The difference between Chicken and Pigs!

No! It is not the color or taste of their meat.  Pigs are committed and chicken are simply involved in SCRUM.  So here is the joke:

"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."

In SCRUM a pig puts his bacon on the line! A chicken is only merely involved.  Well, I do like SCRUM but this business of chicken and pig is really annoying to me!  It reeks of IT arrogance and it really explains why IT still does not get it.  The customer is not a chicken! And the product owner is not a pig.   And why for God sake do we even need to differentiate roles in agile software development based on these analogies.   The theory here is that the chicken (stakeholder or the customer) need to only be involved during sprint review!  And the pig (product owner or scrum master) is the one with the bacon on the line.  Do not get me wrong! I like SCRUM and I have been avid supporter of the approach.  But this business of pig and chicken to me is not only naive but also presumptive on IT's part. 

Customers are not chicken and product owners are not pigs! At the end of the day everyone involved or committed or merely is a part of the team on both sides in business and in IT is on the line for the service being published or consumed.   But human nature is always focused on drawing lines and boundaries and painting different colors to establish control mechanisms! I personally prefer to think of Tai Chi's push hands excercise or maybe Zen practice! 

Comments

[Ajay Gupta]

Interesting post, Nida. Following are some thoughts I would share with you:

1. I agree with you whole heartedly that a customer should just be involved in the inception phase of the project. I personally don't agree with drawing boundary lines around business and IT as it simply creates more rifts and artifical boundaries of communications within the same organizations and most often also limits collaboration which is such a key component while using a methodology like SCRUM or XP which both heavily depend on collabration between team (IT or Business).

2. In the past, when I have used the notion of "Chicken" or "Pig" in a SCRUM context, we would use those terms at the daily Scrum meetings to distinguish between people who had something significant to report in the status (a pig) vs. someone who did not get anywhere with what they were working on (may be, they were working on a proof-of-concept and could not make any breakthroughs yesterday) - that's a chicken. This term would be applied based on the daily contributions rather than to distinguish roles of different people involved.

3. Most agile methodologies talk about iterative and adding value added features (or stories) in an incremental fashion. I agree with this but unless you talk about an "iterative deployment" approach and actively engage your customer on the testing of the features that you are delivering, all you are doing is building an "increasing" pipeline of features for them to test. This proves no value and makes use of an agile approach ineffective. If the user cannot test your application, they cannot provide you with the rapid feedback which in turn makes any agile methodology smell like Waterfall.

Thanks