When I see “Business Transformation,” I admit I immediately think of a company trying to become digital. While this isn’t always the case, it does resemble the path to a significant change, much like a business transformation effort could.
However, rest assured, this article is not about business transformation.
Instead, I’d like to bring the Kata Improvement Model into the fold and see how we can use this Lean practice, most notably used within transforming a business, or parts of a business, within Agile Project Management.
Kata is technically defined as
… a Japanese word (型 or 形) meaning “form.” It refers to a detailed choreographed pattern of martial arts movements made to be [practiced] alone. Wikipedia
From its origins, the term was used in semblance by author Mike Rother in his book, Toyota Kata, as a result of his observations of Toyota’s manufacturing methods. In this sense, the term has come to encompass further
… the Improvement Kata and Coaching Kata are a means for making the continual improvement process … teachable.
In "you and I" terms, the Improvement and Coaching Kata are used as a system of routine to improve a product or a service. The relationship between Business Transformation and Improvement Kata goes hand-in-hand; the subject change needs to be repeatedly demonstrated to permanent a change. However, this is just the surface; the rabbit hole 🕳 goes much deeper… but it doesn’t get any more complicated.
Kata, as Applied to Agile
Agile is naturally a “repeat until success is met” methodology. So, for example, if we create a specific piece of software functionality during our current iteration/sprint only to find out that we failed to apply an overlooked persona-test, we would re-introduce the code work into our next iteration. So essentially, we’re repeating the process.
Where the Improvement Kata and Coaching Kata can come into play is the refinement of the actual process of Agile as applied to the situation. Using our team scenario in the previous paragraph, we can see a high-level use case as such:
While we’re always trying to move forward, the Improvement Kata can assist our teams in maximizing future efforts. For example, during a Sprint Review, the team may want to take a step back and look at what was missed that allowed the mistake to materialize?
Berry O’Reilly, an Agile coach, suggests looking at these four steps as a means to resolution:
- Understand the Direction or Challenge: *What did we forget? Maybe the team didn’t forget anything, but instead, perhaps, this type of user (the missing persona) wasn’t a thought before this software release?
- Grasp the Current Condition (What’s the Current Performance or System of Work?): *Ask the team or individuals if they felt rushed? Maybe the task wasn’t estimated correctly?
- Establish the Next Target Condition (What operational goal we’re striving for?): *Moving forward (always forward), what’s the team’s goal? It may be as simple as creating a checklist for future projects/iterations. This is a team effort, and thus Zero-Fault bugs should be used to ensure nobody is “faulted” for the issues that arise; instead, it’s about working through the problem(s).
- Execute Toward the Target Condition(s) (How to execute the experiments?): Now that the team has a solution to avoid future issues like this, they’ll need to implement it. For this situation, it’ll be as easy as looking toward the next iteration and seeing if they were able to bypass or avoid making the same mistakes.
As you might surmise from its namesake, Coaching Kata is taking the Improvement Kata to the next level by being a mentor at the individual level. This is where the change happens; much like any Agile discipline, to truly teach it outside of a classroom, you should have the experience to back it up.
Being able to Coach Kata at the ground level is a huge responsibility that I don’t think too many people could handle. Not only are you teaching and walking through a potentially significant issue on the spot, but you’re also facilitating program-wide problem-solving without external oversight. Now, let’s move this out of the car factory and place the example within a Scrum team working on a new feature for AppX.
Wait, do I sense some of you noticing the parallels between a Scrum Master and one who’s Coaching Kata? I would expect so because, in my view, they’re pretty darn close to the same thing. The only significant difference I see is where the Scrum Master is one to clear a path for the team when an issue arises outside of the hands-on work (e.g., team issues, nosy external managers, unannounced stakeholder visits), this is not the role of someone Coaching Kata.
Where they come back together is when a technical issue arises. The employee would raise their hand or pull the lever to stop the line on the manufacturing floor. A manager would make their way to see what the issue is. Change this to the Development Team’s domain, and we can do them together. The Scrum Master and manager Coaching Kata will go through the process to get the team/member to define and solve the issues.
I like Berry O’Reilly’s Lean/Kata questions the Coach (and Scrum Master) should be trying to solve with the team member:
- What is your Target Condition?
- What is your Actual Condition at this moment?
- What Obstacles do you think prevent you from reaching the Target Condition(s)? What single issue are you addressing right now?
- What’s your Next Step? What are you expecting the outcome of your Next Step to be?
- How quickly can we go and see what we’ve learned from this step?
Our goal with this is to make small steps in the right direction, do create and/or fail with our hypothesis quickly, and try again. Then, once we’ve figured out what works, we can scale to a more significant, more solid fix.
Smaller, quicker, faster feedback loops ~Berry O’Reilly
The resemblance between Kata and Agile (as a whole) is on point with how we (or I at least) want to run my teams. So give it a shot, maybe do some reading on the overarching theory of Kata, and see if you, too, can implement it into your workflow.