May 7, 2012
Team Katas. Like, Y'Know, Katas For TeamsThere are lots of well-known programming katas that individuals and pairs have been using to hone their craft. So far, though, there's been a tendency for these katas to focus on a small subset of disciplines - in particular Test-driven Development - and to stop short of creating anything more complex than a bowling game or Conway's Game of Life.
But what about all the other skills a software developer needs? Usually, what we're working on is more complex than a single algorithm, and usually we're working in teams, tackling different aspects of the problem in parallel.
Code katas tend not to exercise our communication skills, or disciplines like collaborative design, continuous integration and the whole messy business of delivering working software that does what the customer needs.
Then it suddenly occured to me this week, while running a 2-day workshop on collaborative design, that this whole workshop is a Team Kata. Well, potentially.
The group is split up into pairs and assigned different user stories for a community DVD library management system. They have to design and implement their aspect of the system in parallel with everyone else.
I act as the customer, and each pair has to agree an acceptance test with me. The ultimate aim of the exercise is to deliver working software that passes these acceptance tests. Ideally, it should be well-designed and maintainable, too.
I've done this sort of thing without applying programming and team disciplines, and it can be an utter train wreck. It sounds easy on paper: half a dozen or so simple user stories, a handful of core application classes and a user interface with a handful of views. For a single pair working on the stories in a sequence, it's a bit of a doddle. But for a team working in parallel, it's surprisingly tough. We measure delivery by how much of the acceptance tests we can pass at the end of the second day, and - so far - no group has delivered more than 30%. Collaboration is hard.
But, like all disciplines, it gets easier with practice. I'd wager that the same group, given a chance to repeat the exercise, would deliver considerably more the second time around -even if we gave them a completely new set of user stories for a different problem.
What always amazes me is that, in 2 days, with a bunch of UML training taking up some of that time, these groups deliver anything at all. I've watched some pretty experienced teams chase their own tales for a week before they even get a build up and running. The communication overhead defeats many teams, in my experience, and this is something that we can work on with deliberate practice.
So I'm proposing the notion of Team Katas. Get the whole team undertaking a group exercise to solve a shared problem, and vary both the problem, the rules of the exercise and the make-up of the team to sharpen those team skills and keep everybody frosty.
Posted 6 days, 8 hours ago on May 7, 2012