Coding dojo – a great team builder
Lately another team organized a coding dojo. The feedback was great.
The idea of a dojo is quite simple. You set an objective for about 1h of dev (games are cool). You begin with a pair of developers. All others must be able to see them and what they do (e.g. using a projector). Developers are asked to say what they’re doing, and apply pratices like TDD. The navigator should also do his job, of course. Every 5 minuts approximately, the pair changes: the pilot leaves, the navigator becomes pilot, and someone else comes in as the navigator.
Just looks like a game, right? But it is helpful for many aspects, not only for technical stuff. In this team particularly, most of the devs attending the dojos were not very experienced in software engineering and agile. Of course, they learned technical things from their peers, like:
- patterns
- IDE features and shortcuts
- coding technics
- refactoring technics
- …
As everybody could experiment these in a safe environment and witness their benefits, it was also a great way to foster XP practices like:
- pair programming
- unit test first
- always refactor
- …
And last but not least, most feedbacks were, quite surprizingly, also about observing how the team interacted:
- what devs knew or not
- how they analyzed problems or found solutions
- how they interacted with their pilot/co-pilot
I was surprized about the outcome of this experiment… not because it didn’t meet my expectations, but because it went way further.
Thinking about it, the coding dojo is close to the optimal compromise between safety and realism for software engineering. You can try new things, observe their benefits, observe your teammates. You can do it without bad consequences but with hands on, in a very short but effective time. I will definitely use it for passing dev messages.
Has anyone tried coding dojo before? Do you have any feedback about it?
AAAgile 