I'm not convinced by the merits of developer only testing. I've known teams that have done it, and in certain contexts I'm sure it can work well, but I've not encountered many situations personally where a good software tester wasn't actually or potentially a massive asset to the development effort. I know that it can be challenging even for an agile team that has been struggling with developer led testing to know exactly how to understand the tester role and get the best out of testers when they are introduced. I encountered this situation last year when I bringing some testers into a struggling development team. To help clarify expectations I created some definitions around how different development roles focus on value ...
Introducing testers can be a challenge
The programme was a victim of it's own success. A flagship bespoke agency programme that had grown into a behemoth of bespoke development as more of the customer's international regions were brought onto the programme. As the scope grew the team's reliance on informal developer only testing and code review backed by unit testing had led them to struggle. Revenue was being lost due to high levels of non-chargeable bugs and rework.
We negotiated to bring two devoted testers into the programme and I brought in two excellent testers that I knew. While everyone agreed that the testers were very much needed, there was some confusion within the scrum teams as to what the testers were supposed to be doing.
- My original brief to them was to act as 'test consultants' helping the developers product owners to identify risks and to improve the rigour around the processes of work flowing through the team.
- Some were expecting the testers to act more as gatekeepers and 'sign off' each story passing through the team.
- Others were almost trying to pretend that they weren't there and still hitting the same problems as before.
It was clear that the testers were much needed but the confusion around their role and responsibilities was limiting their impact, with the result that the team were still struggling to deliver value.
Three pillars of value
The team needed some alignment on the responsibilities of each role so I built some role definitions to share. Heavily influenced by a conversation I'd had with Michael Bolton at Eurostar - where he discussed the idea of the tester of having responsibility for the identification of risk not just in delivered functionality but through the entire development process - here's what I presented:-
- Product Owner - Identifies Value
- Developer - Delivers Value
- Tester - Protects Value
That simple.
I don't have the original presentation but I've since drawn up a similar summary of the differing responsibilities of each role in this context
In each column there's an order here that reflects increasing depth of capability.
- A basic product function will look to identify new capabilities that they believe will add value and prioritise these for development. A more advanced function will analyse and identify things that don't add value and look to establish tools and processes to provide evidence supporting value decisions.
- Every development team will code new features into the product, teams with deeper focus will have the autonomy and capability in technology and progress to prioritise redevelopment and introduce technologies to ensure that the delivery of value doesn't slow down over time.
- Rudimentary testing processes may look for bugs in newly coded features, others will have a defined and effective approach to regression testing. For many this is the extent of the testing role, however those with a deeper testing capability will have the autonomy to negotiate for testability in the software. They will also have the capabilities to introduce processes and tools to help in their exploration for risks. An important distinction from a traditional view of testing is that these risks to value may occur throughout the development process from the earliest idea inception right through to testing during delivery and production use, if there is a risk to the value we've identified and are trying to deliver then it is part of the tester's remit to find it.
A healthy balance is needed
For a development effort to maintain long term value it needs to have a balance involving depth capability and focus in each of the three pillars of value identification, delivery and protection. These areas of focus don't have to correlate to roles. Yes it is possible that one role can be responsible for more than one of the pillars, but what I've personally encountered in this situation is that those responsible for multiple pillars will only focus on one beyond the basic level.
Without a role that specifically focuses on each, the priorities of the other(s) can pull the team and product into an unhealthy shape.
- Too much priority given to value identification leads to an unachievable backlog. This is a risk in lean startups and agency programmes including the one that prompted this post. New features will be identified and added but at the expense of maintaining a healthy architecture and processes. This will reduce ability to maintain the velocity of delivery over time due to architectural no-go areas and high levels of regression.
- Over-powered delivery results in a runaway development team adding technical capabilities to over-architected software at a pace that with low confidence that it will deliver value. The product roles are too busy 'feeding the machine' to gather evidence on whether the features are delivering the value hoped. This shape is characteristic of teams that have scaled developers without the support of product and research roles.
- An excessive focus on value protection is more characteristic of more mature companies who are more focussed on maintaining what they have than identifying and delivering anything new. The lack of pace in responding to changing market needs with new capabilities poses a serious risk of being uncompetitive and ripe for disruption.
Having a healthy balance of focus on each area is not easy, but is necessary to ensure that value can be added and maintained at an indefinitely sustainable pace.
Did it help?
It would be easy for me to say now that the whole programme improved after my explaining of roles, and to attribute this success to this intervention. I know that the team did improve massively, to the point of supporting a renegotiation of rates and budget with the client, but I also know is that everyone on that team was putting in a huge amount of work to achieve this improvement and that effort had little to do with my input. What I like to think is that just getting the team together and giving some guidance around primary responsibilities and a clearer process helped to inject some clarity at a time of uncertainty and align the efforts of the different roles.
It's often said that nothing helps you to understand something than explaining it to others. Putting together the role descriptions for that team has provided me with a clearer way of explaining different roles in future and a useful model for assessing the balance of a team and the reasons for the problems they may be facing. A more subtle but important benefit that I get from this way of explaining the roles is this provides a structure that shows testing, development and product roles on an equal footing with a fair representation of what a deep testing capability looks like. For this if nothing else I'll certainly be using it again in the future.
image: https://www.pexels.com/photo/white-painted-pillars-907819/
Nice post, thanks Adam
Post a Comment