Alias: PartialEvaluation
Get ready...
Go!!!!!
During one study, I asked the organization to describe how they develop software. "Well," they said, "project management gives us a list of features they want estimates for. So we start working on the features we think are the most important. Over time, they ask for more detailed estimates, and the features we are working on have smaller estimates, because they are underway. Those features generally make the cut. By the time we get official approval to begin development, we are nearly finished."
....you have a good idea of a market need and, furthermore, a good idea of how to get started on parts of the project. You're eager to get started but want to proceed deliberately and by the path that will be both expedient and productive.
✥ ✥ ✥
You can't wait until you have every last requirement to get started.
Team members are sitting idle because their upstream tasks have not been completed. On the one hand, you want requirements to be done carefully. On the other hand, you have some information, and people sitting idle.
Therefore:
As soon as you have confidence about some project direction, start developing areas in which you have high confidence. These may lie in the area of hardware development (or procurement), algorithm development, database schema development, etc. Let each subgroup work according to an InformalLaborPlan as if they were in full-swing development.
Note that "high confidence" refers to project direction and requirements, not technology. It's perfectly all right, and in fact desirable, to work on the technologically risky areas first (see BuildPrototypes.)
Give yourself some room to retrench later as requirements become more clear.
✥ ✥ ✥
In many projects, behavioral requirements are one of the last things that the designers get right. Many projects ship their first release with only basic requirements met, with economically more significant requirements met in subsequent releases. Telecommunications systems often follow this pattern, offering basic communications systems in early releases and more advanced features later. In fact, behavioral requirements are often overrated in their impact on the overall structure of the system; the code that meets behavioral requirements often lives in application code that is added very late to a robust stable base. The base reflects deep domain knowledge more than it reflects behavioral requirements. There is much common code that can be done early on with high confidence: code that supports common domain functionality that is part of most systems for a given market. This code can often be started or acquired before requirements are firm.
This pattern can increase rework, but it is more in the spirit of piecemeal growth architecture than would be a master-planned system that precipitates from "complete" requirements. It is likely that any false starts will also be educational at the enterprise level. In fact, as a risk management measure one can consciously decide to not commit to the results of such an activity. On the enterprise level, this becomes the pattern SkunkWorks; with a project, it is BuildPrototypes.
There are two occasions in which you cannot tolerate that rework. First, if the task is the process bottleneck, it must work at peak efficiency, and rework should be minimized. Very occasionally, the rework will take longer than the original task, and so this pattern should not be used.
Teams need good communication with their upstream counterparts through patterns like HallwayChatter and ResponsibilitiesEngage to make this work.
The principle involved is that a process not constraining the overall system can afford to be done inefficiently and in parallel. It is often the case that the analysts, designers and programmers can get started right away, without having finalized requirements. Serializing their work will take longer than doing 10-20% rework. In one group we studied, the database group constrained the process. They could not afford rework, and had to work in the most efficient way possible. Therefore, they did not start early, but waited until their requirements were stable. The designer/programmers had enough extra time that they could afford to prototype some test databases for themselves, which were thrown away when the database designers did their final design.
See [BibRef-GoldrattCox1986].
Examples:
Each team had 1 requirements & analysis person, and 2-3 designer/programmers. Database design was understaffed and constraining the process, so it was made a special service group given final requirements only (the counterforce). A first cut at the requirements had been done earlier, so a rough set of requirements were available. Much of the system was similar.
The designer/programmers quickly got ahead of the requirements people, who were busy in meetings trying to nail down details of the requirements. If they waited until the requirements were solid, they would not have enough time for to do their work. They were able to guess quite closely what the requirements would be like, without knowing final details, so they started design and programming right away. The requirements person gave them course corrections after each meeting. The amount of time it took to incorporate those mid-course alterations was small compared to the total design time.
This pattern comes from Alistair Cockburn's original pattern AllAtOnce [BibRef-Cockburn1996], which was later modified and renamed GoldRush [BibRef-Cockburn1998]. The alias name "PartialEvaluation" comes from the inspiration that this is a temporal form of DivideAndConquer. The name "GetOnWithIt" arose when we discovered that the name the pattern bore at that time — JustDoIt — conflicted with another pattern written by Jeff Garland. Jeff suggested the current name.
Shalom Reich writes:
The "AllAtOnce" pattern appears to be a typical Project Management "crash project" approach. In a "crash project" one must be careful to identify true predecessors for each task with the goal of reducing the "critical path". This allows parallel efforts to proceed which will all "come together" at the last possible moment. I have found that project plans often contain false linkages between tasks. For example, in one large project we had a "specification" phase. I was able to break the project into several smaller projects which each had its own specification phase. This allowed me to juggle my limited resources and have coders working on the part that went first through the specification phase at the same time that the analysts were working on the specifications for the second sub-project.