Your browser does not support JavaScript! SCRUM: Pigs and Chickens - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS


Pig Snouts at bullysticks.com

Ken Schwaber started the pigs and chickens story in the early days of Scrum. The terminology is now under deep discussion in the newsgroups:

A chicken and a pig were brainstorming...

Chicken:

Let's start a restaurant!

Pig:

What would we call it?

Chicken:

Ham n' Eggs!

Pig:

No thanks. I'd be committed, but you'd only be involved!

The real issue for a Scrum is who is committed to the project and accountable for deliverables. The committed get to talk at the daily Scrum meeting. They are the pigs and their butts are on the line. We could call them contributors if we don't like pig terminology.

People who are not committed to the project and are not accountable for deliverables at the meeting do not get to talk. They are excess overhead for the meeting. They might be called eavesdroppers if you don't like chickens. Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others. Sorry to be political incorrect but others should come up with a euphemism that conveys the right balance between being "nice" and communicating clearly that eavesdroppers must minimize their impact on the productivity of the team.

If you look at most corporate meetings you will see 50-80% excess overhead. These are the meetings that Scrum eliminates on day 1 if done properly.

Most of excess overhead will claim they need to know what is going on because it impacts their work in some way. They don't need to know what is going on in the Scrum. They need to be able to see a visual representation off the backlog that is updated daily, preferably automatically on the web. At the end of the Sprint, they get to go to a demo where they can see exactly what went on, can provide their input, and can influence the next Sprint. This is where they can provide a real contribution.

One of the biggest challenges Ken and I had in various companies where we worked together was stopping members of Scrum from going to any excess overhead corporate meetings because they were one of the biggest suckers of productivity from the team. People that like to go to these meetings are often seen in a Scrum whining about not completing their deliverables because they were at such meetings. A well running Scrum has an immune system which expels such people who don't deliver over time.

Maybe we should call them barnacles, because like barnacles on a ship, they will sink the ship if they accumulate. It is good to have some negative connotation in the terminology, no matter what we call it. People will not change their behavior if they do not feel an emotional impact.

All of this needs to be handled firmly, impartially, and impersonally. A good ScrumMaster handles this effectively, tactfully, and persistently. S/he effortlessly converts barnacles into real contributors.

On occasion, there are people who have their jobs on the line if the Scrum doesn't deliver. These people have sometimes been welcomed into Scrums during critical periods. They are usually line managers or product managers who have a contribution to make - clear reiteration of the business objective and real time comments on the potential business effect of decisions in the Scrum. It seems to work best if they speak only for a minute at the beginning or end of the Scrum and the Scrum feels free to assign them work, particularly assignments to eliminate bottlenecks that are impacting Scrum productivity. They are expected to report on such deliverables in the Scrum (particularly if they are the Senior VP of Engineering or the CTO).

We have some litmus tests here on how well the Scrum is doing:

1. Are their barnacles present? Bad, productivity is being impacted.

2. Is the Scrum acting to reform them or eliminate them? Good, the immune system is functioning.

3. If there is any management present, are they assigned tasks by the Scrum? Good, the Scrum is functioning autonomously.

en_USEnglish
Shares