There is a certain pattern of action we humans are almost addicted to. I say “addicted” because we keep acting this way, even though the pattern almost always fails. This pattern of action often shows up in Scrum implementations in large organizations.
This structure has three components: a list of nice things to have, one or more enforcement agencies, and a population whose job it is to produce, willingly or not, the things on the list.
Consider two examples:
– A software development organization develops a list of nice things for its software to have: documentation, unit tests, etc. It creates an enforcement organization, called QA, to ensure that the code produced by the developers has these nice things. In the agile community, we know that this structure rarely works.
– A financial system, likewise, can develop a list of nice things for financial institutions to have such as capital requirements, risk limits, and so on. This financial system creates various enforcement organizations, including government entities and public/private partnerships, to enforce compliance to the list of nice things. We know that this structure often does not work[1].
When cooking up Scrum in large organizations, the cooks follow a standard recipe quite like the aforementioned pattern. They create several pilot programs, and then capture the lessons learned from these pilots in the form of: a list of nice things to have. An agile advisory board is then created to enforce this list of nice things throughout the entire company. Every new team that implements Scrum is required to satisfy this list.
Given that this command-and-control structure has repeatedly failed throughout the ages at many levels of human society, I wonder why anyone considers it a reasonable way to implement Scrum.
References
[1] http://www.nytimes.com/2009/01/04/opinion/04lewiseinhorn.html