Q&A on the Book Level up Agile with Toyota Kata

In the book Level Up Agile With Toyota Kata, Jesper Boeg explores how to apply Toyota Kata to drive improvement in organizations that are using or striving to use agile ways of working. He shares his experience from combining agile with Toyota Kata to enable organizations to keep improving towards their goals.

InfoQ interviewed Jesper Boeg about the Improvement Kata and applying Toyota Kata in an agile context, improvements in which multiple organization levels are involved, how they rolled out Toyota Kata across Bankdata, end-to-end process optimization, and measuring organizational maturity.

InfoQ: What made you decide to write this book?

Jesper Boeg: I found that it was hard to find any real documented experience working with Toyota Kata in a software development setting (or any product development context), at least beyond a single team or for a short period of time. Mike Rother (author of three books on Toyota Kata) and others have done a great job of describing how it works in a manufacturing context where variability is low, cycle time is measured in seconds, and you can visually observe the process. Given the many failures and hiccups we have gone through in our efforts to translate the concept from the world of manufacturing and apply it at an organizational scale, I wanted to make it easier for others to get started by learning from our mistakes.

Also, I had a personal need to reflect on my experience from six years of working with Toyota Kata. Forcing myself to put it into writing was one way of doing that.

InfoQ: For whom is the book intended?

Boeg: The most obvious target groups are agile coaches, Scrum Masters and leaders struggling to achieve the organizational or team-level agile maturity they were hoping for. Toyota Kata provides a system for them to turn good intentions into real results.

InfoQ: What does the Improvement Kata look like?

Boeg: There are two main Kata: the Improvement Kata and Coaching Kata. Put simply, the Improvement Kata is the engine that translates ideas into results, while the Coaching Kata aims to improve that engine. The Improvement Kata is a systematic way of setting measurable improvement goals and working iteratively to achieve them through short learning loops. You might for example strive to achieve a more balanced team through broadening the skill sets of individual team members, so the team can pull work in order of business value. As they work to establish this capability, they experiment with pair programming, handover sessions, mentor/mentee and tutorials to find the best strategy.  

To apply the Improvement Kata, you need to know where you are and where you want to be. You might for example realize that only 20% of your work is pulled in order of business priority, that deployment takes four man-days of manuel effort and involves 15 manual steps, or that average lead-time is 40 days despite working in two-week sprints. Not something to be sad about, but a great chance to set measurable and time-bound goals for a better future state and start working systematically to improve the situation.

InfoQ: How does Toyota Kata drive improvement, and how does that differ from other improvement approaches, for instance agile retrospectives?

Boeg: First of all, it is important to realize that Toyota Kata is based on directed improvement, meaning a focus on a desirable future state. You need to be able to explain what for example agile means beyond vague terms like "iterative and adaptive" or a "learning organization". Often that means defining an agile Vision containing the core capabilities that define agile for the organization. In the book I mention eight capabilities that agile organisations should strive to establish:

• Strategic alignment
• Empowered, self-organizing teams
• Stable end-to-end teams with 100% allocation
• Always releasable – all work, any time, fully automated on demand
• Small batches (MVP, MVF), always outside-in approach
• Visual management – full transparency
• Continuous qualitative and quantitative customer and end-user feedback
• One-by-one flow (Limit WIP)

The vision provides the direction and boundaries for improvement. If for example  a local manager wants to form temporary project teams with part time allocations, that would be against the vision of "stable teams with 100% allocation" and would therefore not be an acceptable solution. In the same way, if an agile team decides to slice scope into big chunks in functional layers, that would not be acceptable as it is neither outside-in nor a focus on small batches.

But the vision should not include specific solution design like "Scrum by the book" or "Microservice architecture"; that would leave little space to inspect and adapt according to the local context and find creative solutions to move forward, as we would mandate specific roles and practices.

This also means that most team and organizational-level improvements will focus on one aspect of the vision, for example, automating the deployment pipeline would fall under "Always releasable, fully automated on demand," and working to measure the impact of released user stories falls under "Continuous qualitative and quantitative end-user feedback on all delivered value".

This is a very different approach compared to reactive problem-solving. With Toyota Kata, we only focus on the obstacles that keep us from reaching our goal or "Target Condition," not on problems with our current process. We will always have hundreds of problems, but unless they keep us from reaching our goal, they are not really worthy of our attention. Studies have shown that our brains are actually much better at moving towards something we want rather than away from problems - "Removing what you don’t want does not necessarily give you what you want".

