Archive
A testing bottleneck in my Scrum Team
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.
Sailboat Retrospective
I use the sailboat retrospective as an activity to gather information for Sprint Retrospectives, Release Retrospectives or even when I go in as a coach to find out where teams are. It is a fun way to gather opportunities, risks and problems.
I believe I may have been inspired for this retrospective by Innovation Games Speed Boat game used for Identifying features that are holding you back.
I draw a picture, you don’t have to be an artist just see below:
The idea here is that the team are on a boat. On the right hand-side is the Promised Land it is the best development environment they can imagine: an effective team who can take pride in their work, happy customers, opportunities for learning and growth (I usually get the team to create some kind of Vision for what the Promised Land looks like). However there are anchors that are holding them back, stopping them making progress towards the Promised Land (These are the problems). In front of them there be pirates, rocks and other obstacles which could stop the team/organization getting to where it needs to be or even sink the boat completely (These are the risks). There are however opportune winds, things in the organization that we can take advantage of to fill our sails and navigate a course to the Promised Land (These are the opportunities).
So ask the team:
• What are the opportune winds that will help us propel our ship to the Promised Land
• What are the anchors that are holding us back
• What are the rocks and pirates that can sink our ship (or at least do some damage)
One problem, risk, or opportunity per sticky and ask them to write clearly. I get them to do this individually so that everyone gets to contribute.
5-7 minutes to individually brainstorm
Allow time for each person to go up and place their stickies on the picture while the others listen.
You can then get them to organize/filter them however you want. Before moving onto driving out some actions.
Cool Wall Retrospective
This post is republished from my old blog
At the Munich Scrum Gathering (2009), Harvey Wheaton from Supermassive Games did a presentation entitled “Growing Self Organising Teams”, which was exceptional and I found it very inspiring, the presentation can be found on the Scrum Alliance web-site. In the presentation one slide caught my attention and it was how the team had used a Cool Wall, inspired by Top Gear (popular car show in the UK). I thought that would be an excellent tool for a retrospective and used it at the next opportunity, this is how I used it. Picture not great, but you get the idea…
Using the Cool Wall to Gather Data
The team was asked brainstorm team practices/team customs/patterns/ways of working, each team member then took it in turn to add their practice to the cool wall, and share it with the rest of the team. Sub-zero was for practices where the team felt they were world class, seriously un-cool was reserved for practices that really weren’t working.
I then asked the team to vote for the practice they wanted to work on, I had forgotten my sticky dots so we used marker pens. The team actually picked a practice from Un-Cool as the stuff in seriously un-cool was out of their sphere of influence and the ScrumMaster was dealing with it already.
Using the Cool Wall to Drive out Actions
Once we had selected a practice we had some discussion to understand the root cause. We then moved to generating actions by asking ourselves what we need to do to move this practice one column to the right. Remember you only want a few actions otherwise nothing will get done.
Check-out
To keep with the car theme I then asked the team to say given their project, what mode of transport they most felt like.
Summary
The approach worked well and really helped to create a picture of the work the team does, and uncovered loads of stuff that the ScrumMaster could work on to help the team improve. Also we only spent an hour doing it.
Exploring Agility 