The case against Chickens and Pigs

Schwaber and Beedle's Scrum book introduces the pig and chicken fable to illustrate a point. It goes something like this:

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 story is used to illustrate a difference between
a) the core team members - the "pigs" who are committed to the success of the project (blood sweat and tears maybe?) and
b) outside contributors - the "chickens" who contribute but are presumably not "sacrificing" for the cause

First - I think the analogy is confusing. I always have a hard time explaining it and I haven't heard a coherent verbal description of the concept. There's got to be a better way to make the point.

My higher purpose here, however, is to extinguish the point.

A commonly cited rule is that "only pigs can talk in the stand-up". There is an underlying premise here that anything a "chicken" or non-core team member has to say is wasteful of the team's time. A corollary perhaps: anything a core team member has to say is important.

I have participated in stand-ups where chicken "contributions" have been extremely valuable. Example:

pig: "My computer monitor froze last night; I need to order a new one"
chicken: "Stop by my desk after stand-up. I have a spare"

pig: "Today, I'm meeting with the product owner to review stories for the next iteration"
chicken: "Product owner is out sick today. Let's talk after stand-up about rescheduling or doing it remotely"

Or how 'bout a chicken who participates in the stand-up and shares relevant information. Maybe the normal contribution is "pass" (meaning - there's nothing of import to the team to share). But maybe she's got something important to say:

chicken: "Yesterday, I met with a group of 6 customers to review the prototype. Feedback was overwhelmingly positive. They had some good suggestions. Today, I'd like to sit down with Joe to review some of them and get stories added to the backlog".

What a great contribution to the stand-up! The team gets a valuable shot in the arm (positive feedback) and Joe gets a heads up on some work for later that day.

I've also witnessed many examples of core team members' verbosity and sharing unimportant information.

pig: "Yesterday I had a one-on-one with my manager and worked on my mid-year performance review"

Huh? It seems that this information is being shared not for the benefit of the team, but to justify someone's paycheck for the time they spent in the office.

pig: "I ran into an issue when creating the xyz service. When I compiled the code, I got an Exception in the compiler. I stepped through the compiler assembler logic, but couldn't figure anything out. I then spent about an hour on Google looking for the cause. I finally found this bizarre reference in a Japanese website - thank goodness for Google translation - but it's kind of funny how they botch the translation, I mean, it's not exactly the King's English. Anyway, I translated it, and found someone had this issue because they were running service pack 1 of the IDE without the next two patches on a MacBook Pro running Boot Camp. I installed the patches and still had the problem. I tried a bunch of other things after that and finally got things working. I think clearing the cache did the trick. I thought I'd be done yesterday, but that issue set me back a bit. Barring any other bizarre issues today, I expect to be done with the story by end of day.

OK, I made all that stuff up. This guy needs some coaching on being more succinct. There's some valuable info in there ("hey everyone - make sure you have those two patches", and "I should be done today") but it's buried in irrelevant detail.

My general point is this: I think the chickens/pigs designation is more harmful than helpful. Common sense - about what's valuable to share - should carry the day. Open and honest conversations with *all* participants about expected behavior in stand-ups and beyond should trump this arbitrary dividing line about whose voice should be heard when.