Another key difference is the focus on experimenting in small learning loops. If we accept that process improvement is an iterative path rather than a straight road from A to B, we need to plan for short learning cycles, just like we do on the product development side. As we need to learn to slice our user stories into small vertical chunks of customer recognized value, we need to learn how to quickly validate process improvement experiments. If experiments are short, we become less afraid of failing, and a core element of Toyota Kata is actually building a much more fail-tolerant culture which in turn enables creativity and daring to try out new techniques and approaches.

InfoQ: What benefits can Toyota Kata bring when applied in combination with an agile way of working?

Boeg: In my view, Toyota Kata is more an enabler of agile rather than a combination. It is a way for organizations to keep improving towards their goal of becoming true agile organizations without getting sidetracked or falling back into old patterns of command and control, analysis paralysis or temporary project teams with little chance of ever reaching the cliché notion of "A high performance team". I view Toyota Kata as the improvement engine that keeps us improving in the right direction, even after the "agile Transformation" honeymoon is over, and makes sure that we do not forget the goal when we are pressured by changing leadership positions and product failures. The real test of organizational maturity is not the level of initial Agility, but what happens when the organization is stressed and pressured by internal or external factors.

InfoQ: How can agile (Scrum) teams apply the Toyota Kata in an agile context?

Boeg: As I mention in the book, we actually tried different strategies to make Toyota Kata fit within the typical Scrum container (most teams were using at least part of the Scrum framework). In terms of basic mechanics, most teams opted for substituting every second retrospective with an Improvement Kata planning meeting. As preparation for this meeting, the Scrum Master would typically validate the focus on improvement with the rest of the team, and help gather data to support the understanding of the current condition in order to be able to set a realistic ambitious improvement target. The remaining retrospectives would focus more on the softer aspects, as well as "go-fix-it" issues.  

Since not all teams were using Scrum, we chose the more neutral wording "Process Lead" for the role of facilitating the improvement process in the team. For teams using Scrum, this would naturally be the Scrum Master. A key learning point here was that despite Scrum’s ambition to have Scrum Masters coach, lead and guide the team and organization in the adoption of Scrum and agile, this was not happening in all teams. Some Scrum Masters had been reduced to mere facilitators with only the ability to ask, "What do you think?" and were not seeing themselves as process experts. With the introduction of Toyota Kata, this became very evident as Process Leads are required to deeply understand both lean and agile, and drive directed improvement. This sometimes both includes taking on actual decision responsibility, and saying no to ideas and solutions that might seem right but actually work against the very core of what the team and organization should strive for. Examples of saying "no" to ideas include breaking user stories into functional layers to optimize for utilization of individual developers, starting new work instead of finishing what has already been started, or assigning all work items at the beginning of the sprint to create individual accountability.  

Not all Process Leads/Scrum Masters liked the idea of taking on a more leading role in driving improvement initially, and we heard many comments like, "The team always knows best". In a Toyota Kata setting, this is however not acceptable, as we have high respect for the skills of team members. If you spent years becoming a fantastic software developer, business analyst or graphical designer, it is totally fair and expected that you prioritise watching conference presentations, reading blogs or exploring new tools within that field. If you are a Process Lead however, we expect you to do the same within the area of agile and lean and become a true expert in those fields.   

InfoQ: How does the principle of the second coach work?

Boeg: The principle of the second coach is actually not unique to Toyota Kata, and almost every organization employing agile coaches will already be familiar with the concept. To become better at coaching, the coach needs feedback on their coaching skills. Thus, the second coach observes and provides feedback either during or after the coaching session. Just like an agile coach will observe a Scrum Master coaching the team and give feedback, that will help the Scrum Master improve their coaching skills over time.

Coaching Kata makes sure that improvement drivers at all levels get a chance to reflect on their improvement efforts and get feedback on a weekly basis. Often, a manager will coach their direct reports which could be team level Process Leads or other managers. Since there are so many ways that this can go wrong, second coaches are really important - especially in the beginning. Typical anti-patterns include coaches who are trying to mandate their own solutions to a problem, resulting in vague assumptions instead of finding actual data, or Coaching Kata sessions turning into command and control style meetings focused on progress reporting.

InfoQ: What's your suggestion for improvements where multiple organization levels are involved?

Boeg: This is where Toyota Kata becomes very interesting, as all levels of the organization are involved in driving improvement. Though we often focus on the team level because it simply represents such a large part of the agile organizational structure, the key is to understand that Improvement Kata and Coaching Kata are executed at all levels of the organization. If you think about all the obstacles teams face in a complex organization, this makes perfect sense. Expecting a single team or Scrum Master to change budgeting, funding or portfolio processes or the way teams are structured and people are allocated to projects or initiatives is often too ambitious, and making sure that higher level management takes responsibility for agile process improvements on these elements is often key to long term success.

