Introducing a Practice to Continuously Improve Your Scrum
Introducing Scrum to a team or an entire organization seems so easy. Stop doing what you are currently doing and replace it with Scrum as defined in the Scrum Guide. Implementing what is described in a 13-page document shouldn’t be so hard, right? That thinking ends already when you hit the first sentence in the Scrum Guide:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
There are so many things to unpack in this sentence and actually in the entire document. This sentence alone sets the stage for several things. Frameworks are by definition incomplete and you need to find answers through inspection and adaptations. Furthermore Scrum will make you think what is value? And the sentence makes you reflect if Scrum is suitable for all situations or just the complex ones?
Just based on that one single example, introducing Scrum in a pre-defined, top-down approach just does not sound like a good idea, doesn’t it? But for many years I have witnessed exactly this behavior many times. “Rolling out” Scrum following an upfront plan sounds plausible for many unfamiliar with Agile and it is easy to communicate, but reality requires a different approach. Transformational efforts are bumpy, not cookie cutter solutions. Those can lead to zombie Scrum. The chosen transformation process needs to accommodate for that. Changing the way a person works, not only as an individual but also in a team, is a complex endeavor. Just think about the transition to a work from home policy at the start of the pandemic.
Let’s talk habits. I am sure you can think of a habit you would like to change about yourself, but that is often easier said that done. The same is true for organizational change, just on a much larger scale.
In terms of agile transformations, I was convinced that there had to be an agile approach to introducing agile, like using Scrum to introduce Scrum. I actually tried using Scrum to introduce Scrum but without success for several reasons. Let me give you two quick examples to illustrate the dilemma. In past client situations, I could not find a single product owner in an organization to steer the agile transformation. Nor is it a good idea to have the future agile culture of an organization originate from a single person’s brain. Secondly, defining a done increment of work does not apply in the context of what is described in the Scrum Guide. To be clear, Scrum was not created to steer organizations through a transformation of any kind, it is a tool to build products. There are many great ideas in the Scrum Guide that should be considered during an agile transformation, for example the Scrum Values or self-managed teams, but adjusting the Scrum framework to conduct an Agile transformation with Scrum would set the wrong tone for the Scrum teams using Scrum to build products.
I just hit a dead-end at that point and had to take another avenue. Then in 2018, I stumbled across the great work by Mike Rother about the Toyota Kata and since then, I dug deeper into the Kata world and experimented with the Improvement Kata and Coaching Kata in the context of agile processes. I realized that the those Kata are very suitable for lean manufacturing but felt that they needed to be adjusted to work in the agile context. For example, the Toyota Kata uses a coach and a learner role, where the coach is the manager and the learner is the subordinate. That is in the spirit of self-managed teams not creating an agile culture. And, just to give you a second example, the Toyota Kata could be used to potentially improve anything, but in the context of Agile we would like strive to gain more agility based on the agile manifesto. We don't want to lose the context we are operating in.
The Agile Kata is the result of refining and improving the Toyota Kata to make it suitable to achieve business agility, which is a result of an agile transformation. It uses the proven Toyota Kata as the core and driver of continuous improvement. The agile shell around the core turns it into the Agile Kata. That shell introduces and defines the use of the measuring value, following the agile manifesto, agile leadership, agile culture and self-managed high-performing teams.I invite you to explore the content of the Agile Kata to see how it could help you introducing or improving Scrum at your work.
The beauty of this approach is that a Kata can start anytime, it begins with your current situation. No past efforts are wasted or reversed. You can use the Agile Kata to improve agility on a single Scrum team, a department level, or increasing business agility as a whole. Last month, I released the Agile Kata 2.0 as a share-alike license under creative commons so you have full access to this practice to improve your Scrum and much more. Alongside, we also released the new Agile Kata Kit, which serves as a learning aid for everyone interested in this pattern. The kit contains, a wall poster, desk version of the poster, pin and sticker. I did not come as a surprise to see that the latest version of the evidence-based management makes references to the Toyota Kata by Mike Rother as well. I would love to hear back from you, how you used the Agile Kata to improve your Scrum soon.