Ok, if you’ve not heard the joke yet, here it goes. The chicken suggests to his friend the pig that they open a restaurant called ham and eggs. No thanks, replies the pig, while you would be merely involved, it would require my total commitment.
Accordingly in the Scrum methodology, the pigs represent the core team (developers, testers, documentation writers) who are so labeled because of their total commitment to the project. Other stakeholders are called chickens because they are involved but not totally committed. In the daily scrum, a project meeting that starts each day, the pigs may speak but the chickens must stay quiet. So it’s oinks ok, no clucks allowed.
Scrum is very popular for projects that result in products. But let’s consider a project intended to improve a business process. The developers, who may well be consultants, create the software and then move on to another project. The stakeholders must live with the software to get their jobs done on a daily basis for years to come. Who here is totally committed? I’d suggest that the pig and chicken roles are reversed: stakeholders are the ham, developers the eggs.
So is scrum kosher for process improvement? Certainly, I don’t like the implications of telling stakeholders that they are mere chickens. I want to increase their commitment, not limit it in any way. And in cases where developers are using rapid application development tools and can and should reach out for constant stakeholder feedback, I think even the notion of a sprint breaks down.
This is not to argue that the basic principles of Agile do not apply to process improvement but just to say that not every Agile methodology is as applicable in every situation. But I guess that is implied in the notion of agility itself.