Agile: How can you show process improvement?

Posted: May 9, 2010 in Agile, Testing
Tags: , , ,

As in all walks of life, the need to illustrate and justify your position is an integral part of belonging to an agile team.

Selling Agile to customers, announcing that collaboration and collective agreements will reduce the time lost to inefficiency; caused by mountains of paperwork and documentation is a big statement to make. Following that up with thoughts of parallel development and testing and the budget holders start drifting off into a dream World centering on time to market and thoughts of an extra bonus if we can bring delivery times in still further.

Making these claims, need to be built on foundations; there needs to be proof that all that is claimed will eventually turn to gold. So how can you do that, without increasing your management burden? Without affecting the mantra of team self-organization? Inevitably metrics have a role to play; but which ones?

One method that I use, can provide a dual purpose. The graph below, shows 2 main pieces of information:

1. Team velocity per sprint
2. Number of defects detected per sprint.

Sprint Velocity and Defect Trend

What this shows is that as team velocity grows, through collaborative efficiency or adding additional heads; the trend to aim for is that the number of defects found is reduced, or at least does not show rapid spikes. So what? I hear you cry. Well when you think about an agile project, Sprint 0 is a write-off in terms of delivering functionality; follow this up with the early sprints and it is likely that only basic features will begin to emerge. Fast forward to Sprints 6, 7 etc and the level of functionality is significantly increased. Therefore, if you can demonstrate that as your functionality increases; your defect detection rate remains the same  or shows a downward trend then this either means you are extremely lucky, not reporting all defects or the one I hope you find yourself in; that the level of process and collaboration is improving.  

 The above is a very simple trend model to create at the end of the sprint. Though simple, it should at least give a view of how well the team is doing. A rapid increase in the num ber of defects that are found, should lead to open discussion during the retrospective, questions should be asked, along the lines of:

1. Did we take on too much? Did the refactoring undertaken reduce the testing time during the first 2 weeks of the sprint.

2. Did we take onboard the testing feedback? if so, did we delay the fixing too long?

3. Are we sure all team members knew what the stories; and design meant?

If during these discussions it is found that a short-cut was taken, steps can be taken to close the process gap. Referring to the trend chart at the end of the next sprint should provide the evidence of how well the retrospective feedback was taken onboard.

Retrospectives also have a big role to play in illustrating process improvement. On a recent project; every Monday after the completion of the previous sprint the team all got together and came up with 3 or 4 retrospective points. After 2 or 3 of these retrospectives we found that the same points were coming up each time; we were holding retrospectives purely to follow the steps of Agile! The team agreed that 1 of the retrospective items had to be “Implement and Track Retrospective items!!”. Since this decision was made, we write the agreed retrospective items onto a different colour story card and track them on the wall from ‘To Do’, ‘In Progress’ to ‘Done’. It’s a very simple approach, but each day the team stands in front of the cards during the daily scrum… we have to discuss the items and make sure they are being implemented!

 Both items outlined above have been effective in indicting where the team is potentially coming off course. The most important thing about them is that they are not labour intensive and do not impact the self-organization of the team.

  1. Devon Smith says:

    Great tip. Agile testing is a different style and there are a lot of adjustments QA can make to show our involvement and help us integrate into the new system.

    • dsearle says:

      Thanks for the comment Devon. The amount of adjustment is indeed a lot, but I am finding that there are a number of overlaps to enhance the transition to Agile Testing. Although ‘Process’ is sometime an evil word to use on an Agile team, variations of this do support the collaborative ethos of Agile.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s