Want to run a kata at your company? I did it. Here are some tips.

So, a month ago I was visiting my company headquarters and I encouraged my team to hold a TDD session. TDD is kind of hard for many developers. It is a habit, and habits need to be exercised. If you don't exercise it frequently then you fall back into the old and unproductive behavior: write - manual test 10 times - write a test.

Tip 1: Sell it to your manager first

My manager was a bit skeptical. The conversation was a bit like this:

[MGR]: "What is that half-day long session you guys are having?
[ME ]: "Oh, it's a TDD session, we will settle ground on common test practices and then approach problems trying to write the test first."
[MGR]: "What type of practices?"
[ME ]: "The usual. Writing small tests, enforce single responsibility on tests, make sure proper names are used, make sure there are comments, and so forth"
[MGR]: "Don't they know such things? They are senior developers".
[ME ]: "It does not matter how senior you are if you have been exposed to bad practices your whole life".

I was a bit surprised by the seniority question, and it is actually a great point. But the truth is over my last years managing different types of senior developers I found that it really does not matter how many years of expertise you have or how solidly you deliver features. Even for myself, if I don't practice I keep accumulating bad habits. Moreover, as new people join from different companies and with different habits, it's always a good idea to settle some common ground in terms of code practice expectations. So the TDD session still looked like a good idea to me.

Tip 2: Set rules and expectations

You are the master of ceremonies. As such, you should facilitate the session. I am guessing, or at least that was my case, that most of the folks in your team might not be that used to how a kata works. Some rules and limits should always help to put some order. In our case, for example, we started limiting the exercise in time. We would use a maximum of two hours. Teams will also be pairing in teams of two or three people and the person typing would switch every 20 minutes.

We also did hold an Intro to TDD session before starting with the Kata which helped to set what were the expectations for the quality of the tests written. Hence when doing the Kata we would be practicing how expressive our tests were too.

Tip 3: Add some incentives

Add some incentives. Some incentives should make that exercise more fun. Perhaps some prize to the team that finishes first, or maybe having a sponsored lunch if all teams finished their kata which always helps to have more experienced people helping people not that familiar with these exercises ;)

Tip 4: Avoid the usual katas

If you are regular at agile events and familiar with TDD then you surely are familiar with names like Fizz Buzz, Bowling, —Game of Life_, etc. Likely, you are also familiar with all the nice kata directories out there. But you know what? Do you want people to be offended? Then choose one of those.

Don't take me wrong. Those katas are great and some are nicely targeted to certain skills. But those do only work on a neutral ground. A ground, with no roles or grades, where everyone works on different companies and industries, where every attendee is passionate about agile practices.

But getting your coworkers who might even be wondering what are they doing there at a "kata" and making them code a Fizz Buzz could be a recipe for disaster. Some could directly take it as an insult. Pretty likely some will find it frustrating as approaching these exercises is usually not as easy as it seems and then will blame the irrelevance of the exercises chosen as silly algorithms for recent graduates.

In my opinion, if you want the practice to be less aggressive it is simply better to work on some real-life problems for the people you are going to work with. This requires some work on your side. You will have to choose real problems. Things you are facing every week. In my case, for example, I did choose three real user stories we had to complete that same week and divided them amongst the team members. Each team would approach that story as a kata trying to solve the problem with a complete TDD approach.

You might actually find that some user stories are not easily testable. And that is a bad smell too that might need to be worked out. If stories are difficult to test, then how can we expect our developers to embrace TDD?

Tip 5: Have solutions ready for your kata stories

You will have to be ready to help with the user stories you chose. Again, this is work on you, but it will pay off. Some teams will get stuck with their tests, so you need to know how to unblock them. This is pretty important to avoid frustration so in advance to the exercise you really need to know how to approach the test. In the end, the test might be written entirely different from what you had thought of, but if people are having difficulties with the testing practice you need to be ready to unblock them.

The least you want is to approach a problem with TDD and find out that the teams cannot address it. Again, TDD is great, but it needs to be reinforced, and reinforcement comes with success, not with frustration. If you are finding hard to find user stories that are easily solvable for you, then I would argue there is some technical debt in the testing infrastructure that needs to be tackled first.

Tip 6: Repeat. Make this a habit

If this is a one-off thing then, well, it's not bad, but it's not good either. As mentioned before, practices need to be reinforced, otherwise, they will not become habits. You don't need to go to extremes like doing a Kata every week. But I believe that having a team activity for practicing writing code together is something really good and promotes some nice habits like teamwork, pair programming, settling on common approaches, etc.

So definitely if you have the chance, try to do this more often. I'm trying too and hopefully, we will have another one real soon.

I hope this helps you! Good luck!