One of my favorite ProjectManagementPatterns, although it chills some people to their bones. It was originally called AllAtOnce, and posted that way on posted on http://members.aol.com/acockburn/riskcata/allatonc.htm, but that name never transmitted its intended connotations. I changed its name to GoldRush before putting it into SurvivingObjectOrientedProjects.) --AlistairCockburn
Here is the original version, in the medical metaphor format ( the precursor to CockburnPmForm).
GoldRush (AlistairCockburn)
Topic:
Sensation:
- If we wait until all the requirements or analysis is done, we will not have enough time to do the design or programming. (Alternatively: We applied TeamsIntegrateDiversity, what are our designers/programmers going to do while requirements and analysis is going on?)
Symptoms:
- Team members sitting idle because their upstream tasks have not been completed.
Forces:
- On the one hand, you want requirements to be done carefully. On the other hand, you have some information, and people sitting idle. You have done TeamsIntegrateDiversity, so the people have good communications with their upstream team members.
Try This:
- Let the downstream people start now. They have some idea of what they are to produce. Rely on the close communication within the team to take care of changes.
Counterforce:
- Letting a team get started early means rework. 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.
Examples:
- TeamsIntegrateDiversity already done. 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.
Principles Involved:
- The principle involved is that a process not constraining the overall system can afford to be done inefficiently and in parallel [Go]. 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 the above story, 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.
Related:
Reading:
Comments
Alistair adds (about names on the patterns): ...This project manager guy also reacted to the one I then called, "Rough Sketch", which I changed to, "AllAtOnce" and eventually GoldRush. Another pattern searching for a good name. He said, "We use Rough Sketch all the time" -- it turned out he thought it meant doing logical design before physical design. He read the whole page and never figured out it was just the opposite of what he did. It was only on my 3rd explanation that he heard the pattern, and then his eyes opened wide... So, of course, I changed the name immediately. Possible names I tried were, "Program Too Soon", "Implement Immediately", and others, all obviously unsuitable. Name suggestions are welcome for this one, too.
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. (I guess that this is another pattern that may resolve the problem.)
In the Jan/Feb 1999 issue of IEEE Software, SteveMcConnell writes about gold rush software development, and contrasts it with post-gold rush development. It is not exactly the same as this pattern, but pretty close.
How about GainExperienceEarly
CategoryPattern CategoryManagement
Gold Rush