Scrum Has a Messaging Problem

“You are not doing Scrum.” How many times have you heard that? Scrum Police are a legion. “If you are not doing `insert your missing part of the framework here OR (even better) a complementary practice`, you are not doing Scrum.”

Whether or not you should be doing Scrum, whether it applies to your environment and context, whether your organizational capacity for change is capable of absorbing the shock that the Scrum framework will inevitably introduce (and that shock, in this case, may not be necessarily a bad thing): these things are not the focus of this post.

I believe that the crux of the problem is twofold: a rigid and orthodox reading of the Scrum Guide and a less than desirable level of practitioners implementing and teaching Scrum these days.

The Guide does have the immutability clause, that reads, “Scrum’s roles, events, artifacts, and rules are immutable, and although implementing only parts of Scrum is possible, the result is not Scrum.” It does introduce some sense of a binary Scrum / Not-Scrum state of affairs.

However, life is not all that black and white. Any Agile framework or method introduction (or implementation) is about embarking on a never-ending journey, a continuous and virtuous improvement cycle, rather than a remote and coveted destination. Unfortunately, the Scrum/Not-Scrum binary statement from the Scrum Guide could lead some people to believe that Scrum is some coveted state, some target, that one can reach, and when there, the travelers will gain some riches, and all their labors will be behind them.

As an aside, I think that “because the Scrum Guide says so” explanation belongs to the same circle of Hell where the “because we have always done it this way” kind of arguments dwell.

“You fail because you are not doing Scrum.” “Scrum cannot fail; you are doing it wrong, try harder.” Attitudes like these embraced by (some) practitioners and consultants are unhelpful and lead people away from agility instead of towards it.

So You Aren’t Doing Kanban Either?

The Kanban Method has a different message. “Whatever you decide to do now, it’s all good if it takes you in the right direction. Start where you are; improve collaboratively, evolve experimentally; resistance to the change is like a rock, be like water, go around the rock.” This is the mantra of the Kanban Method.

The Kanban Method uses a set of practices that comprise the “Standard Kanban,” as opposed to the “Proto Kanban.” Some of the practices are visualization, WIP limits (WIPL) throughout the system, active management of flow, explicit policies, feedback loops, and continuous improvement. Proto Kanban might miss some of these practices, which does not make it bad Kanban. It just can be improved, like everything else. Kanban Maturity Model (KMM) gives an interesting perspective at the evolutionary changes a Kanban introduction and adoption can go through, and the benefits each step can bring about. We can have a long argument whether maturity models are good or evil, in my mind, again, it’s all about the journey, not the destination: the KMM charts that journey.

Some will say that, not unlike in Scrum, some Kanban practices such as limiting work-in-progress are nothing short of revolutionary and that all this evolutionary talk is just a façade for the hard and fast rules and rigid principles. Those arguments miss the point. While WIP limits are a must for attacking waste (both muri and mura – overburdening and unevenness), they are not required by Kanban Method from day one; they can take various forms that will allow for easing the transition and making it a true evolution of the process.

It is worth noting that in the absence of any or some of those practices, the chances are that you will not have Standard Kanban. It is also possible that your Kanban will devolve into a form of a Proto Kanban. We don’t equate Proto Kanban, with something lesser than Kanban, or bad Kanban. It is just a transitory stage on the journey of continuous improvement.

What you will not hear from competent Kanban practitioners, is something like, “You are not limiting your WIP (or your policies are not explicit), so you are not doing Kanban, try harder.” What they are more likely to point out is how existing practices improved your work, how they provided relief from overburdening and made the flow less uneven. What they will suggest are the evolutionary practices you can try to enhance your present state further. A lot of Scrum practitioners could benefit from a similar mindset and adjust their messaging accordingly.

Scrum and Kanban: More Similarities 

Time and time again, “It’s not Scrums fault, it’s you,” sounds to me as a defense of the framework. Please know that the Scrum framework does not need your protection. It works, it’s holistic, and, applied correctly in the right environment and to the proper context, serves its purpose beautifully. What Scrum needs badly, is a lot of better-educated practitioners, who are adept at exercising their growth mindset, who can differentiate a journey from a destination, and who have a good command of sound change management principles and practices. Unfortunately, we pay insufficient attention to the latter.

Now, I am not arguing that Kanban is better than Scrum or vice versa. They both can shine given the proper environment and context. They both work beautifully together under the right circumstances. My understanding is that Kanban applies to some challenges where Scrum is inappropriate. For example, we know that Scrum is a framework to solve complex and adaptive problems. That’s only one habitat from the Cynefin framework. In most cases, Scrum will be inappropriate in 3 other parts of Cynefin.

Kanban can strive in almost all of those. Kanban techniques of visualization, applying WIP limits, managing work in progress, continuously improving the workflow are a great help to Scrum teams in the Complex habitat. The framework will not work if you don’t have stable, fairly cross-functional, and empowered self-organizing teams. Some organizations might not even need those (though, reading McCrystal’s Team of Teams would lead you to believe that we entered the age of Teams and anything short of a team would be something of lesser quality and value). Groups of individuals coordinate their work; team members rally around a common goal and purpose. Scrum will not work for the former. Kanban will.

If I were to attempt to create a Venn diagram showing problems Scrum and Kanban can successfully tackle, it would have probably looked like this. I welcome a dialog about that diagram, since, right now, I have a hard time imagining which problems Scrum could tackle and not benefit from some complementary practices rooted in Kanban.

Scrum and Kanban are not foes, not antagonists, and not even competitors unless you talk to sellers of competing courses and certifications. We should stop conversations “Scrum vs. Kanban” or “Scrum or Kanban” right now. One is a framework to develop products while solving complex and adaptive problems. Another, with its laser focus on evolutionary change, is first and foremost, a change management method.

We can use some solid change management ideas and principles while introducing and working with Scrum. We can use some softer language while guiding teams on the journey to agility.

Common language and messaging are important. They underpin Transparency. Paraphrasing the Scrum Guide, “Transparency requires significant aspects of the process to be visible to those responsible for the outcome and be defined by a common standard, so observers share a common understanding of what is being seen.” Moreover, “common language shared by all the participants” is specifically called out as one example of transparency.

I call on the Scrum and the larger Agile community to correct our messaging while we walk the continual path of tackling hard problems. Be less dogmatic. Think Agile. Be more like water and Scrum On!