I’ve spoken in previous posts about how at my previous customer I was working with non-software development teams, helping them interface with the development teams in order to increase collaboration.
A fantastic side effect of this coaching was that the non-software teams recognised the importance of having cross-discipline teams being aligned around value delivery, rather than in their specialist silos.
This post outlines an experiment where we created a cross-discipline team, focused on delivering an FS marketing strategy without changing the organisational structure.
I often use a pithy phrase I picked up from Michael Bolton many moons ago (which he himself picked up from David Platt author of Why Software Sucks) to help people understand the relationship between software quality & it’s users / customers
I’ve been using it a lot recently, so thought I’d share it here
Here in the UK we’re in the middle of campaign fever as we have a General Election on the 12th of December.
Its pretty important election, with some big topics being used as political weapons so I’m currently trying to gather as much knowledge as I can in order to make an informed decision on who to vote for.
This post is about how i’m applying the critical thinking skills & tactics I use in my day job to test claims made by politcal parties.
Heads up, I won’t be sharing my political views in this post.
One of the biggest challenges I typically face when joining a development team is understanding the silo between programmers & testers (& other team members).
I approach this challenge by referring to both roles with the generic term of “Developer”, whilst using “Programmer” & “Tester” to differentiate between the roles when required.
I use the term “Developer” as we are both helping to develop software. I believe I got the analogy of eating from Michael Bolton – you can’t keep stuffing food in your mouth (programming) without swallowing (testing).
This post builds on that idea to share how I use the fire triangle as a metaphor for activities & roles that play a part in software development.
The working title of this post was “Followership – because sometimes leadership can go f*ck itself”.
This sentiment seemed to sum up where my head was at after a challenging role which left me taking stock of what I wanted from a career & my life / work balance. I retreated back to my comfort zone to let someone else do the leading.
You may be able to tell, in my funk I was seeing the term “followership” in a negative light. After studying the topic further I started uncovering the importance of followers & the related skills of following.
After nearly 3 years & 16 Liverpool Tester Gatherings, the 3 of us have learned several very valuable lessons in running free meetups to provide a platform for new & experienced speakers, with both local & international testing status.
I’ve recently been working with project teams who are attempting to remain effective after their organisation has chosen to adopt the Scaled Agile Framework (SAFe).
I’m trying capture & refine the common patterns I’ve observed across several SAFe implementations that have helped those involved in the implementation remain effective after they have been left wondering where they fit.
I’m hoping it will help others who have been in touch with me who are trying to understand what it means to be a practitioner in their newly formed SAFe organisation.
Several projects I am working on within my organisation are adopting SAFe in order to build software solutions, so I thought I should perform some SAFe testing!
With my Agile background, I am able to provide a lot of value in helping the teams follow an iterative development lifecycle (predominantly Scrum), but I have little experience of processes outside of the development teams themselves.
I also seem to struggle to get my message across to senior stakeholders within my organisation who are new to Agile & SAFe.