Reporting for Accountability
by Geoffrey Slinkerversion 1.3
March 24, 2006
April 22, 2005
July 1, 2005
Abstract
Reporting and accountability are essential for business processes. Without those budgets can not be calculated, resources can not be utilized efficiently, as well as many other issues. Reporting has come to a level where one can truly do "more with less." Daily stand-ups, end of cycle reporting, damage charts, dashboards, and burn charts accurately and concisely disseminate information.Introduction
Often the challenge of doing "more with less" is extended to teams as a catalyst for thought but many readily accept that generally the paradox is not possible. In the area of reporting of status and progress in software development the paradox is true. This is accomplished through the use of less technology than has previously been used and also the acceptance of new mediums for documenting and reporting.The goal of reporting should be to accurately report the subject matter concisely and precisely. To facilitate that reporting is done often the mechanism should be easy to use.
The practices that will be used for reporting are project planning, release planning, iteration planning, 10 minute stand-ups, end of iteration reflections, end of release reflections, end of project reflections, and information radiators or dashboards.
The information radiators or dashboards include damage charts, burn charts, and project status charts.
Ten Minute Stand-Up
This meeting should be held early and it sets the tone for the day. The meeting should be held in proximity of the information radiators so that everyone can see what they are supposed to be doing.Some questions that can drive the stand-up meeting are:
1. Have the expectations for success changed?
2. Has the scope of current tasks changed?
3. Have there been any changes in related or dependent projects?
4. Has the priority of any remaining tasks changed?
5. Are there changes to any risk factors?
6. Do you feel the project is focused on solving the right problems?
From these questions you should receive yes or no answers. Any no answers should be noted and addressed afterwards with the right set of people.
Project Planning
In the 20th anniversary edition of the Mythical Man Month Brooks states that iterative development has been shown to be more efficient than previous development approaches.I will not go into the details and benefits of iterative development and will assume that it is generally understood to be superior to strict "phased" approaches. I have elaborated on this topic on the paper "Software Scouting and Recon".
At this point you begin the wheels turning as described in "Design By Use Development" (DBU). The project requirements are fed into the DBU process. DBU uses this information to identify subsystems and boundaries. This additional information helps in the organization and scheduling. The information from DBU is combined with the project requirements become "User Stories" which are organized for each sub-release of the project.
Release Planning
The user stories identified as part of the project are now divided into small related groups that will be developed during the iterations of each release. The user stories are fed into the next part of DBU and the usage examples are created. Notice that development starts early but with sufficient information to be headed down the correct path.Each use case has a priority determined by dependencies, complexity, and an estimate for completion.
The use cases with their usage examples are fed into the iteration planning.
Iteration Planning
All of the use cases and usage examples for the release are taken and organized and placed into a particular iteration. When an item has been finished the actual time for completion is recorded next to the estimated time.Completion means that the usage example runs without any errors and implies that the usage example truly represents correct usage and all contracts (pre and post conditions and invariants) have been satisfied, and that the completed item has been integrated with any piece that is completed and awaiting its use.
If this is not the first iteration then recommendations from the previous iteration reflection are considered.
End of Cycle Reports / End of Iteration Reflections
At the end of iteration comments and congratulations are given concerning the completed items. Any items there were not completed are discussed and dependencies and release schedules are update.End of Release Reflection
At the end of release comments and congratulations are given concerning the completed releases. Any items there were not completed are discussed and dependencies and project schedules are update.End of Project Reflection
At the end of the product comments and congratulations are given concerning the project. The key here is to celebrate the hard work and the finished product. If scope had to be changed or dates had to be altered for the project the information concerning those items should have been recorded in the end of iteration and end of release reflections. This is a time to take pride in the hard work so don't dampen any spirits. At the next Project Planning meeting the lessons learned can be discussed and improvement activities can be identified.They say that each project fails one step at a time but also each success builds one step at a time. Let's take the positive look on things and remember to allow people to have success.
Information Radiators
Information radiators are placed where they can be easily seen by those who are concerned with the project's information.Information radiators are low tech for a reason and that is ease of update. Information radiators should be very active and therefore necessitate easy change. They should be well organized and easily captured though the use of a high resolution digital camera. The digital photograph is the medium for recording. Remember if it wasn't recorded it didn't happen and notice how easy it is to record. That is like having your cake and eating it too!
There are certain types of charts or layouts that convey information rapidly that are considered essential for each project. A description of each type follows.
Damage Chart
Alistair Cockburn described it to me at a users group meeting something like this: "In the web browser market the race between Netscape and I.E. was concerned with getting anything to market. The damage caused by not planning was not the concern. The key was getting anything into the market. Trying to make the best web browser didn't matter. Software concerning the space shuttle is completely different. The damage caused by insufficient planning could be extremely expensive and cost lives."
Other types of damage plots can be created. Damage for a missed "release window" could be plotted but this type of chart must be very accurate or you will not be able to motivate people after wolf has been cried too many times. Estimating the damage for missing a window of opportunity is similar to the inaccuracy in estimating when code will be finished. The similarities should cause development and marketing to appreciate the difficulty of each other's tasks and alleviate some of the bickering and finger pointing. Holding marketing to their estimates should be done with the same rigor that development is held to their estimates or in other words "play fair".
Burn Up and Burn Down Charts
These charts show progress. The key is determining the units for the Y-axis. There are many reports on these charts and one should study them to determine how you will do them. Here is an excellent reference: http://alistair.cockburn.us/crystal/articles/evabc/earnedvalueandburncharts.htm
In this example burn down chart it shows that the project estimated the completion of 100 features in 8 weeks. The chart shows that it took 10 weeks to complete the features. It also shows that the project was in trouble significant trouble at four weeks and that the team got the project back on schedule on the fifth week but was unable to maintain the velocity.
These charts should be updated and posted with any information radiator that is related to or concerned with this information.
Project Status Charts
These are those charts on butcher paper or white boards covered with sticky notes.
In this progress chart each line represents a developer and the use cases for this iteration. Each yellow box represents a sticky note that will have a short description of the use case and an estimate for completion. The sticky note moves from left to right showing the representing the percent completion. When the use case is finished it is placed on the right with the actual time for completion noted next to the estimate.
This progress chart shows the entire product. The thick line represents the product boundary. Every use case above the line will be included in the product. Every use case below the line are things that were considered but haven't made it into the product at this time.
The use cases labeled "Release Sets TO DO LIST" are the use cases grouped by release. The current iteration at the top shows the release set that is currently being developed and are in progress. The finished uses cases are those that were completed during the previous iterations. The green arrows show the flow from the left side or to do side to the current iteration and from the current iteration to the finished side.
Each use case has a time estimation and the total of all of the uses case estimations form the "to-do" area, the "in progress" area, and the "finished" area the total time to develop the product. If an item is moved from the "use cases not currently in the product" into a release set then an item from the release sets with an equal or greater estimation time must be removed to keep the project on schedule.
No comments:
Post a Comment