In your experiences, what are some effective ways to introduce code kata practice into an organization or company?
To be clear, I'm not concerned with the usefulness of code kata. I'm interested in methods to introduce this concept to a development team.
The question is "effective ways to introduce X into the workplace". I will not discuss if you should or should not. The way to introduce it is to look at your own organization and determine who is in the right position to introduce it.
In some organizations the best approach is through management. They rule some workplaces, so anything that they don't think is beneficial will be squashed. Otherwise participants will be forced to hide it from management, thus limiting its effectiveness.
In other workplaces the best approach is to get buy-in from a senior developer. They can encourage others to participate. They can get their entire team/project involved.
The 3rd approach is to get another respected developer involved. They have earned enough leeway that their time invested in X is not seen as a waste of time.
After it is introduced, be prepared to collect data and prove that it: increases productivity; reduces defects; or reduces training time.
How you introduce code katas into your workplace depends very much on what you want to get out of them.
In my case I wanted to encourage the use of Test Driven Development so I ran a Cyber-Dojo. With this sort of exercise, the emphasis is not on the code itself, but on the process of writing the code.
We spent an afternoon, in pairs, repeating the same kata, but under different conditions. We started with all groups doing one exercise at the same time. This provided a baseline.
We then discussed some of the basic principles of TDD, had everyone change partners and repeat the same kata. We repeated the same kata to de-emphasise the generation of code and instead concentrate people on the process of naming test cases and the Red/Green cycle.
Then we repeated the kata again, but roughly every 10 minutes one person in each group would move to another group, simulating the rather fluid team environments we often find ourselves in these days.
In the final iteration, we had both partners change every 10 minutes or so into different groups. This helped to demonstrate that with TDD, even the handover from one team to a completely different one needn't necessarily be too painful, since the project should only every be one Red/Green cycle from working.
The interesting thing was, there were few people who had done any TDD before the session, but what TDD knowledge there was rapidly spread until by the final iteration through the kata, most people were thinking in a TDD way or could at least appreciate why it might be beneficial.
People generally said that the afternoon was both fun and informative and we are now looking at other ways to use Cyber-Dojo at my workplace.
Cyber-Dojo, written by Jon Jagger is works incredibly well for this sort of exercise. It is a web based integrated environment for doing deliberate practice of TDD and learning about team dynamics. It has lots of kata's selected specifically to help people concentrate on the process of TDD and not the problem. It also supports a range of languages, from Python and Ruby to Java and C++.
The best thing is, after doing a kata you can then go back and look at the red/green progression (or maybe not *8') of each of the groups participating. It's traffic lights are a great way to visualise how the TDD process works.
If you want your own CyberDojo server, the whole project can be found at github and there is even a Turnkey Linux appliance virtual machine linked from there, which means that assuming you already have VMware player or VirtualBox installed, you can be up and running within a few minutes of downloading the appliance!
One idea is when implementing a new algorithm that is a bit tricky or difficult is have multiple developers implement it independently. More than likely there will be two or more different implementations. Then switch with each other and try and implent the others implementation independently. Then get together and determine which way is best. This way you practice and it looks like you are just getting to the best solution.
One of the developers in my group recommended doing an occasional freeform refactoring that caught your fancy just to prove that it could be done - then revert the whole thing.
That seems to be the best real-world application of a "kata" that I've heard of.
It prepares you for if/when you ever get to do the refactoring for a real issue, and isn't a waste of time on an imaginary problem that may or may not apply to your codebase.
