Introduction
- Purpose, Background, and Goals
- Who Should Read this Book?
- How This Book Is Organized
- Challenges
This chapter is from the book
This chapter is from the book
This chapter is from the book
Agile Kata is new. Both topics individually, Agile and kata, are not. They have long histories on their own. They have proven themselves time and again and their communities are strong. Both believe in similar things. My hope is to connect them, and perhaps many other Agile professionals will have an aha moment similar to what I experienced when I began moving the puzzle pieces closer together.
In recent years, I have seen a burst of new fresh ideas flooding the Agile community. At the time of writing this book, I noticed a positive trend and energy toward organizational design, enterprise and team coaching, business agility, agile leadership, scaling, and portfolio management. There was also an appetite to learn ways to improve the process of an Agile team. The beautiful thing is that Agile Kata can help you get started with all of these topics. And if you’ve already started with one of them, Agile Kata can help you continuously improve it.
Agile Kata is a universal pattern, not the universal pattern. I can’t predict the future. No one can. But from what I can tell about recent trends, businesses have adapted to leaner and flatter hierarchies. Some companies have established democratic, self-managed workplaces with great success. Employees entering the job market are looking for purpose, learning, and growth as a person—and, of course, reward. A fail fast and learn attitude, courage for experimentation, and closing feedback loops with stakeholders and customers is becoming the new norm everywhere. All of these trends are deeply anchored in Agile and scientific thinking and are directly linked to Agile Kata, which can enable these.
Purpose, Background, and Goals
Back in the mid-1990s, when I developed software in Smalltalk, I had the chance to experiment with a series of processes that were fundamentally different from what was commonly used. I used the Rational Unified Process (RUP), Ivar Jacobson’s use-case-driven approach, and Extreme Programming (XP). Compared to today, this pre-Agile-Manifesto period before 2001 truly felt like a groundbreaking, revolutionary era. Some might have referred to us as a bunch of corporate rebels. Even though I was at the beginning of my career, I already had firsthand experience with the flaws of waterfall. I felt anxious to try something new, but we didn’t have the data and evidence yet to be sure that new ways of working would revolutionize the future. In hindsight, this was a bold move to branch off into a niche, especially because I was so early in my career.
The Agile Manifesto did a wonderful job bringing the various processes and frameworks together under one umbrella by giving it a name, values, and a set of principles. I vividly remember taking a trip to Newton, Massachusetts, shortly after the Agile Manifesto was released because news made it to me in New York City that “a guy” named Jeff Sutherland would give a training on Scrum. I felt that I had to be part of that session, especially after I read Agile Software Development with Scrum (Pearson),1 which was fresh off the press. So I made my way up toward Boston…
The training took place in an improvised back room at PatientKeeper, where Jeff worked at that time. It was a small class, and I felt like an intruder because a regular workday unfolded next to us while we were learning about Scrum. Because of the circumstances where Scrum was being taught, it felt like a well-kept secret. That is what moonshiners during prohibition must have felt like.
When I reflect on the past, I recognize that moments like that were important stepping stones in my career. My background in various Agile processes eventually led to creating my own consultancy: Incrementor in New York. Just a few years after that trip to Boston, I had the chance to deliver scrum trainings alongside Jeff and Ken.
A similar eye-opening moment happened in the late 2010s, when the early indicators for successful Agile transformations were dismal. By looking closer at the struggles and failures of Agile transformations, it was quite noticeable that the Agile mindset we used with teams got lost when applied to the transformation process. Questions from clients, such as, “What is the process of introducing Scrum to my organization?” did not generate good answers. It felt ironic that organizations fell back into waterfall behavior when introducing Agile as their new DNA in the organization. I noticed “waves” of work and heard words like roll-out and complete used in the context of Agile transformations. These transformations were often treated as projects or as single-improvement initiatives, like an item on a corporate checklist.
The grassroots movement of Agile in the early days—where teams worked, learned, and continuously refined their process over time—seemed to have ended. Agile transformations now showed signs of top-down, command-and-control leadership. Some companies even tried to standardize their organization and aimed for ____ (fill in the Agile process flavor of your choice) conformity. Those organizations had entirely missed the idea of what Agile was all about.
In 2017, when I began reading Toyota Kata (McGraw Hill) by Mike Rother, I had this instant feeling that scientific thinking trained by kata and continuous improvement could be of tremendous value for the Agile community. Even though Rother uses Toyota as a vehicle (no pun intended) to bring that pattern to surface, it’s really not about Toyota and cars at all. Once I saw that the kata is a meta skill and can be of universal use, it became my friend for Agile transformations and so much more. Let’s explore this further.
During the hype of Agile transformations, I noticed an abundance of promises made by companies selling shiny Agile transformation playbooks. Those start-to-finish processes were often just a fancy name for an old-school waterfall process that made the planned transformation look logical, safe, and easy to buy in. Many learned the hard way that this is far from reality. I know of several large companies that had several unsuccessful transformations, until they decided to give up. Maybe it is time to question the playbooks and the approaches instead of questioning the ability of an organization to change. I would even argue that every company can change. The question instead is: How fast can they change?
The difference between the traditional approach and kata is also captured in the well-known saying, “Give a man a fish, and you feed him for a day; teach a man to fish and you feed him for a lifetime.” Just handing an organization a blueprint and sending a constant stimulus from the outside to become more agile is clearly not enough. On the other hand, Toyota Kata is that meta skill that teaches an organization to learn how to fish. As a matter of fact, it teaches how to fish and continuously improve your fishing skills. Learning is continuous.
But when I began increasing agility this way, I remembered the quote by Antoine de Saint-Exupéry: “If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”
Agility is the resiliency in an organization to make better, more rapid decisions in response to feedback with the purpose of building better products and services. To stay relevant as a for-profit company, reading the market trends and reacting accordingly is extremely important. The successful companies are really good at this.
Agile Kata extends Toyota Kata in ways to embrace and live by Agile values and principles from day one. Enabling an Agile culture by adopting a new leadership style increases collaborating skills in self-organized, autonomous teams. It also requires an upgrade of coaching skills and ways of measuring the success of our products and the process.
In the beginning, my goals were very narrow. I wanted to help clients in their transformation journey. We tested kata ideas and experimented in various settings. The feedback was positive, and we got encouragement to continue. We created the Agile Transformation Kata as the first attempt to formalize the pattern and name it. Then we dropped the word transformation after we learned about many additional scenarios that went way beyond the initial transformation need.
I hope this book will give you plenty of new ideas to help increase agility. The ideas in it will challenge the ways things currently work in your organization and help you consider how using Agile Kata can make it a better place. Considering that agile organizations are more flexible and adaptable and therefore more competitive, I believe that Agile Kata can be of tremendous value for your company or client. Another hope, which might sound very ambitious and audacious, is that Agile Kata can help your organization and the Agile community as a whole to break through stalemate situations to reach a higher level of agility.
The goal of the book is neither a full introduction to kata nor to Agile nor a resource to make you an expert on either topic. It would be a false expectation to think something so big could be covered in only a couple hundred pages or to expect that you can develop skills only by reading. However, this book should get you off the ground.
If I have left out a reference to your favorite Lean, Agile, or kata book, it doesn’t mean that it’s not relevant in the context of Agile Kata. It’s tough for an author to find a balance between the right amount of relevant information and paralyzing the reader through information overload. Again, I hope I have kept the content focused so that you can navigate the topic effectively.
This book is relatively short by design. It may take you only a few days to read through the material. The Agile Kata approach is very lightweight, just like other Agile processes, and the length of this book carries that spirit. However, keep in mind that lightweight does not necessarily mean that it is also easy to do.
You will certainly encounter challenges when you apply Agile Kata within your environment. Over time, though, if you practice it deliberately, it will become second nature.
My goal with this book is to build a solid bridge between kata and Agile—a bridge that should make you feel comfortable to cross in either direction. To do this, I chose a mix of theory, examples, and use cases that should give you plenty of confidence to introduce Agile Kata to your organization. I’m curious to hear about your success stories, but if you notice that it is not working the way you expect, please let me know, too. To keep this process interactive, I have reserved www.joekrebs.com/agile-kata-book, where you can submit any feedback about the content of the book. For training-, certification-, and community-related inquiries, please visit www.agilekata.pro, a hub created for Agile Kata professionals. For book content and feedback, please visit joekrebs.com/agile-kata-book.