Another aspect of this is what is often referred to as a catch-ball. This might for example be a shared initiative across teams and organizational levels to reduce leadtime or increase feedback. Having aligned improvement goals means that all layers are pulling in the same direction and that everybody is required to demonstrate what they are doing to help bring the organization to a new level of performance in that focus area. In an effort to reduce lead-time, a senior director might for example work with the customer to change contracts and policies for receiving new versions of the software, while a middle-level manager helps eliminate cross-team dependencies and teams are busy automating the deployment pipeline.

InfoQ: How did you roll out Toyota Kata across Bankdata, and what did you learn from this roll-out?

Boeg: We made many mistakes in the roll-out, and explaining just the major failures and adjustments would take a couple of pages. In short, we did it in the usual style focusing on a pilot in one business area initially, and then subsequent waves as we learned and adjusted. Key lessons learned included the need for intensive coaching initially to find appropriate improvement goals and metrics, creating a shared metric inspiration catalogue, focusing on local goals initially before launching catchball initiatives, and most importantly, not doing the roll-out faster than we were able to support.

InfoQ: How can we do end-to-end process optimization?

Boeg: Value Stream mapping and other tools are a core part of developing both an understanding of the current condition and identifying desirable future states when using Toyota Kata. So much so that Mike Rother actually talks about the process of using these tools as separate "Kata".  What surprised us initially was how little individual teams and managers focus on the end-to-end process of turning a vague idea into usable software. Mapping the value stream to identify dependencies, handovers to other teams, or simply lack of knowledge about what actually goes on turned out to be a huge "aha" experience for many of the people involved. Some believed that they had formed end-to-end teams only to realise that it took several cross-team handovers for actual code to reach production, while others thought they were much, much faster than the actual data revealed.

At Bankdata, a couple of internal coaches decided to launch an internal training program focusing only on understanding end-to-end process optimization in order to help teams and managers become better equipped for using Toyota Kata. It quickly became one of the most popular internal offerings.

Put simply, you cannot effectively optimize a workflow you don’t understand or that is not sufficiently consistent. If you focus on whatever comes to mind, you could easily spend a lot of energy without creating any actual results or optimizing a process that is ad-hoc and random. You might try to fix a quality issue just to find that the process was not even repeated the next time around. But this does come with a warning. If you start too big and insist on covering the entire value stream, at first you might find it hard to get started at all. We found that equal attention must be given to learning the basics of the Toyota Kata framework and finding valuable improvement opportunities in the beginning.

InfoQ: What's your suggestion for measuring organizational maturity?

Boeg: I have found that a simple survey questionnaire grouped by the capabilities included in the agile vision makes most sense. Around 25 questions in total seems to be the limit, if you want teams and managers to do the survey monthly or bi-monthly (often enough to be useful, far enough apart for things to have changed), without too many complaints. As a community, we have a long history of navigating blindly through agile transitions. To me, a rough overview of how we are doing in terms of our efforts to establish agile capabilities in our organization is absolutely crucial, and I find it hard to imagine working without it.

As a consultant, it is also a great way to keep your feet on the ground. We tend to imagine that everything is perfect, and people love and use the material and advice presented in coaching and training sessions. In reality, things can be quite different, and forcing myself to look at the actual data is a healthy exercise. On a more practical level, it is also a great way to look for success stories and areas that need more attention.

No matter how you structure the survey, it will however never be perfect, and it should never be a replacement for getting out into the real world and talking to real teams and managers and observing how they actually work. But it can give you an idea of where to focus your energy on.

About the Author

Jesper Boeg is implementing Agile and Lean principles in the context of innovation and IT has his work and passion since 2006. He enjoys difficult challenges and is constantly seeking new ways to deliver great solutions and make work simpler, easier and more enjoyable for everybody involved. Boeg works with the entire value stream, from C-level to individual teams. He enjoys both the job of aligning senior management on the company’s Agile direction, building a team of internal change agents, and hands-on implementation. Boeg is known for being to the point and unafraid of bringing difficult matters to the table, but with a smile and humor as a key enabler. Boeg has worked with companies of  all sizes, from small startups to large corporations, and has worked hands-on in almost all possible roles, including a position as VP of Agile and Lean Process Excellence at the software development and consulting company Trifork. Boeg is now the owner of AgileUpgrade.com focusing on leading Agile and Lean change initiatives. He regularly speaks at local meetups and Agile and Lean conferences.