How to get the max out of your Team Coding Dojo ?

3 minute read

If you’ve read my previous posts about Team Randori Coding Dojos, you should know why and how to run a successful one.

Did you manage to setup the team Randori coding dojo as a recurring event ? Congratulations ! Your team is on the road to continuous learning and improvement. To close this series of posts, here are battle tested tricks for greatest impact. Let’s boost your teamwork, your production code and a few other things.

Yoda doing the Fizz Buzz kata

Boost your teamwork

I stated before that the team Randori is a perfect occasion to improve your teamwork. By itself, just doing it will already take you a long way towards better collaboration. As instigator of the coding dojo though, you can push the topic faster and further.

Coding and Design Conventions

Whenever you see the opportunity during the dojo, raise design discussions. It’s a good way to share best practices. It often ends up in new coding conventions for the team.

Also don’t forget to use the retrospective. It’s the perfect time to agree on best practices for the dojo and for production code. Push people to dig into what they are mentioning. Ask them if they are willing to adhere to a particular practice. You can use thumb vote to get a quick agreement. Once the team agrees on something, record it somewhere and make sure it is visible to everyone.

Egoless Programming

Egoless Programming makes collaboration a lot easier within a team. In the dojo, demonstrate Egoless Programming yourself. In particular if you already enjoy good peer recognition, adopt a “low attitude”. Don’t hesitate to encourage others to delete your code when they have a better idea. Yourself, don’t hesitate to delete code if it makes sense, but don’t make a fuss about it.

💡 Be a champion of Egoless Programming in Coding Dojo to bring this practice in your team.

Be careful if your workplace is too competitive or if your reputation is not yet strong enough. I’d go slow on this aspect in such situations.

During the dojo, you might notice people who have difficulties with egoless programming. In this case, remind its principes to everyone and that you are here to learn and practice. You can also mention that this is a TDD exercice and that deleting and changing code is the way to go.

The cover of "The psychology of computer programming"

Going further

After enough successful sessions, you’ll want to push further and experiment new things. Absolutely do it ! There’s a lot more to discover about the coding dojos.


You can try new formats like the Prepared Kata or Randori in Pairs. You can learn a new language by redoing your favorite problems in this language. You can add constraints like “No If”, “Always Compiles” or even exotic things like “No Heap Allocation”. You might also give Emily Bache’s book a read for tons of others ideas.

Production code

If you continue long enough, your team will get particularly good at Randoris. At that point, you might wonder how you could apply this to production code ? It turns you can !

One way I found, which I wrote about in my first post, is to try to fix a local smell or static analysis issue in the code. Get all the team to do a Randori to fix that, discuss the design and conventions, and commit at the end of the session.

Particularly difficult legacy code refactorings are also pretty good candidates for Randoris. 

💡 Given enough eyeballs, all bugs are shallow. Linus’s Law

Once you are there, you might altogether jump into mob programming ! Randoris are by nature, like timeboxed mobs. Replace the Randori rule “Driver decides what to code” with Strong Style pairing (Make the driver code your idea) and that’s it, you are a mob !

Spread the word

One last thing before closing this series on team coding dojos. If the practice is useful to your team, spread it. Chances are that there are other development teams working next to you. Invite members of other teams to your dojo. This will build up their envy for their own team coding dojo. Propose your help to boot their first session !

In the long run, the improved practices of this team might benefit you ! For example, if your teams start collaborating. Or perhaps you’ll join this team some day !

Whatever happens, I wish you a lot of fun in your teams Coding Dojos. Happy Coding !

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment