If you’ve ever explored options for how to train your engineering team, you’ve probably come across Code Katas. Teaching with Katas is relatively simple: show your team a short, made-up problem (the “Kata”) and get them to try and solve it. Traditionally, this is done either individually or in pairs.
Yet while handing out Katas for people to figure out on their own works in many cases, there are occasions where it falls short. Simple problem statements handed out one-by-one or pair-by-pair are great for teaching specific techniques—especially ones where there isn’t a lot of variation—but when you want them to learn a technique that involves more unpredictability, it may not be the best option.
This is best illustrated with an example. Let’s say you want to teach your team TDD and you hand out Katas according to the “traditional,” one-by-one approach. If an individual or pair runs into trouble — which is almost a guarantee — help isn’t immediately available to them. At best, they can raise their hand and wait for the instructor to come and help, which takes the instructor’s attention away from others who are also having issues.
When left to their own devices, participants in a Kata are tempted to look for shortcuts or skip some of the harder and more important parts of the exercise. (And for those of you who remember learning TDD, some of the steps can be frustrating and easy to skip, especially when you’re solving a simple problem that you don’t think needs a test-first approach.) Here, traditional Kata instruction leads to a loss in teaching efficiency.
When left to their own devices, participants in a Kata are tempted to look for shortcuts. This leads to a loss in teaching efficiency.
Traditional Katas also make it hard to sync up at the end of an exercise: everyone has completed the challenge in different ways, so in order to walk away with a shared understanding, you have to invest a lot of follow-up time presenting and comparing solutions to ensure proper alignment.
In situations where the lesson is more extensive or complex, a more fruitful way to conduct Katas is with a method called “Randori.” Randori instruction is when you work through a problem collectively according to the following rules:
There are a lot of tweaks you can make to these rules (such as how often to rotate pairs or how often the audience may intervene) but these are the basic principles. The point is that unlike the traditional approach, the Randori training experience is a collective one.
Running your training session Randori-style has some unique benefits. For starters, developers get feedback from the whole team, not just their pair. This means that if the pair runs into trouble, they aren’t stuck waiting for the instructor to put them out of their misery. Nor are they likely to take shortcuts or skip anything difficult. Teaching efficiency is high, because everyone is there to work through the solution together.
And because they work through the solution together, the team enjoys a collective experience. Shared context means that the team can refer to specific events and have a common ground for future discussion. “When Jessica was writing that test, I noticed that…”
Shared context means that the team can refer to specific events and have a common ground for future discussion.
Incidentally, another bonus of Randori is that it can help more quiet developers practice speaking in front of groups of people. A group of one’s peers is a low-pressure environment, so it’s a good place to get started. Plus they’ll be coding, which they’re already comfortable with.
When running a Randori session, it’s important to keep the following in mind:
Randori isn’t always the easiest method for imparting new concepts to your team. Pairing is an important part of how the exercise is run, for instance, and if your team isn’t used to it, you may notice some friction.
Randori can also be expensive to run, both in setting up the space and setting up the problem. If the skill you’re teaching is relatively straightforward (e.g., setting up a docker container), then it’s worth exploring other options.
Traditional Kata instruction and Randori-style Kata training each have their strengths. But whatever you choose, it’s important to go with the method that suits the nature of the skill to be taught. If the skill is complex enough and would benefit from being taught in a collaborative environment, Randori might be the way to go!
Cameron is a Software Engineer at Connected. He’s always looking for ways to improve the processes and interactions in his team.
Currently undergoing rapid growth (and we mean rapid), Connected is looking for talented engineers, designers, and product managers to join our team. Click here to view our open positions.