My First Coding Dojo as Organizer

Today I organized my first coding dojo at work with the help of a colleague. We both had almost no previous experience of this kind of event, I only had two as a participant (an event storming kata and a global day of code retreat). I «try to» practice TDD as much as possible but I am not a specialist either.

The outcome of this event has proven you do not need much to start your own.

Preparation

The Coding Dojo Handbook by Emily Bache has been of great help, even if I only read 25% of it. For a first, we accepted to start with just an approximate idea of the perfect dojo and to improve for the next iterations.

To win some time I prepared a repository with a project setup and the minimal toolset to start coding: a bootstrap, a business class, a test class, a first green test, some fixtures, and of course a test framework. Participants only had to git clone and composer install to start … in an ideal world were you never leave the slightest detail aside.

Things to improve

Indeed, we lost some time getting everyone able to commit on the kata repository. I should have informed the participants about what they needed (an IDE, a wifi connection, a github account), got their Github logins and invite them on the project prior to the dojo.

Overall

Participants found the preparation ok and had no trouble getting in.

Tools

Each of us came with his computer. The randori was divided in 5min iterations involving a pair of navigator and driver. The driver shared his screen in a Slack conference call. This worked quite well.

We all used the same IDE, but with our own habits. Personaly, when coding in TDD, I like to have a split screen, test on left, class tested on right. Other colleagues prefer the opposite, other the whole screen width for a file…

Things to improve

On Slack, reading was a bit difficult. Next time we will increase the font size a bit to improve readability on screen sharing.

About people different habits, we will do our best to define a more standardized approach to avoid confusion when the driver changes.

Overall

We faced no crippling limitations when it came to the tools.

Choice of the problem

The Roman Numerals problem appeared quick to grasp and difficult enough to solve for a first dojo. So the difficulty seemed well suited for a first.

Learnings

Briefly, participants agreed they learnt :

  • to listen to each others, especially when being driver.

  • it is sometimes difficult to expose an idea or intention clearly, especially when being navigator.

  • what is egoless programming, especially when one of us made a U turn and adopted a completely different approach near the end. We all let him develop on his idea and found he was on the right path to a solution when we all were pushing in a dead end.

  • it is sometimes difficult not to anticipate when being driver and start typing before the navigator gave instructions.

  • IDE tips and tricks : during the first 10min, each of us had learnt at least one new tip.

Conclusion

ROTI

On 5: 3,3,4,4,5. Average: 3.8. Overall this event has been welcomed both by developers and management, which is very encouraging.

Things to improve

Because we wanted to have a randori and thought the problem was «not that hard», we aimed for something very dynamic, with very few time left for discussion. Globally, many participants would have liked more time to define an approach before coding. So next time we will try another format to leave more room for discussion.

Next time

I step aside for the next iteration. My co-organizer colleague will pair with another colleague who was participant this time to organize the next dojo. This is a way to share knowledge and provide help to anyone eager to make this kind of event a true Agile ritual.

That was fun! We will come again!