Tuesday, March 23, 2004

Getting to Linear

Last week at the USC CSE Annual Research Review, I used this Cumulative Flow Diagram to illustrate how I track progress on agile projects and how I use it to make informed management decisions.

Philippe Kruchten made an observation that the chart showed an almost linear progress. In fact it truly isn’t the usual S-curve that I wrote about in the book. What is shown here is 1 week of modeling (Feb 10 through Feb 17) then 5 weeks of coding. The coding achieved a steady progress of around 45 Features per week. [Note: the project is now code complete]

Kruchten’s observation was that there must be something enabling this linearity. His suggestion was that the modeling technique and the use of the domain model, as a planning and communication tool throughout the project, was probably the enabler of the linear progress. In other words, the development team were able to use the model such that they could choose work which would not interfere with other on-going work avoiding dependencies between programming tasks. I think that there is a lot of merit in this view. The Domain Neutral Component [PDF] techniques of Peter Coad and Stephen Palmer are very powerful and allow clear progress to be made without rework or refactoring.

However, there is another reason why the chart shows linear progress and it is much simpler to explain. On the project shown, the team were very good at surfacing issues and running them down before they hit the critical path and slowed down development. This was achieved through the daily standup meeting or the Morning Roll Call of Features which I detailed in The Coad Letter #101. Keeping a visible issue log, cross referenced to all the Features affected by the issues, updated ever day at the standup, really focuses the minds of project and program managers. Getting issues resolved early produces tangible results which can be measured by the absense of the S-curve effect and the consequent higher productivity.