The Risk Management Catalog

(Part of the Risk Management Catalog , located chez Alistair Cockburn, Humans and Technology, acockburn@aol.com )

2. " Sacrifice One Person "

Submitted by: Alistair Cockburn, Humans and Technology, acockburn@aol.com 801/943-7772.

Chapter

Distractions (Progress, Productivity)

Sensation

This is a distraction to our primary purpose. We are losing precious design cycles.

Symptoms

The project is not moving forward as it should be, because there is some important interruption taking time from all the team members. This is a special case of Team Per Task in which the secondary task is some form of interruption which can be handled by one person.

Forces

On the one hand, you cannot drop the distracting task, it is somehow very important. On the other hand, it is keeping the team from moving on its primary task.

Try This

Assign one person, ideally, to the distraction, otherwise as few as possible. Let the rest of the team move forward at full speed.

Counterforce

If this keeps happening, you will have no one performing the primary task, and you ought to examine why you have so many distractions in the first place.

Examples

Situation 1: Scheduling Progress came to an halt when it was decided that the schedule was out of date. We thought that each person could best evaluate their own work over the next several releases, and that it would be fair to spread the discomfort and experience of work estimation. What happened was that there was no progress on the system, and when they got back to designing, it was a month later and they had to start up again.

One team applied Sacrifice One Person, fingering one person to do the team's estimation while the others got on with the main task. At the end of several weeks of estimation, that team had moved forward while the other teams were at a standstill. Thereafter, every team applied the pattern. Eventually, one person was made responsible for maintaining schedule information for the whole project. Each person working on the schedule really felt sacrificed. This pattern was originally called the "Scylla Variation", for reasons obvious to readers of The Odyssey.

Situation 2: Going through test As in Team Per Task, one person was assigned to walk a release through test (Sacrifice One Person is indeed Team Per Task applied to small teams). The person assigned to test felt sacrificed; the rest of the team was happy to make progress.

Principles Involved

The principle involved here is to protect the main task, where constant progress is paramount. In Situation 1, above, it was not that the design teams were complaining of the loss of flow during design - they were simply not doing design, because of the need to do scheduling.

(Up:) Team Per Task (Down:) -none-

Reading

-none-

Comments

Ralph Johnson writes: "Sacrifice one person" is not a good name. You need something more positive. How about "Horatius at the Bridge", in honor of the brave Roman who held the Etruscans back from the bridge while his comrads chopped it down, and so saved Rome. He survived, though with the loss of an eye.

Alistair replies: ...Several of us (like Doug) have tried coming up with other names for "Sacrifice One Person". It is interesting to me that we feel obliged to come up with a *positive* name... why is that? I showed these patterns to a project manager here in town, as we were colluding on a large project, and at Sacrifice One Person, he said, "Oh, I use that one frequently." Which leads me to think that Sacrifice One Person is not a bad name, because he understood what it meant, which he wouldn't with some of the alternative names we have tried, like "Atalanta variation", "Scylla", "Altruism". Doug suggested Atalanta, which stuck for a while, until I tried to write it down, at which point it became clear it was backwards. So, I can't think of an accurate, positive name that people will understand - actually, I think the idea is fundamentally negative, and that is how it is perceived ("let's sacrifice Ed to the schedule..." "No! No! Please...no!...arrrgh...!"). At the same time, I am happy to keep getting suggestions for it.

Jim Coplien notes that Sacrifice One Person is very similar to his Alistair replies: Firewalls calls for creation of a manager role to reduce the flow of unwanted information (distractions, interruptions) into the team. To a person not wishing to be a project manager, it is indeed like Sacrifice One Person (that is like saying the scientist has been trained by the rat to produce food whenever a bar is pressed...). To the person who wants to be project manager, it is not a sacrifice at all, and there is nothing temporary about the assignment...

Oh, I get it - I wrote the pattern so generically, I forgot to think about the transitory nature of the assignment! Is it still Sacrifice One Person if the person wants to do it and it turns into a full-time job?

I don't think the Sacrifice One Person example of assigning test fixes falls into the Firewall pattern, and I don't think the example of hiring a project manager falls into the Sacrifice One Person example... so I think the two address different risks.

Shalom Reich writes: Per the lessons from Organizational Behavior I added to Risk Management Catalog front page In Team Per Task and "Sacrifice One Person" the organization (the development team) is dealing with external complexities that threaten its ability to do its assigned task (develop SW). In each case a liason is created (the size varying in the two patterns) to encapsulate this complexity. Here, if the person sacrificed isn't happy you will run into a motivation problem (which may in turn give you high turnover).

Scheduling feedback is always a problem. One place I worked for got around this with some simple procedures involving weekly status reports. Procedures can often be substituted for skills when the tasks are repetative (again from OB).