You Can’t Process Your Way to Agility
Today’s entry in my KataLog might make a few seasoned agile practitioners uncomfortable, especially if you are using a process framework like Scrum. This is something I've wanted to share for a while because I frequently get similar questions about the differences between Agile Kata and those popular frameworks that are increasingly questioned or challenged today.
I have observed the same pattern endless times. Scrum teams start strong. They learn about the process and are coached to navigate the situation and domain they are in. You typically notice a lot of energy in teams and organizations during that time, as the newly introduced process shakes things up. But over time, the once fresh new process becomes stale, mechanical, and robotic. For leaders watching this from the outside, they might call “mission accomplished” because the team found its groove. Scrum was “installed” like an operating system. Managers are calling their organization Agile and, like nomads, move on to the next buzzword. The autopilot mode is not only problematic for Scrum but has become a real problem for many Scrum Masters over the years, especially in companies focused on cost-cutting.
Let’s be clear, this is not how Scrum is supposed to work, nor is it an error in the framework. Our current business world runs on a mindset of thinking in products, projects, and initiatives. Managing costs, timelines, and people. And because this has been done worldwide for decades, it is deeply ingrained in organizations' DNA. And just as with any bad habit, it is even harder to change existing organizational habits and procedures in the long term. Even worse, once you stop cultivating this new mindset, old habits creep back in. That's why Scrum is hardly recognizable in some so-called Scrum teams and is just a label put on an old process. The energy, benefits, and promises just seem to have faded away over time.
My goal is not to be down about this or blame Scrum, but to use this common scenario to highlight the differences between a process framework like Scrum and a continuous improvement pattern like Agile Kata. To do this, I am using Mike Rother's illustration of learning to swim as a metaphor below for inspiration.
Scrum, as described in the Scrum Guide, is like your process product. It describes the roles, events, artifacts, and rules of Scrum. This basic framework needs to remain intact; otherwise, it is no longer Scrum. You can add your practices, tools, and techniques, but you can’t remove them from the framework. For example, if you replace the short Daily Scrum with a weekly long meeting, it is no longer Scrum. The rules of the game of Scrum are clear, defined, and may be perceived as rigid.
Agile Kata, on the other hand, is a starter routine that uses scientific thinking to establish a continuous-improvement mindset in your team. The Improvement Kata by Mike Rother, for example, is a general pattern. The Agile Kata builds on this general pattern but specializes it for agile teams and organizations. If your team consists of experts in scientific thinking and agile, you don’t need Agile Kata. You are beyond the level of bootstrapping that Agile Kata aims to support. But because scientific thinking is uncommon in the business world, and teams struggle to avoid Agile autopilot mode, Agile Kata is here to help. Agile Kata does not have hard rules, roles, events, or mandatory artifacts. There is a basic 4-step routine to follow to support continuous improvement, but over time, your way of working will evolve and morph into something that you will call your own.
Scrum and Agile Kata are fundamentally different. Scrum aims to improve how we do something defined in the Scrum Guide; Agile Kata aims to help us think differently and change how we look at agility.
With Scrum, you replace what you are currently doing; Agile Kata picks you up where you currently are. In the world of scientific thinking, that is called the current condition and is one of the 4 steps in the starter pattern. So technically, if a team had started with Scrum, feels stuck, and wants to start with Agile Kata, your initial current condition is actually the Scrum you have. Not the one listed in the Scrum Guide, but what it became in your team.
The moment you apply the Agile Kata pattern, however, your Scrum is expected to change. Soon after, your Scrum might no longer be Scrum according to the predefined rules. It is important to point out that it will require openness and commitment of a Scrum team to accept that fact. If you are a Scrum Master on one of those teams, you are no longer a Scrum Master. Why? Because your role is about upholding Scrum, which is no longer the case with the slightest deviation. Your focus just shifted to agile; therefore, calling yourself an Agile Coach fits this situation much better, in my opinion.
Let’s take this example to the swimming pool, our metaphor. When learning to swim, for example, as a toddler, you don’t learn to swim from listening to instructions or watching videos. You learn it by entering the pool and going into the water. For someone brand-new to swimming, this can be potentially life-threatening, which is why we often start in the shallow end. Someone who teaches someone to swim (a coach) will most likely enter the pool as well to make the learner comfortable and safe and to give hands-on instruction.
Over time, the roles of the learner and coach change through learning and feedback in this process. The learner might upgrade from a beginner class to an intermediate class, but even within these categories, learners are at various levels. We might perform similar practice routines, but the feedback and attention each learner receives can vary. The coach’s role evolves as well, stepping out of the pool and onto the sidelines. This way, the coach can keep up with the pace and watch the execution more closely. This is continuous improvement in action and scientific thinking, which, by the way, is extremely hands-on and practical, and can guide the learner and coach to seek excellence. Remember that seeking represents a quest for excellence, a moving target.
Where in this pool would you find your team? We could argue that our Scrum team mentioned above, which executes Scrum robotically, is at the low end of the pool. just beginning to practice. We were told about the basics of swimming and had some dry-run exercises outside the pool. Our coach is with us in the pool, course-correcting and making sure everyone is safe. With no experiments or pushing the boundaries of agility, a team would never leave the shallow end. Let’s be realistic, being comfortable with being uncomfortable is the key. The moment we stop continuous improvement, we are stuck where we are at, or even worse, paddle backwards.
Agile Kata helps you push the boundaries of agility through scientific thinking. Not through time-boxes and iterations, but through challenges. It makes you assess your current agile condition and where you would like to be next (target). Those targets are naturally small, like proper leg coordination in freestyle swimming. Many targets lead you eventually closer to the initial challenge. Knowing the current and target conditions, experiments are planned and executed. Working this way is common sense, practical, and evidence-based. Relatively easy to explain, but not easy to do. Once you have the pattern internalized, the team moves slowly but surely into the deeper parts of the pool, then sets new challenges.
In summary and on a high level, existing Scrum teams can benefit from Agile Kata in two different ways. First to improve their Scrum continuously and keeping it Scrum. and secondly to evolve it and turn it into something that closer to what works for that team even if that result is not Scrum anymore.
