The story has been written by Ken Schwaber, one of the contributors to the Scrum methodology. 

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs?’” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

This fable has been used in order to describe the two types of project members of an agile team:

• pigs, who are totally committed to the project and accountable for its outcome. For a Scrum project, for example, the development team, the Product Owner and the Scrum Master are pigs;
• chickens, who aren't commited but only involved and, as such, not accountable for any specific deliverable. Keeping the same example of the Scrum team, the chickens are the different stacke-holders and managers that might be involved, i.e.  consulted on the project and informed of its progress, but not commiteed as not accountable for any specific work.

As of 2011, the fable has been removed from the official Scrum process. And with good reasons as it didn't give a very positive and enviable image to it. But while the Scrum apologists don't like to much the chicken and pig mataphore, at such a point that they removed it from the Scrum folklore, the story shows however a reality that any Scrum, or other agile practitioner, should be aware of.

If you're like me, then you've certainly noticed that, at your daily stand-up, there are two categories of participants: the ones talking about theirself and the ones talking about the others. The first category are pigs. They talk about what they did, what they didn't do, why they didn't do what they were suposed to do, what kind of issues preventing them to do their job they meat, what they we'll be doing tomorrow, etc. They are commited. The second category are chickens. They are talking about what meetings they have attended, what the other guys in the meetings said, what did they hear about different events that might affect different enterprise aspects, what kind of decision has been taken in this or that department, etc. They aren't commited as they don't have any precise goal, any defined result to attend, they are just involved, meaning that they are talking about around, they are asking questions, most often irrelevant and time consuming ones, etc. They need to be informed by the others, the pigs, because by themself they aren't able to find the right information.

This sketch of an agile team gives a very unequal and undemocratic view of how things happen in the nowadays digital enterprise. This goes back to the Agile Manifesto very ideological stance, where personal opinions are turned into a dogma, as this is often the case with "manifesti". But more then a dogma, the Agile Manifesto is an utopia.

The most utopian point of the Agile is probably its allegedly leaderlessness.  Did you ever see an orchestra which is not guided by a conductor ? I'm not talking, of course, about a band formed of 4 - 5 guys, but about a real orchestra. However, as surprizing as it might be, there is no such a thing like "project manager" in Agile. This means that the team leads itself ! Such a team is supposed to work as a "band of brothers and sisters" and to put mission first. And in order to provide self-organization, the team members need to be colocated, even at the cloud era and, sometimes, to share the same keyboard, mouse and screen. The colocation is also supposed to guarantee that the team members are fully dedicated and permanently available.

This so-called self-organization is, in fact, a transfer of a significant quantity of work from the chicken area to the pigs one. I a traditional project, the organization is the work of the project managers, i.e. a full time work. This role is considered, for some reasons, as being a non directly productive one, nevertheless is requires a high commitment and, often, much more than 40 hours weekly. Project managerst throw themselves on meeting grenades so that the team can actually get work done. The number one goal of any competent Project Manager is to shield their team from as much of this organizational overhead as possible. So, how is than the self-organization supposed to work ? How is the agile team supposed to compensate the fact that there is no longer anyone to the Project Manager's job ?

If you're like me, then you certainly have heard many times stacke-holders and line managers saying to developers (the pigs), who were chanlanging them in the organization field, something like: "You need to organize yourself. We're doing agile here !". Agile became the ideal alibi for the managers and stacke-holders to flich from their obligations and responsibilities. Previously, in the context of traditional projects, they were responsible to organize things but now, with agile and the so-called self-organization, the became free like birds to roam around the institution, from meeting to meeting and discover adventure, without any pressure of milestones and deliverables. The result is that managers don't manage any more, while developers aren't given the required resources to coordinate themselves. Consequently, when delivery dates become pressing, i.e. most of times, instead of coordinating itself, the team is disorganized.

But things are even worst when it comes to documentation. Not only agile became the prefered management alibi to avoid doing its fundamental work but, additionally, if you are like me, you certainly have heard many times that: "We don't have documentation 'cause we're doing agile". This also goes back to the Agile Manifest which says: "Working software rather then documentation".

This sentence of the Agile Manifesto was probably the most criticized one. What "working software" might mean if there is no documentation explaining how everything is supposed to work ? How could a software tester decide whether a piece of software works if there is no any test plan ? 'Cause test plan is documentation.

Here again, the agile apologists have explained that the expression "rather than documentation", didn't mean no documentation at all, but spending less time in writing documentation, not trying to define everything from the beggining, doing it in several iterations as opposed to a water-fall process. Well, our friends, the chickens, didn't understand things this way and, since pigs were already renowed for not being very good at writing documentation, the result is that most agile projects have only the code as the unique source of information.

But the most important impact that agile methods have had on software development projects concern their architecture and design. If we take Scrum as an agile method example, then the work is done in sprints. The sprints content is decided based on the back-log. But the back-log is drafted in terms whic make sense to the Product Owner and to users. These terms come from epics and user's stories and they express users concerns. They are expressed based on templates like: "as a user, I would like to have a function able to ...".  Consequently, the back-log and, with it, the sprints, are drafted in functional and business terms. So, what about software architecture and design ?

If you are like me, you know that the success of a software system depends on the reliability and robustness of some basics components, often called framework. Things like distributed processing, remote access, security, transactions, race conditions, data persistence, high availiability, etc., are the role of this basic components called framework. What is the place of the framework in the back-log ? Well, probably none.

Scrum finished by recognizing the importance of the framework and it added the so-called "sprint 0" which is supposed to deal with this components. But the "sprint 0", as viewed by Scrum, is an initial phase of a couple of weeks in which software architects and designers are supposed to agree on a framework. This framework couldn't then change during the whole project life-cycle, because this would block the sprints. This is a very simplified and even naïve view of things to consider that topics of that importance could be decided, one for ever, in the "sprint 0". The Scrum method has evolved since its begginings and, nowadays, it recognize the importance of the so-called "agile architect" supposed to be in charge of the software architecture and design across sprints and to guarantee the change management. This role is somewhere between the pigs and the chickens and most of the Scrum teams don't provide a formal definition of such a role. Hence, no one in the team has a long term vision of things such that to assure a real technical leadeship.

Thus, as time goes by, the organization finds itself with a code that was being written with a tunneled vision of the system, by ignoring the wider system and by ignoring what’s coming in the future. There will be no framework in place, no standard practices, each part of the code will be written with different assumptions in mind because each of the developers have different ideas. The modules will not be scalable.Making a change in the code becomes a nightmare and implementing simple features takes a lot longer time than expected. The chickens then begin to wonder why the pigs are unable to deliver at the same speed as in the beginning of the project. The scrum master goes crazy over why the team’s velocity is dipping with each sprint.

 If you're like me, you know that this chickens/pigs paradigma illustrates kind a modern-day-slavery where pigs sacrifice their lives for the project, whereas chickens only have to give up their eggs. This is not only a terminology matter. You can replace these terms by others like players/spectators, contributors/observers, commited/interested, forwards/backs, active/passive, etc., but the deep nature of the dialectic relatyionship stays the same.