You are never done
What do Agile, XP and Process MeNtOR have in common? The idea that information get created and decisions get made when the time is right, not earlier.
There is a common misperception in software development that documents, be they requirements, design documents or plans, have to be completed, reviewed, signed-off, before they can be used as input into the next phase in software development. This has given rise to processes that are not only overly bureaucratic, but also non-responsive and costly to manage once changes occur.
The agile movement has an acronym for this: BDUF, which stands for “Big Design Up Front”. You could extend this to BRUF (Big Requirements Up Front), BPUF etc. I think you get the drift.
Tom and Mary Poppendiek in their book “Lean Software Development” have discussed the Toyota Car Design process and why it is quicker and less expensive than that of their American counterparts. A key element in the success of Toyota is to avoid making decisions too early. While it is tempting to do make the decisions on issues as soon as the issue becomes apparent (it gives you a nice warm and fuzzy feeling), it often causes follow-on decisions to be made on the basis of the original decision. If later the original decision turns out to be wrong or no longer valid it results in having to un/re-do all the dependent decisions, an exercise that is usually quite time consuming & expensive.
Deciding not to do too much up-front too early is a good idea, but what constitutes ‘too early’ and when is the right time in a software development scenario? The answer is not straight-forward because each project has different dynamics and different dependencies.This is where good practitioners (project managers, requirement team leads, architects, test managers etc) shine by being able to make the right call.
In Process MeNtOR we decided to introduce the concepts of maturities for our deliverables (Process MeNtOR deliverables are the core management concept, it focuses on providing guidance on when and how to create these deliverables. That allows for powerful customization abilities of the project roadmaps but that is another story). On closer analysis of our deliverable we found that many deliverables have a natural maturation cycle. Let me give an example:
A common set of maturities are Initial, Core and Final.
INITIAL means the deliverable lays out the strategy of creating the deliverable, the why and the basic principles and approach to create it. If the deliverable were a software component, then Initial would be the Roles and Responsibilities and, in a test driven environment, the acceptance test case.
Initial is usually reviewed by a peer or a stakeholder representative who can provide guidance to the author for implementation. It also serves as a heads-up for others who will require it as an input for their work – allowing them to get started on their deliverables for an initial release.
CORE identifies that the deliverable, while not ready for production, is good enough to allow checking that it meets the key requirements. For most deliverables it is good enough to be used by others who require it as input for their work. It often has many questions to be answered or decisions still to be made but which are not (yet) show-stoppers for the authors of the subsequent deliverables. If the deliverable is the requirements model, then this would be the key input for the designer/developers to start moving the System Model towards a core release, without having to wait for all the little detail decisions to be completed.
FINAL is well, final. The deliverable is complete and won’t need changes (until the next iteration).
The maturities identify natural milestones in the deliverable. At these milestones it makes sense for other members of the team or the customer to get involved, either for review & guidance or as input for their own work.
Maturities help shorten the delivery time, because it allows downstream consumers of the deliverable to get started – eliminating wasted time having to wait for all little details to be completed.
Another advantage is that maturities identify outcomes not activities. In creating a software component the author is free to determine the actual selection and sequence of activities (design, code, test vs. code a bit, test, design, repeat) according to the actual circumstances. This gives the author more freedom but also more responsibility on how to deliver what they commit themselves to.
Process MeNtOR describes maturities for each of its deliverables. A few have no real maturities because they always are only produced as final (e.g. a test case result). Some have more than three, but not too many as the maturities require to be easily grasped and understood by all involved. Process MeNtOR provides deliverable specific descriptions of the maturity and guidance how to determine whether it has reached this maturity. That makes maturities a good tracking tool for progress which can be easily graphed and displayed to the team and the customer.
The following diagram is an example of a snapshot taken during a real project, tracking the maturities of Use Cases. Because Use Cases have more natural maturity milestones, we use the colors of the rainbow instead.
