You Are not Doing Scrum
"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 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 Scrum framework will inevitably introduce (notice, that shock, in this case, is not mandatorily a bad thing), is not the focus of this post.
Now I think 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 Scrum 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 rather about 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.
(Some) practitioners and consultants' attitude doesn't help either. "You fail because you are not doing Scrum." "Scrum cannot fail; you are doing it wrong, try harder."
Are You not Doing Kanban Either?
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," professes the Kanban Method.
Kanban Method uses a set of practices which comprise the "Standard Kanban," as opposed to the "Proto Kanban." Some of the practices are visualization, WIP Limits throughout the system, active management of flow, explicit policies, feedback loops, and continuous improvement. Kanban Maturity Model 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, and the KMM charts that journey.
Some will say that practices such as limiting work-in-progress are nothing short of revolutionary, and all this evolutionary talk is just a façade for the hard and fast rules and rigid principles. Those arguments are missing the point. While WIP limits are a must for attacking both muri and mura, 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, provided relief from overburdening, 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.
More Similarities Than Differences
Time and time again, "It's not Scrum fault, it's you," sound to me as a defense of the framework. The Scrum framework does not need your protection. It works, it's holistic, and, applied right 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. Scrum will be inappropriate in 3 other parts of Cynefin in most cases.
Kanban can strive in almost off 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. Scrum will not work if you don't have stable, fairly cross-functional, and empowered self-organizing teams. Some organizations might not 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). Group 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 the 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, 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. Scrum is a framework to develop products while solving complex and adaptive problems. Kanban Method, with its laser focus on evolutionary change, is first and foremost, the 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.
Be less dogmatic. Think agile. Be more like water and Scrum On!