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.
*Until you understand the challenges preventing you from collapsing the process into To Do | Doing | Done
I’m a big advocate of collapsing columns on your Scrum / Kanban / Story board from the classic In Analysis / Analysis Done, In Dev / Dev done & In Test/ Test Done (yes, this is a waterfall process on a wall) to To Do | Doing | Done.
There are many reasons why To Do | Doing | Done is more suited to iterative & incremental development – Jit Gosai does a great job of calling out some of the benefits in his “In Test Column” post.
This post is focused on the When & How of collapsing the number of columns on your board.
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.
In my previous post on followership, I talked through how it came onto my radar & ideas for being a good follower.
I also discussed how the term is more nuanced than I first gave it credit for. As I dug deeper into the topic, I started honing in on those areas of my life where I was a follower or actually some form of leader & how I felt about each of those relationships.
This post outlines how I used various models to help me understand where on the scale between followership & leadership I was for various aspects of my life.
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.
I always believed that if you shared your goals, you’re more likely to achieve them, but whilst trying to find science to back up my thoughts I found several articles stating the opposite – sharing you’re goals makes you less likely to achieve them.
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.