About the Blog

  • Software is our business, and perfecting the art and science of delivering it is our mission. The contributors to this blog are passionate about the impact that great teams and good software can have on an organization’s bottom line. They bring decades of experience designing, developing and delivering great software, and each is playing a critical role in Borland’s own transformation.

Blogging Authors

« Agile Testing: what does it take? Pt. 2 | Main | How agility drives product development - an inside view »

July 07, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.

David J Anderson

I had a similar back channel discussion with Stephen Palmer. We privately concluded that the Chickens and Pigs metaphor is not useful and I would go as far as to say really encourages dysfunction. I would prefer that we drop it from Agile altogether. In some ways, I am kicking myself for encouraging it with the article.


Stephen Palmer

I understand where David is coming from and at one level, I completely agree. Looking at an organization as a whole, you obviously want everyone working together as committed as possible to achieving that organization's objectives.

When you zoom in on particular activities, the situation is a little different. For each distinct activity, there will be people who directly contribute to the outputs of that activity. There will be others that contribute indirectly, and others that do not contribute at all but may still be interested in the output produced. At this level, the chicken/pig distinction does make sense to me. It means people contributing indirectly and those simply interested in the output communicate with those producing the output at well-defined points in the process.

To use another analogy, we know that the best way for client software to communicate with server software is via a well-defined interface. Similarly, the best way for clients of a team to communicate with the team is through the ‘interface’ defined in the process.

In addition, at this level of abstraction, people (actually roles played by people) should not simply be labeled pigs and chickens. That is to misunderstand and misuse the metaphor, and David is right to push back against it. A person in a particular role is a pig or chicken in relation to a specific activity.

Scrum and eXtreme Programming focus on the working of a single small development team and the ways they interface with requirement and project management. In this context, it is understandable that the developer role is more frequently a pig than chickens. Widening the context, the developer role is unlikely to be a pig in activities such as setting business objectives, for example.

There is an ‘us and them’ situation that often needs managing during a transformation between those in initial projects using the ‘new way’ and those still working to the ‘old way’. The ‘new way’ teams can become elitist and, some managers will actively encourage that for a time in the hope it will inspire others to want to join the elite, and so propagate the transformation. This, however, is not an appropriate application of the pig and chicken metaphor.

So in conclusion, viewing an organization from a distance, everyone should look like a pig but zooming in you have the surreal image of people metamorphosing from pigs into chickens and back again as they perform different activities in different roles.

Personally, I think for a process that takes its name from the game of rugby, Scrum would do better to follow through on the analogy of players, coaches, team owners, fans, etc than to mix metaphors by introducing farm animals via a very tired and not even particularly funny joke.


I'd go a step further and throw in Seagulls: http://7thpixel.net/blog/2009/06/11/chickens-pigs-seagulls/



I am remembering the first time I heard this distinction and was distinctly labeled a 'chicken' because I was not 'doing the work'. As a business analyst I was working all the time, defining requirements, grooming the backlog, etc, but it didn't fit in as work in the context of the agile development team. I found this a bit off-putting and the foundation of a new barrier between business and IT instead of trying to address the links between business and IT.

Of course, I understand that I was not "doing development work" and, as such, my work needs to be thought of a bit differently in the context of the sprint, but to me, this created an unnecessary distinction between the different tasks that needed to be accomplished for successful delivery.


Kelly Waters

Personally I hate the pigs and chickens metaphor. It's mildly amusing but does in my view encourage an us and them attitude and undermines the true nature of agile, which is inclusive and collaborative. The idea that someone is a labelled a pig or chicken, even in jest, or that some people are not allowed to speak does not have very positive connotations...

Kelly Waters
All About Agile

Raj Satya

Agile by design, forces developers and team members to a mind set where deliverable is quick. In reality critical resources get pulled into sustaining activity , especially in Startup kind of environment.
For sustaining issues, a new approach for "wicked problem" based IBIS is being studied for effective resolution and visibility into progress.
In this context, Not sure how well agile based new product development and sustaining issues work in practice.
Should critical sustaining issues be incorporated as Story and dealt in a day to day basis.
Any thoughts or possible project management approaches will be appreciated.

The comments to this entry are closed.