Scrum is a Cargo Cult

One of the advantages of Scrum is the The Scrum Guide™ which provides an easy to understand and cookbook like recipe for implementing it. This however is also the biggest threat of Scrum. It lets people believe that they can successfully become agile by introducing the roles, events, artifacts, and rules described therein. This is exactly what a Cargo Cult is:

The term “cargo cult” has been used metaphorically to describe an attempt to recreate successful outcomes by replicating circumstances associated with those outcomes, although those circumstances are either unrelated to the causes of outcomes or insufficient to produce them by themselves.

– Cargo Cult on Wikipedia

Applied to Scrum the Cargo Cult is the believe that imitating the visible behaviours described in The Scrum Guide™ will make you become agile, i.e. agile as software development team or department, or agile as a whole company. Many people meticulously, sometimes even dogmatically, follow what is described in The Scrum Guide™ without understanding the why. I call this “doing agile vs. being agile” where waterfall thinking goes in disguise of Scrum behaviour. Few people know and understand the 4 values of the Agile Manifesto. Even fever people know that there is a second page on the Agile Manifesto describing the 12 Principles underlying it. This limits their ability to inspect and adapt their processes.

The Agile Maturity Iceberg

My biggest critique on the Agile Manifesto is that it is too limited. The fourth paragraph reads as follows:

Business people and developers must work together daily throughout the project.

– Agile Manifesto

At no point are the users of the software mentioned. End users are the actual customers of a software. It gives the impression that the Agile Manifesto considers the “business people” to be the customers. One could think that the Agile Manifesto has been written by consultants who’s actual customers are the “business people” on the client side. This may not be completely wrong after all. I have seen to many product owners who have never had direct contact to the users of their software. Many times they’re only talking to the sales representatives of their organisation, not realising that what the sales people want from a software is not what the actual users need.

DevOps on the other hand specifically targets the actual users of a software. In DevOps it’s not enough to review the “potentially releasable increment” with the product owner and then indulge in complacence. I wonder why Ken Schwaber and Jeff Sutherland, the authors of The Scrum Guide™, chose the term “potentially releasable increment”. Why isn’t it called “releasable increment”. Should it be shippable or not? DevOps is about deploying features early and often to production. And then to measure behaviour of actual users to validate the hypothesis of a feature. Think A/B tests, feature toggles, dark launches, etc. The whole purpose of a feature is to provide value to an actual user. How can you determine if it does without actually shipping it?

I value Scrum as an agile methodology. However, I think The Scrum Guide™ should add a disclaimer noting that simply applying the roles, events, artifacts, and rules will not make you agile. There are a lot more powerful, while less visible, aspects to being agile.