How to start a team coding dojo Randori today
In my previous post, I explained why you should start a team coding dojo Randori as soon as you can. Here is a step by step guide to set one up today.
Logistics
This the most important, and most easy, part !
A Time Slot
For a regular team coding dojo, practice showed that 2 hours every 2 weeks works great. Most teams I’ve worked with had 2 weeks sprints, which made this rhythm natural.
Try to find a day and a slot that fits your own constraints. It could on the first, last or mid day of the sprint. It could be in the morning where people are usually fresh. People might have a bit less energy in the afternoon. Don’t put it in the middle of the afternoon, or you’ll ruin the programmers’ focus. Some teams use the lunch break, and bring food in to make the coding dojo even more fun.
Once you’ve found the perfect slot, book a recurring meeting with all your team. It’s now official, you are going to have your first team coding dojo !
Material Stuff
You now need only 4 other things :
- a room
- a laptop with a programming environment
- a large visible screen to display the laptop
- a timer
It used to need a bit of preparation to get all these, but nowadays, it should be easy.
Your first session
The good thing about the Randori is that it is almost preparation-free. Here is the typical agenda for a Randori session :
- Introduction (0:05)
- Problem Selection (0:05)
- Coding (1:40)
- Retrospective (0:10)
Introduction
Start by reviewing last session’s retrospective. This will bring good resolutions back to everyone’s minds. Obviously, you cannot do that at the first session. Present the rules of the Randori instead (as stated by Emily Bache in her book):
- If you have the keyboard, you get to decide what to type
- If you have the keyboard and you don’t know what to type, ask for help
- If you are asked for help, kindly respond to the best of your ability
- If you are not asked, but you see an opportunity for improvement or learning, choose an appropriate moment to mention it. This may involve waiting until the next time all the tests pass (for design improvement suggestions) or until the retrospective.
Don’t hesitate to repeat the rules when you have a newcomer or when you see fit.
The introduction is also a moment where participants can share things together. Just make sure it does not eat on coding time.
Problem Selection
There is a ton of coding dojo subjects out there. For the first session, pick in 1 or 2 problems for the team to choose from. After a few sessions, let people bring in problems and dot vote on their favorite subjects.
As a first problem, I like the Roman Numerals kata. It’s not too difficult and has some interesting YAGNI and “Do the simplest thing that could work” properties. That’s only a personal preference though. Here some resources where to find kata problems :
- codingdojo.org
- cyber-dojo.org
- kata-log.rocks
- The Coding Dojo Handbook (Where you’ll also find tons of other valuable advices)
Whatever the topic you chose for your first session, make sure it is not too difficult.
💡 As a first team Randori coding dojo problem, I like Roman Numerals kata.
Coding
That’s why we are here ! The Randori is a dojo format where everyone works together, on the same problem, through the same computer. Start the timer for 5 minutes as the first pair works on the problem. When the timer rings, the co-pilot takes the keyboard, and someone new becomes the co-pilot. Start the timer again, and repeat after 5 more minutes. If you did not already, have a look at my previous post for more details.
You should be using Test Driven Development during the Randori. Even if you are not (yet) using it on your production code. Here is why :
- It provides a fast feedback loop which enables the fast paced 5 minutes round robin
- It teaches how to design testable code, which is always useful
- It teaches how to do baby steps refactorings
- 🎁 Bonus : it demonstrates agile principles in practice (focus on outcome, incremental delivery, YAGNI …)
I’ve written a lot about TDD, have a look at my posts for more. Applying TDD means sticking to the Red-Green-Refactor loop. During first sessions, be particularly careful that people don’t refactor on red tests.
💡 Team Randori coding dojo demonstrates agile principles in practice (focus on outcome, incremental delivery, YAGNI …)
Retrospective
Stop coding 10 minutes before the end of the session. It might be difficult, but remind everyone that you are here to learn and that you can resume on next session. Use these 10 minutes to think about how it went. As the facilitator, take the keyboard, write these 4 questions in a text document :
- What did we do ?
- What did we learn ?
- What still puzzles us ?
- What did we decide ?
Ask everyone for their answers and write them down. You’ll use this at the beginning of next session.
Next Post
I thought 2 posts would be enough to cover coding dojos, but it seems I have more to say ! My next post will be about tricks and advices to make your dojos a success.
Leave a comment