Pickens and Chigs
Virtually every Scrum practitioner knows the story of the Chicken and Pig. With time you learn that some practitioners adopt a Picken and Chig behaviour. Here are some clues to find out whether such hybrids have evolved in your organisation:
You probably have Chigs if:
- Some team members do not attend dailies
- Some team members excuse themselves from retrospectives
- Some team members attend dailies, but do not participate in the rounds
- Some of the team’s work is regularly done by non team members, such as experts, that do not see themselves required in ceremonies
- The Scrum Master is responsible for Sprint Reviews
- The Scrum board and Burndown chart does not get updated if the Scrum Master does not update them
You probably encounter Pickens if:
- Your Product Owner participates in effort estimations, although he/she is not knowledgeable about how to make the software or product
- The time of the Daily Scrum depends on the availability of non team members, such as the Manager or a Quality Champion who’s not on the team
- Experts, such as managers or architects, make decisions on behalf of the team
- Team members feel frequently dependent on other teams, such as infra
You probably have examples of your own of such hybrids, who are neither team members nor not team members.
So, what to do?
One possibility is to map out the involved individuals according to what role they play for the team. Then let the Pigs say what they would like to do with the various hybrids. Here’s an example:
+---------+----------+-------------+ | Who | What | | +---------|----------|-------------+ | Abe | Pig | | +---------|----------|-------------+ | Sarah | Pig | | +---------|----------|-------------+ | Isaac | Pig | | +---------|----------|-------------+ | Becky | Picken | Into the sty| +---------|----------|-------------+ | Jack | Chig | To the coop | +---------+----------+-------------+
The rule is that anyone that enters the sty with the rest of the pigs must play with the pigs – attend the ceremonies, get their hands dirty in making products, commit with the rest. The ones that go to the coop can play with the chickens, but are asked to kindly not interfere with the pigs.
Why is this important? Because for teams to become autonomous, self organised, self learning, all the good stuff you want from a Scrum team, they need to feel safe in their sty. And chickens should be chickens.
Becoming agile 
Great again!!
I would question your categorization of the Product Owner as a non-team member. The Scrum Primer says this about Scrum teams:
“In Scrum, there are three roles: The Product Owner, The Team, and The ScrumMaster. Together these are known as The Scrum Team.”
@Thom, good point! That being said, a voting Product Owner, that consistently votes low by undermining the size of stories, and is considered more senior in the organisational hierarchy, may create a dysfunctional team. Sometimes this will be manifested in low morale, at other times it could be compromising quality in order to meet commitments or forecast.
By all means, if the PO is seen as getting his or her hands dirty, and has an equal stature in the team, it only make sense to classify them as a Pig.
Thom, I have re-read my post last night, and realized that indeed it was too biassed towards PO not being a team member.
I stand corrected – and changes the post accordingly.
Thank you for pointing this out!
I would question your categorization of the Product Owner as a non-team member. According to the Scrum Primer:
“In Scrum, there are three roles: The Product Owner, The Team, and The ScrumMaster. Together these are known as The Scrum Team.”
Always good to have snazzy names for lengthy-to-explain-syndromes. Thanks 🙂
Thank you, Shreesh. I found that it helps bring a smile during the discussion, and breaking resistance.
However, in retrospect I also found that Chig is also an offensive term, so one should be also aware of the cultural context
On the Product Owner being part of the team thing – I agree that they are Scrum team members and I think that they really get there hands dirty (or should do). The PO is a key role without which the team cannot function and they should be right in the thick of the action.
Perhaps the difference is in what we consider “getting your hands dirty” really means though? For developers and testers it is obvious – writing tests/code/testing/design etc.
But a PO gets their hands dirty in other ways. E.g. They drive requirements sessions (writing stories) and often have to work across multiple business stakeholders to ensure all requirements are identified and requirement clashes are sorted. They have to participate in Release and Sprint Planning sessions by explaining and discussing the requirements and shaping the solution (remember the team can propose technical solutions but the PO has to understand all the ramifications of different options and the impact on the business – which is not always immediately evident. The PO also has to prioritise and re-prioritise. Then there is working with the teams during development – answering the questions, taking away issues and exceptions and sometimes sitting down with devs to design screens, validation, etc, etc. Then there is the acceptance and feedback on the resulting software, running demos to the wider business, discussing user type documentation/business processes and how the features may be implemented into possibly very large business communities of users. Not to mention producing business cases/justifications for developments, product strategy, understanding business policy and so on.
Now that is getting your hands dirty!!! BTW – I am not a Product Owner but I think you have to very much respect the role!! In large organisations with multiple complex products it is an almost impossible job and is where agile scaling to large organisations has all the issues. The technical is easy by comparison I would suggest.
@Mike, I have re-read the post (following @Thom’s comment) and realised my miserable mistake.
I hope you like how I revised the post.
I love this!
Nice way to make a spoonerism WORK!
Thank you, Stacia!