Using Kata for Improvements

I used to keep coding dojos for my colleagues, and it was sometimes very hard to find the right topic. I recently rediscovered the code kata - I did it earlier, but stopped after a short period -, and got an idea. I’m going to use it for discovering areas where our teams can improve. The setup is very easy: I propose a certain kata to the others with a time constraint. While they are working - the participation is voluntary -, I’m hanging around and looking for certain clues. These clues and the discussions after the session will help me find the areas where we need to exercise more.

After they get used to the code kata style and are able to finish the exercise within the time frame, we go forward with some constraints. In the far future, they will be able to pick their own code kata and constraint, but first there are things which have to be re-learnt and practised more. Here are some of the usual problems:

  • Too much time spent in red

  • Too much thinking before actually doing something

  • Not following the ideas from the clean code book

  • Too large steps

My plan is to come out with good practices in order to show a way to improve these areas, but for now, let’s have a final look at the code kata setup:

  1. Present a coding exercise for the participants

  2. Give them a time frame and keep them informed about the elapsed time

  3. Walk around and watch out for things the guys are doing right and wrong

  4. When the time has elapsed, shortly discuss the experience, share ideas with each other (sharing is very important here)

  5. If there is time left, redo the session from the start

  6. …

We are going to keep these sessions twice a week before the daily stand-up meetings. Usually this time of day is less productive, because not everybody is in the office, people are warming up, having their starting tea or coffee - the list goes on. It is also a good time for doing improvements, but I’ll talk about that in a different post.

One can ask why this style is different from others, and how it is going to help. I see it this way: if programmers have to perform a simple but challenging task under time pressure, they are focusing on it very much. They won’t bother that you are watching what they are doing, or that you are asking them short but focused questions. On the other hand, during pair programming, they may show a picture of themselves as they want to look like, or simply become shy. Time will tell how this is going to work. I’ll keep you posted.

comments powered by Disqus