People don't use the pigs and chicken metaphor in Scrum much anymore. I tend to agree with the reasons for avoiding it - it tends to create an Us vs. Them mentality.
Us is the Scrum Team, or the pigs. The "committed" individuals who are responsible for delivering the solution. "Them" is anyone else - the chickens. The chickens are only involved and not committed like the pigs.
The idea was that the committed individuals had a lot more at stake than those who were simply involved. Those committed individuals are the ones who will be accountable for the results. They should have more rights in terms of power and decision-making ability than those who were simply involved.
I meet people who still use the pigs and chickens story with Scrum teams. However, most people don't. Both of the founders of Scrum stopped using it and removed it from the Scrum Guide in 2011 because it perpetuated the Us and Them mentality. It was also considered offensive and derogatory and it divided people unnecessarily.
I agree. We already have enough problems with division of people which dilutes the power of Agile and Scrum. Within our Scrum Teams, we frequently have specialized subteams like the BA team, or the business team, or the product team, or the testing team. We callously label people as offshore to distinguish them from the onshore team. We have developers of all stripes - front end developers, backend developers, data developers and application developers. And we have divisions between employees and contractors, with some organizations making it very clear who is who by the color of the badge each wears.
It is pretty difficult to create a high-performing team unless everyone considers themselves a committed team member first. The divisions and subteams only lead to suboptimization, lack of end to end ownership, and ultimately blame if things don't go well.
There was one thing that I liked and thought was valuable about the pigs and chickens metaphor. It was the idea that the individuals who are doing the most work should have the lion's share of the decision-making power. That the ones who are in the trenches, with their sleeves rolled up and committed to deliver should be the ones who make the decisions. They are usually the ones who have to live with the consequences. Here are some specific examples.
1. Estimating - The team that is going to do the work should provide the estimates for the work.
2. Deadlines - The team that is going to do the work should provide forecasts (i.e. best guesses) of when things might be completed. Deadlines should not be imposed by others. If there are legitimate deadlines, the team should forecast what scope may be accomplished by the deadline. And others shouldn't treat the team's forecast as anything more than a best guess - it's not a contract and never should be treated like one.
3. Self-Organizing and Working to Capacity - The team that is going to complete the work should be the ones to decide how they will do it. And they should decide how much work they will take on.
In my training classes, I get a lot of questions from people who are not really Scrum team members, yet who want to control and make decisions for the team. Frequently they are coming from a project management background and they are used to directing others and being in charge. Or, they are accustomed to being the go-between for the team and the end customer. They talk about the importance of their role to push or drive teams to perform; what they want is a high performing team. They can't envision leadership within the team. They don't imagine a world where teams themselves develop and communicate estimates and plans to stakeholders.
I see the same behavior when coaching in organizations. There seems to be no end to the line of people waiting to tell the team how to do their job. They act superior to the team, second-guess them, and they undermine the team's performance by making decisions, telling them what to do, and disempowering the team.
Exasperated, I sometimes resort to explaining the pigs and chickens story because I don't have a better way to say - "hey, let the people actually doing the work make the decisions".
Wow, I think I just said it.