Skip to main content
Environment: local

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.  Read Statement

Chickens and Pigs

The chicken and pig lore of Scrum is no longer a part of the Scrum Guide. Professional Scrum Trainer Steve Porter discusses the signifigance of what some may assume to be a relatively innocuous change:

As you're probably aware, Jeff Sutherland and Ken Schwaber recently published an update to The Scrum Guide, the definitive guide to Scrum. Many of the changes they made aimed to better define the rules of the game, and remove situational tactics. Some changes were large in scope and others less apparent. 

One particular change was arguably small and cosmetic, but it really has significance in my opinion. So much so, that I offered to write this brief article to explain why the change was made and how you can interpret these changes as you go about implementing them in your projects.

Every Scrum practitioner has heard the fable of the chicken and the pigs. I won't recount it here, but it is an embedded part of Scrum lore. Ken Schwaber created the pigs and the chicken metaphor in the early days of Scrum and it has been used repeatedly to separate the people who are committed to the project from the people who are simply involved.  

Over the years, the labels have generated their share of controversy. Some argue that the terms are harmful to the process because they are derogatory. Others say that the negative connotation conjures a power dynamic that drives negative behaviour. Either way, you won't find any references to animals, barnyard or otherwise, in the new Scrum Guide.

Why was it removed? Ken and Jeff felt it was better to discuss accountability directly in the Scrum Guide, as opposed to through metaphor. However, I think I can provide some additional insight. I was present at some of the discussions that led to the 2011 update and many people, including me, found that the labels were being used in a way that does not contribute positively to a team's ability to perform its core function. 

The labels were being used to create barriers between the Scrum team and individuals in the organization who potentially could assist the team in meeting its goals. Jeff Sutherland has been quoted as saying that, "… 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.” 

As a consultant, I witness many key members of an organization pull themselves away from a Scrum team with comments such as, "I know I'm just a chicken, so I can't say anything.” In some cases these people were key project sponsors or critical system matter experts. These are individuals who, while possibly needing some education and guidance from a Scrum Master, can be critical to the success of a project. The better the level of engagement you get from all of your stakeholders, the better off your project will be. By calling someone a chicken, it doesn't exactly look like you're rolling out the red carpet.

Another consideration is that Scrum, as a framework for delivering products, has come a long way. It's now used in all manner of organizations, including large, significant corporate environments. I welcome this development because I think there is great potential to improve the working environments of development professionals in these organizations through the use of Scrum. If we want to be taken seriously in these types of organizations, we need to make sure that we can communicate effectively with the various stakeholders with whom we engage. I welcome the challenge of working with a corporate executive in a fortune 100 company to help him/her create products of the highest possible value. I don't want to start that relationship by referring to him/her as small-brained fowl and myself as the animal that took over George Orwell’s Animal Farm.

So, where does this change leave you? Fortunately, the updated Scrum guide still makes a distinction between members of the Scrum team and those individuals who are part of the process, but not responsible for delivering products. However, the language has been changed. We still have the Scrum Team, but now the guide makes reference to "the organization," "employees" and "stakeholders" rather than pigs and chickens. 

The updated guide also makes it very clear that, "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.” For all the Scrum Masters out there who have to deal with intrusively engaged stakeholders, print out the new guide, highlight the appropriate passage and make it available early and often.


What did you think about this content?