Scrum's chicken and pigs parable

Chickens and pigs in Scrum

There’s a parable bout a chicken and pig that has long been associated with Scrum. It comedically uses a ham and eggs breakfast to describe participants’ level of involvement in an organization’s Agile transformation. According to the metaphor, in a ham or bacon omelet:

  • The chicken is involved (by supplying eggs).
  • The pig is fully committed (by becoming ham/bacon).

Who are the chicken and pigs in Scrum?

On a Scrum project, the product owner, developers and the Scrum master share responsibility for the project’s success. They decide how to allocate resources and how to develop the product. Immediate Scrum team members are the pigs. They are fully committed.

“In a ham and eggs breakfast, the chicken is involved, but the pig’s 100% committed.”

Stakeholders, customers, vendors, middle-management, and executives are all involved in the project’s success, but they’re just chickens. They provide insight, guidance, feedback, and direction. However, they aren’t as fully invested as the pigs.

Scrum’s ham-and-eggs problem

Scrum’s pigs and chickens parable is certainly a colorful metaphor, but you won’t find any reference to it in the latest 2020 Scrum Guide. It was included in earlier versions, but many Agile practitioners and Scrum community members found the analogy problematic for a variety of reasons, including:

  1. Implicit promotion of inequality.
  2. Lack of cultural awareness.
  3. Negative connotations and associations.

Inequality on the animal farm

Scrum masters work hard to promote a psychologically safe environment in which all participants are seen as equals and peers.

The assertion that some participants are fully committed pigs while others are less committed chickens creates a hierarchy of involvement. Hierarchies are antithetical to Scrum’s values and pillars that encourage open collaboration amongst all participants in the product development process.

Pigs chickens and Scrum values

Scrums pigs-and-chickens metaphor may go against its core values.

Unintended consequences

The last thing a Scrum team wants is an important stakeholder who holds back feedback or does not show up for a Sprint review meeting because they feel their opinions aren’t as valuable, since they perceive themselves as nothing more than lowly chickens.

Scrum is supposed to help tear down inter-department barriers and build integrated, cross-functional teams as organizations embark on an Agile transition. The chicken-and-pig parable linguistically does the opposite of that.

Lack of cultural inclusivity

Educators and advocates should always ensure that the metaphors and analogies they cite are cross-cultural.

Scrum already stumbled on the cross-cultural point when it linked its brand to the sport of rugby, which is popular in some regions but not globally known as, say, football (a.k.a. “soccer”). In some parts of the world, a chicken-and-egg breakfast might be a staple, but in other parts of the world it’s not as well-known. For that reason alone, one could argue, Scrum’s chicken-and-pig parable isn’t suitable for a global audience.

Negative connotations

People don’t like being called chickens.

People also don’t like being called pigs.

There’s a real possibility that a stakeholder will not understand the parable and take offense when they overhear someone calling them an animal. It’s best not to build lexical landmines into the defining document of a product development framework used by millions of people.

A better Scrum Guide

Scrum’s chicken and pig parable is an amusing anecdote, but it’s not without its shortcomings.

Under the right circumstances and in select company, it shouldn’t be seen as an offensive or inappropriate metaphor. However, it isn’t a perfect fit for Scrum.

The latest versions of the Scrum Guide have found better ways to describe the responsibilities of the Scrum master, product owner, developers, vendors, and other stakeholders in the product development process — all without labeling anyone a chicken or a pig.

App Architecture
Software Quality
Cloud Computing