Saturday, August 14, 2010

Project Vital Signs

The Thoughtworks Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)At Agile 2010, Stelios Pantazopoulos gave a presentation on project metrics entitled “Project Vital Signs”. Stelios starts by pointing out that IT has lost trust and credibility with the business due to projects having a poor track record of success, poor visibility and ROI that is hard to quantify. Projects are over budget, late, or fail all together. To restore trust and credibility, we need to show how and why a project is on track throughout the project’s lifecycle.
Stelios, suggests applying the metaphor of medical care and their use of “vital signs” to help form a holistic view of the state of the project. In medicine, doctors go over the patient’s medical history, review lab test results, look at vital signs, and then use their experience to diagnose the condition and recommend a treatment. Stelios defines vital signs as simple, quantitative, near real time metrics conveyed via a chart published to a location and easily referenced by all. There are 5 vital signs that need to be monitored. 4 are based on PMBOKs Scope, Quality, Schedule, and Budget. In addition, Stelios feels that monitoring the team’s overall health is also very important.
The 5 charts are:
  1. Scope Burn Up: Backlog burn up chart (stories in each state vs. time) that tracks schedule and scope to show expected delivery date. Number of stories or story points are be tracked. Stelios mentions that if you have a big enough back log, tracking number of stories worked well for him.
  2. Current State of Delivery: Backlog Scrum board that tracks scope and team and shows real time state of delivery. Tracks the state of each story and who is working on which story.
  3. Budget Burn Down: Burn down chart (total $ vs. time) that tracks schedule and budget to show remaining dollars.
  4. Delivery Quality: Dot Chart (bug category vs. time) that tracks schedule and bugs to show overall quality. Bugs are categorized into 4 categories:
    1. High priority/High severity
    2. High priority/Low severity
    3. Low priority/High severity
    4. Low priority/Low severity 
    At the end of each iteration, each bug is represented as a dot in the corresponding category. Ideally, as the schedule nears release date, most bugs should fall into the low priority categories. Stelios also mentions that alternatively one can track automated test results as opposed to bugs.
  5. Team Dynamics: Chart (state vs. time) that tracks the state of the team and schedule to show the state of team at different stages of delivery. The state is collected in the retrospective by asking team member to have a secret vote on where each feels they are on the Tuckman model of group development (forming, storming, norming, performing). Similar to the delivery quality chart, each team member’s opinion is represented as a dot in the corresponding category.

The 5 project vital signs are combined to create a project dashboard that is placed on the wall for high visibility. Stelios wraps up by going through different sample scenarios and demonstrates how the dashboard provides a holistic view of the project. He then diagnosis the project and performs what if scenarios for different treatments showing the state of the project before and after treatment.

Stelios provided the slide deck for the presentation at

Wednesday, August 11, 2010

Agile Coaches Dojo

Agile CoachingAt Agile 2010, Rachel Davies gave a workshop on Agile Coaches Dojo. The Dojo was modeled based on the developers dojo where a bunch of developers get together to solve a challenging programming problem. The group collaborates to solve the problem and along the way learn new tools and techniques.

In the Agile Coaches Dojo, instead of solving a coding problem, coaches solve a challenge faced by an agile coach. Rachel recommends the following format for the dojo:

A seeker presents a specific challenge to 3 coaches. The coaches each take 5 minute turns to discuss the problem with the seeker and provide advice. Meanwhile, 2 to 3 observers take notes documenting interesting perspectives while a facilitator ensures the dojo moves along smoothly. At the end of the discussions, the group has a 5 minute retrospective on what went well in the dojo and what did not.

The Agile coaching Dojo gives participating coaches a chance to see how other experienced coaches tackle the same situation based on their own personal style and reactions to different context.

Tuesday, August 10, 2010

Building a More Accurate Burndown Using Range Estimation in Scrum

