A Structure That Rarely Works

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.

[1] http://www.nytimes.com/2009/01/04/opinion/04lewiseinhorn.html

Michael de la Maza

I am an agile coach and an angel investor. As an agile coach, I have consulted and trained at dozens of companies. Major agile coaching engagements have been with Paypal, State Street, edX, Carbonite, and Symantec. I typically begin with culture first and then proceed to process improvement and business results. I believe in a non-confrontational, non-coercive approach to change in which people are invited to be and act in a new way. This takes the pain out of agile transformations.

With Rob Rubin, an online education pioneer and the Founding VP of Engineering at edX, I recently created DemingWay.com, an online agile education portal that we plan to grow until it has the best agile content and the best learning platform.