Reference Points
Thursday, February 02, 2006 11:54 AM
One would think that the reference points used by people on the same team, working on the same project, would be quite detailed and precise, but this is often not the case. It is unnerving to hear the number of people that don’t regularly use a specification or design as the basis for developing an application – either because it doesn’t exist at all, is incomplete or out of date, can’t be found, or simply because they can’t be bothered to look or have been burned in the past!
When people get together to build a house, it would be unthinkable to do so without a reference point to work from. For a house, which has roughly the same order of complexity of many software projects, this reference point is a broad set of drawings and other information that is established in advance, and kept current with ‘as-built’ annotations along the way, even though there is far less novelty involved in building a house. The multiple views all tie together consistently, and whether it is a plan view, plumbing or electrical detail, landscaping or other perspective of the house, each has been developed in the context of the others. It seems to be this way because we can all appreciate the cost of building House 2.0.
Even in the world of the Agilists, it would be unconscionable to develop a product without a set of reference points to keep the team synchronized in the midst of uncertainty and discovery. Starting with a strong metaphor, through the development and evolution of user stories, the reference points for the project grow and strengthen with time. The fact that they are not collected in a formalized Document is more often than not an advantage in the world of constant change.
Those that might suggest that the code is the only real reference point for their software systems are, to my mind, just plain wrong. While some projects will actually be deemed successful without the initial common ground and direction that these reference points can provide, they almost always arrive at their end point through a great deal of confusion, restarts, disappointment and missed expectations. The declared success is frail, and usually arbitrary.
Even for projects involving one person over a long period of time (as many of my ‘hobby’ projects tend to be), there needs to be a place to capture information that can be referenced later – what I’m trying to build, what’s been done and what’s left to discover, and the rationale behind my decisions – so I don’t have to go through the painful discovery twice.
For any project, no matter the size, the team involved or the timeframes you are dealing with, there is great value in sitting down up front and deciding which reference points are going to be needed to keep the team headed to the same destination. With an understanding of what needs to be captured and where it is going to be stored, we have a higher likelihood of using it throughout the project. As the information is being built up initially, retaining and managing it in that planned location and format reduces the risk of loss, and makes it easier to cross-reference against other sources for consistency.
Focus on identifying and detailing those reference points as well as you can to avoid having the team scattered in all directions – it makes it far easier to converge at the same end point as expected.
-Jim Brosseau of Clarrus Consulting Group
Previous Story - Next Story
Return to Home