by Geoffrey Slinker
version 1.3
March 24, 2006
April 22, 2005
July 1, 2005
| Accesses: |
| Maverick Development |
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.
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.
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.
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.
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.
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.
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.
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 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.
The damage chart shows damage plotted against amount of planning. Some projects
need lots of planning because the damage from insufficient planning could be
devastating. Other projects need less planning. Just remember, all projects are
not the same and one size does not fit all.
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".
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.
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.
Reporting and accountability are crucial for business processes. The time has
come that reporting can apply the paradox of "doing more with less". Planning
meetings, daily stand-ups, end of cycle reporting, damage charts, dashboards,
and burn charts accurately and concisely disseminate information. By using
digital cameras in conjunction with information radiators the state can be
documented as often as desired. Through these planning and reporting techniques
the goals and state of a project is readily visible and easily reported.