At Agile 2010, Arin Sime gave a presentation on how to build a more accurate burndown. Arin started by asking how long does the drive to work take? Various answers were given (15 minutes, 8 minutes, 45 minutes, 20 to 30 minutes). Arin pointed out that some estimate were precise but might not be accurate (for example 8 minutes, but what if we hit traffic?). Other estimates were less precise but allowed for more accuracy (20 to 30 minutes). He mentions that single point estimates are a problem because we tend to be overly optimistic and use different methods or have different biases. He then presented a scenario and asked if we can build a CMS website within 2 weeks. Some answered simply yes or no while other asked for more info and then gave a range of 3 to 4 weeks. The point was that even though a range was a better answer, the original 2 weeks presented in the question created an anchor for the response and any answer will be close to that range.

Arin moves on to discuss Scrum and mentions how Scrum uses planning poker to generate a consensus group estimate, and how using story points ensure relative estimates. However, estimates are still a singe point. Range estimates recognize uncertainty, alleviates our tendency towards optimism, incorporates risk, allows for better financial projections, and better informs our bosses and clients.

Arin then demonstrates how he uses range estimates. Basically, he still uses planning poker with his team, but each team member now raises 2 estimates. The team still discuss differences between low and high estimates, but eventually settle on a range between the 2 estimates. On the sprint burndown chart, both the high and low estimates are tracked. A 3rd estimate (the 2/3 of range estimate) is also tracked. Now the chart shows an ideal burndown and a low and high deviation limit. The actual burndown should fall somewhere in between this range

Arin warps up by warning against some pitfalls of using range estimation. He mentions that not everything can be estimated using a huge range otherwise you will lose all credibility. Try to meet the ideal estimate and don’t use the high estimate as an excuse to miss deadlines. He also stresses on always using the range estimate and not slowly moving back towards relying on the single 2/3 estimate.

Arin provided the slide deck for this presentation at

Effective Questions For An Agile Coach

Arto Eskelinen and Sami Honkonen gave an agile coaching workshop at Agile 2010. They presented the GROW framework in which coaches can structure effective questions. They started by stressing that sustainable change has to come from inside and as coaches we should not be tempted to give advice but instead create better awareness to help the team take ownership and feel empowered. They recommend favoring what and when questions and recommend avoiding how, who and why questions. The goal is to keep things at an observatory level and not at the analytical level.

The GROW structure provides questions that lead to exploration, aim at descriptive answers, avoids judgment, and avoids an unproductive state of mind. The idea is to look at the goal 1st, then look at the current situation, and analyze what are possible ways to move forward. Finally, make a decision and follow through.

Arto and Sami describe each stage of GROW as:

1. Goal: A description of the desired or ideal state. Make sure it is meaningful and specific and stated in a positive way (use: Catch the ball vs. don’t drop the ball). Ideally, how would you like things to be? What will you get out of it? What do things look like when we get to that ideal state?

2. Reality: A description of the current state? Try to expand coachee’s view of the situation by testing current assumptions, exploring different angles and exposing feelings to different situations. Do not be tempted to just gather data and make a decision. Try to ask questions that lead to moving away from reality and lead to exploring and seeing things from a different angle. What if we have more time? More people? What does the other team see in this situation? What does this solution feel like?)

3. Options: State the existing ideas (how would you solve this?) and challenge the limitations (if this limitation was not there, what would you do?). Also, make sure to discuss “stupid” ideas. These might lead to exploring other interesting angles that were not considered before. Try to have at least 3 options to consider. Keep asking: what else? Until there are enough good option to evaluate.

4. What will you do? The last step is evaluating the options and formulating and action plan. Make sure a timeframe is set, obstacles are removed, uncertainties are cleared and done is defined. What are you going to do? When are you going to start and how do you know when it’s done? Are there any obstacles? What prevents you from achieving your goal? On a scale of 1 to 10, how do you feel about this solution? If they answer 8, then ask what is stopping it from being a 10.

A questions checklist is provided at Sami’s site at