Exploring Agility

Recently I was working with a Scrum team who were struggling to get things to Done at the end of a Sprint, they already knew that they had a bottleneck getting things tested, but didn’t really know how to resolve it.  They are certainly not unique in having had this struggle, and it was really costing them partially done work, tester working long hours at the end of the Sprint, a code freeze 3 days before the end of the Sprint.  I also sensed frustration because they felt things couldn’t improve unless they changed the ratio of developers to testers (6 to 1).  That wasn’t going to change immediately and I do like to focus the team on the art of the possible, so what could we do?

I knew I needed to do a little bit of education on dealing with bottlenecks, therefore I gave them a 10 minutes intro on the 5 focusing steps from the Theory of Constraints and then we did a retrospective to come up with some specific actions for them to take as a team.

Identify the systems constraints

The team had already identified that the tester in the team was overloaded with work, especially at the end of the Sprint.  Unfortunately the tester was also starved of work in the middle of the Sprint.

Decide how to exploit the system’s constraint(s)

In this context this basically means looking if anyone else in the team can do some of the testing work.  This is also a subtle way of introducing the team to the idea of taking a whole team approach to quality, without telling them that’s what they need to do.  The kind of things that came up in the retrospective here were:

• Look for opportunities for other team members to help out with the writing and running manual tests. (The team did not yet have any automated acceptance tests)
• Other team members helping out with setup activities, i.e. environments
• Production of tools that would allow the testing work to be done more effectively

Subordinate everything else

For us this meant looking at changing the way we work to get work to flow more evenly.  In this area we were looking at how we breakdown work and work more collaboratively as a team:

• Break down items into smaller chunks so that they can get into test earlier
• Write stories so that they are testable, so that parts of the story could be tested earlier
• Create opportunities for earlier feedback from test, reduce waste of fining errors on test environment
• There is no such thing as a bug in a Sprint, its just work that needs to be done before  the Story in Done
• Limit items team is working on (Items in Progress), team members swarm on items
• Investment in Automated Acceptance Tests, which would allow the developers to take some of the testing burden

Elevate the system’s constraint(s)

This is looking at how we can increase capacity or capability in the bottleneck area.  Which for us would mean hiring more people with the testing skills or providing some kind of training (be it formal or on the job).  You should only be thinking about this if you have tried everything you can think of in the previous two steps.

What the team agreed

The immediate things the team agreed to do were:

• Breaking stories down smaller and also looking for opportunities to commit code regularly, as soon as something can be meaningfully tested
• Involving the tester in design activities, so that the team could design/implement with testability in mind, also as a result there was less of a handover
• Regular demo’s to the tester and Product Owner, whenever there is something to show
• The tester would continually ask “what have you got to show me?”
• Toolset to support Testing Diagnostics

It wasn’t agreed in the retrospective but subsequently they also started to get other team members helping out with testing tasks as well.

As a result of these actions, the code freeze was no longer necessary and the test activities were more evenly spread throughout the Sprint, they had less partially done work.  So this is a good step in the right direction.  To take it to the next level the team will need to focus more on swarming and investing in automated acceptance testing.  If they can start to do that over their next few releases, then the perceived issues of the ratio of developers to testers may become a mute point, as the team adjusts its skills and practices to be able to deliver high quality work.