ThoughtWorks University: Coding Dojo Style
As a result of this suggestion one of the things we’ve done is to change the style of the second week so that it wasn’t full of sessions/workshops but instead involved working on code as a group.
Jim came up with the idea of the 'exploded story' whereby we spent the whole of last week as a group working on one story for Sukrupa while spending quite a bit of time exploring the different activities that playing a story end to end would involve.
We did this by making use of two types of coding dojos:
Randori - two people at the keyboard and the rest of the group watching and contributing ideas about what could be done next.
Kake - one computer per pair but everyone is working on the same problem
We began last week with a Randori dojo where initially two of the trainers paired while implementing a story to add improved search functionality to the sukrupa admin application.
We rotated one of the pair every 5 minutes, initially making sure that there was always a trainer at the keyboard but we quickly changed that so that it was mostly the grads driving the implementation.
The cool thing about using the randori dojo like this was that we were able to code as a group and people were able to get a rough feel for the strengths of their colleagues and see any areas they might be able to improve on.
We were also easily able to see where people were struggling so that we could break out and do a quick session on a topic if necessary.
One disadvantage of this style is that it does put people under a bit of pressure because everyone is seeing the code they’re writing so I’m not sure that it necessarily provides the best learning environment.
We did the randori dojo for a few mornings while doing a kake dojo in the afternoon before deciding as a group that it would be more beneficial to do a kake dojo for the whole day.
We initially ran the kake dojo with 10 minute iterations after which we would discuss how everyone was doing and whether there were any learnings to share.
We pair rotated every other iteration and eventually increased the iteration time to 30 minutes so that we’d have more time to solve some of the more difficult problems.
It was getting really irritating being interrupted every 10 minutes at times!
A few times a day we went around the room to each machine and the pair was able to describe the code they’d written and the approach they’d taken.
We’d then choose as a group which code we wanted to push to the github repository as a baseline and then continue working from there.
I quite enjoyed working in this style and it worked fairly well until we got towards the end of the story and the code that each pair was writing was pretty much identical.
At that stage we switched back to a 30 minute randori dojo before the week was complete!