Training with Randori

Using Collaborative Katas to Teach More Effectively

By Cameron Rowshanbin

Katas in Isolation: The “Traditional” Approach

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.

Traditional Kata instruction: developers sort out the problem by themselves or in pairs. Illustration by Emily Soo.

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.

The Randori Method

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:

1. A pair (driver and navigator) sits at the front of the room with a laptop hooked up to a projector.
2. The other participants sit in the audience and watch the code on the big screen.
3. The pair communicate with one another about what they’re doing as they normally would, while the audience watching them act as “secondary navigators,” giving suggestions where appropriate but generally playing the role of observers.
4. Every 5 minutes or so, everyone in the room rotates: the navigator becomes the driver, the driver joins the audience, and a member from the audience becomes the new navigator.

Randori training: a pair works out the Kata in front of an audience. After a given period, the navigator becomes the driver, the driver joins the audience, and a member from the audience becomes the new navigator. Illustration by Emily Soo.

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:

1. Prepare the space. Make sure you have the laptop and display set up in a way that allows all participants to read the text.
2. Prepare the problem. Make sure you have the Kata ready to go. I find it nice to have the problem written out on a whiteboard for everyone to refer to as they progress.
3. Be ready to pick random people from the audience to rotate in. You want to engage as many people as possible — everyone if you can.
4. Pick a problem that’s simple yet interesting for your group. I find that taking the time to find or create a Kata that is relevant to the types of problems your dev team solves is important to keeping them engaged.
5. Collect feedback! We’ve been able to make all kinds of adjustments to our Katas to better fit our teams as a result of collecting feedback.

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 Lab. He’s always looking for ways to improve the processes and interactions in his team.

We’re hiring!

Currently undergoing rapid growth (and we mean rapid), Connected Lab is looking for talented engineers, designers, and product managers to join our team. Click here to view our open positions.