Bob Haugen's SCRUM Pattern


To: OTUG@rational.com
From: "Haugen, Bob" <Haugen@mail.nexgeninfo.com>
Date: Wed, 13 Nov 1996 10:35:12 -0700
Subj: PullSystem - a pattern candidate

I am uncomfortable calling this a pattern, because I don't have enough experience with it in software development, but it is a fully-fledged pattern in manufacturing, where it comes from.

Candidate Pattern Name: PullSystem

Could also be known as: JIT Software Development
last update: 10-13-96

Problem: How do you handle the detailed specifications and scheduling for a SCRUM or Episode-type development project?

Derivation of terms: JIT stands for Just-In-Time, a manufacturing term and philosophy narrowly defined as "manufacture only the required quantity of the required items at the required time", and broadly defined as "eliminate wasted time and effort". A PullSystem is a simple signal-driven mechanism for synchronizing activities to accomplish JIT manufacturing. The essence is that synchronization is handled on-the-fly by the collaborating participants, not detailed out apriori. This candidate pattern attempts to apply the PullSystem idea to software development.

Forces: Complete upfront detailed specification and scheduling is impossible, because of time pressures or uncertainty. Symptoms of not handling the problem well: confusion, dithering, trying to stay busy, lack of focus, overengineering, featuritis (of low-priority features), paralysis of analysis, hacking blindly.

Applicability: PullSystems can be used as the main synchronization method of a project, or as a sub-pattern where complete specs and scheduling are impossible. Also, pullSystems can be used for micro-scheduling without being used for specs.

Preconditions: The team should probably be self-directed, responsible for its own policies and procedures. Somebody on the team should have decent knowledge of the requirements. A high-level conceptual design should have been done, on the order of Buhr and Casselman's Use Case Maps, with rough architectural partitioning into layers and sections a la Bobby Woolf's Envy Partitions pattern.

Solution: Establish a pattern of client-server relationships between programmers responsible for client and server software modules, where the client and server programmers negotiate and define the contracts between their software modules, a method at a time. This is sort of the reverse of the System-Resembles-Organization rule, where the organization resembles the system.

Implementation: Assign one or more team members to "own" each system partition, with one or more members also owning the requirements. The requirement owner defines the best understood important use case (or the least understood, if you follow that rule). This becomes the basis of negotiation between the requirement owner and the programmer responsible for the user interface for that use case. The programmer then designs and codes the user interface for that use case. Where the UI programmer requires services from other objects owned by other programmers, the UI programmer codes a method which sends messages to the other programmer's object. This becomes the basis for negotiation between the UI programmer (the client) and the server programmer, with the server programmer specifying the contract in Bertrand Meyer or some similar form. The server programmer then designs and codes the services required by the UI programmer, and repeats the contract negotiation pattern where services from other programmers are required.

The fulfillment and testing of the use case represents the consolidation of one episode in the sense of Ward Cunningham's Episodes pattern, which this pattern might fit into as a sub-pattern.

Then, the requirement owner defines the next best understood (or least understood) important use case.

Tentative hints: Don't try to specify too much up front. Do the specifications (e.g. API's between partitions etc) just-in-time as well as the code. Have them emerge from the contract negotiations between programmers. The API's that result may lack elegance, but they will tend to have the required methods, and only the required methods.

When a programmer does not have any pull signals (required work), do not "work ahead". Use the time to consolidate, clean up past hacks ("pay debts" in Ward Cunningham's pattern language), retest, factor-out repetitive code, and do other improvement work (such as creating and sharpening development tools).

If the partitioning precondition is not doable overall, do the partitioning just-in-time as well, use case by use case.

Examples: I have used pullSystems as the main mechanism on one medium-size Smalltalk development project with a team of 6 people, with excellent results in terms of productivity, quality and fun (but no "control group" for comparison purposes). There was a prototype to start with, and a fairly well known set of requirements. (This is a weak section of the pattern writeup, which is why I am calling it a candidate.)

Modified usage: I have also used PullSystems for parts of previous projects, where there was more upfront specification. I have also seen others use similar patterns for small parts or stages of larger projects: for example, negotiating the contracts between programmers and their modules for all or most methods as a stage of design, not negotiating them just-in-time method-by-method. (The contrast here would be between having an achitect design the API's, which the programmers would then code - as opposed to the programmers negotiating the API's with each other in their client-server roles.)

Tradeoffs: PullSystems could conflict with the "single-mindedness" or conceptual integrity of a system. Also, there are the usual risks of going down the wrong path. I do not mean to say that programmer negotiation is always better than architect design. And clearly they are not mutually exclusive - an architect could design the main features and set a pattern for object collaboration, with the details filled in using a PullSystem. Even in the radical version described above, there was a chief architect However, the chief architect sometimes interfered with the PullSystem, and was criticized for doing so. The advantages of the pullSystem were not only less wasted effort than similar projects I know about, but also a high degree of effective ownership by all the participants. In the example project, the chief architect left before the end, and the other participants took the project to successful completion without a "death march".

Related patterns: Ward Cunningham's Episodes http://c2.com/ppr/episodes.html and Jeff Sutherland et al's SCRUM http://www.tiac.net/users/jsuth/scrum/index.html development patterns, where PullSystem might be a sub-pattern. PullSystem works best in episodes, with consolidation stages between episodes.

Bobby Woolf's Envy Partitions pattern, a fuzzy version of which is a precondition for a PullSystem. http://c2.com/ppr/envy/

Robert Martin has a pattern (don't know name) where an Architecture team follows the coding team, doing the consolidation. It might fit with pullSystems.