Wednesday, May 2, 2007

The Agile Team's Dashboard

Last summer, I shopped for a new car. I decided with rising gas prices to purchase a Hybrid. My goal in buying this car was to improve my miles per gallon (MPG) so I didn't have to spend as much as often at the pump. With this car, I have two gauges that I didn't have before. The first is next to my speedometer and shows me my MPG consumption (or electric if no gas is being used). The other gauge will show me the Tank average for MPG.

At first, I wasn't used to these measures and didn't pay much attention to them. Therefore, my driving habits were similar to what I had done before with my other car. I drove the car as I had driven the previous one. As I got familiar with my car, I started to explore both of these gauges. I started experimenting with how to increase my MPG usage. I discovered that if I accelerated a little slower after being stopped it made a difference. I discovered that I could coast more often when going downhill instead of hitting the gas and still maintain the same speed (but save on MPG usage). As I result, I started to see the MPG increase.

Then, I decided to not pay attention to either gauge for awhile. Just try to drive the car using what I have learned and see if I got the same results. Though I did better than when I first started using the car, I still was getting lower MPG by not paying attention to these gauges. These gauges were a good visual tool to help me accomplish my goal of higher MPG, and were a good reminder when my bad habits would come back and cause my MPG to drop.

So, why all of this talk about cars? Well, think about Agile teams. Their goal is develop as much working (deliverable, quality, meets customer needs) software as possible in set increments of time. How do they measure this? There are two gauges that most Agile teams use to ensure they focus on the goal of delivering working software.

First, the team calculates their velocity from Iteration to Iteration. Velocity measures the total amount of work that was accomplished to deliver working, completed stories by the end of the iteration. If a story is partially completed, the team does not get credit until the iteration in which the story has been completed. This encourages teams to focus on completing stories than completed tasks leaving incomplete stories. If the team is focusing on the completion of stories, as is a dedicated team of individuals, you should be able to sustain a certain range of velocity from iteration to iteration. Where Velocity gets lower, you should see why things are getting done. Where Velocity is higher, you need to see why the team was able to accomplish more. If the team pays attention to Velocity, they will begin to see better development practices (much like my driving habits improved after paying attention to MPG).

Second, the team uses a chart to track progress at both a Release and Iteration Level. The burndown chart shows how work in being completed on a "trip" by "trip" basis. At a Release Level, the chart shows how each Iteration is progressing and the team can get a good idea of what amount of scope is possible based on this information. At an Iteration Level, the chart takes the daily remaining hours for the team to be used in the Daily Standup to see progress. If the chart isn't going down as quickly as expected, this is an indication that the team has impediments that must be addressed. These impediments could be thrashing (team isn't getting to a resolution), dependencies to other stories/tasks (team needs to remove dependencies where they can), additional scope (additional stories and/or tasks have been determined necessary to get complete). In any of these cases, the team can quickly see the impediments impact to the iteration and make adjustments.

Both Velocity and Burndown charts are good gauges to ensure that you are doing what you can to deliver working software. These measures should expose you to some problems (waste in Lean thinking) that need to be resolved. Most of the time this requires a change in how you do things in order to accomplish the goal better. If Agile teams aren't using these gauges, much like my driving, they can get back into bad habits and find themselves not having great results after each Iteration.

1 comment:

Rick Palmer said...

That's a perfect analogy Skip - you nailed it on this one!

My first reaction after reading only a few paragraphs was to start talking about the value of just getting really good people who are self-motivated and like to get work done, and are good enough to get a LOT of it done in a short period of time. There's definitely value in that, but even a super hot team can fall into bad habits or be operating at less than optimum. In fact, even if their regular pace is way higher than a typical team, they could still do even better if they "pay attention to their gauges".