How many of you are running Scrum but struggle to get the burndown to be anywhere near the target – more often than not it sits flat and then drops down (to hopefully zero) in the last couple of days. I have even seen teams whose “target” burndown is a similar shape, they’d given up ever trying to get close to that constant gradient.
This is because the teams run mini waterfall inside their sprint. Each team member has their own role and the work is passed person to person (with a note saying, “done my bit, your problem now”) just like a whole project would be in a waterfall SDLC.
The most critical of these handovers is from a Developer to a Tester. This seems perfectly sensible, we know developers, we know testers, there is a natural flow of work. However this approach is fundamentally rooted in the past, reflecting practices and technologies which should now be dim and distant memories.
Firstly the tester role used to be more of an operations role, an experienced user trying every permutation they could think of to check it works. Now we are asking them to be more technically capable so they can test pieces of a flow, stubbing out inputs or outputs.
With an incremental delivery everyone has appreciated the importance of an automated regression test suite and as that has the word “test” in it –well give it to the tester. So there are teams out there with developers writing code and the super technically capable testers writing automated test scripts around it.
Stop everyone! This is taking the traditional siloed waterfall practices and hammering them into SCRUM until they almost fit. It is inefficient and enables individuals in teams to avoid ownership of delivery.
SCRUM is a reasonable approach for work management in iterative development but it has little to say on the technological approach other than the team members should be cross functional, to really get an Agile delivery to work you need to support it with XP – and inside that is the answer to the burndown gradient issue.
Within all the other good stuff in XP is the concept of TDD, Test DRIVEN development, where we write tests inside the code before writing the actual code. The important consequence of this for this piece, is that it is the developer that writes it. So the developer writes the code AND the tests. Horror screams the testers, for two reasons:
- “What about me, am I just redundant now?”
- And then secondly – after calming down for a moment – “we don’t trust the developers to check their own work, developers think differently to us, we consider all the options etc”
The first is an issue, the second a valid point and the solution to the first. If we change the focus of the tester to assure the work of the developer rather than the code (with focus on the coverage and approach of the automated tests) then the role brings genuine value to the team without necessitating an awkward handover.
I’d support renaming this role to be Quality Assurance, giving assurance to the team about the quality of the work done, this frees up the term tester for where it belongs and originated from. Genuine users in operations that can use the system to ensure that it does what is needed, ensuring there is no gap between what was designed and what was needed.
Operating with this approach will ensure that all team members are equally busy over the duration of the sprint and stories are pushed to “Done” consistently over the sprint rather than being pushed to a separate Test function who then close stories out at the sprint end.
As always happy for comments edits suggestions etc. @philagiledesign