In the last months I’ve been in touch with a lot of people trying to start their own coding dojos. Here’s some tips for those who already started or are considering it:
Setting up
You don’t need much more than a place with one computer connected to a projector and enough sits for people attending. A timer to keep track of the pair rotation and a white board or flip chart to discuss the problem are also very useful.
If providing foods and drinks is not in the plan, at least don’t forget to have enough water for people in the room. Breaks are acceptable, but the idea is to get people focused most of the time.
Introducing the dojo to new people
In my experience, the dojo is not suitable for everyone. Not that you have to be special to be part of it. Not at all.
The problem is that people are used to learn in different ways. Some don’t like to slow down and see things they already know being done step by step. Those will become inpatient and probably get in the way of those seeing things for the first time. In other cases, people are so used to learn by themselves that is hard to share this process with other people. There’s also people who will simply find the problem too easy/hard to solve and therefore useless for them.
My suggestion in this case is start with people who already know how the dojo works. Even if it takes doing a small presentation to explain it. Show that the point is not the problem itself. The point is deliberate practice. If people accept that before the meeting starts it should flow way easier.
The right style and size
The number of people is also important. Is very hard to run a randori with more then 10 people. Specially if they are new to the dojo. People approach a problem in different ways and it may become hard to listen to everyone’s opinion in this case.
In the other hand a kata can be done with more people at the same time. This approach requires some effort to prepare and practice the solution for a challenge, but may help to introduce the idea of the dojo before getting everyone involved in the coding.
Choosing the coding challenge
There are load of sources for problems out there. The guys from Dojo São Paulo have a list in their wiki, but in principle any well known problem is okay. I really like something like Mine Sweeper to get people started, and then let them help to choose new problems based on that first experience.
Remember that starting with a completely new language is a good idea only if people do their homework and try to learn the basics before the meeting. Otherwise the meeting will be only for reading documentation instead of coding.
Don’t forget the retrospective!
The dojo is a place for continuous improvement, and the retrospectives are essential to achieve that. It’s normal to have some problems during the meetings, but there’s no excuse to discuss them and do things better next time. For the good things is also interesting to discuss to acknowledge what’s working and try to keep them.
Try to get everyone’s feedback. If people are not motivated to talk, well, that’s the first problem to be solved.
Now that you’ve started…
… It’s time to merge with the software community around you. It’s easy to find more people to attend to the meetings. Simply invite and they will come. I try to attend all the dojos I’m invited because I know how much I learn every time I see other people programming in front of me. For the same reason I’d like to always have new people in my dojos.
I hope to be inviting people through here my dojos soon. At the meantime, I’d be happy to help anyone interested in starting a dojo. In this case, just let me know.