At Tyro, we don’t have anyone with the title of Architect, Designer or Tech Lead who designs software and then asks other people to build it. Instead, each team of Software Engineers does architecture and design as part of their iteration planning sessions for the stories we’re taking on.

As a Team Lead, the two main goals I keep in mind for each person are: keep them happy and keep them growing. One of the ways I try to ensure this happens is by meeting with each person regularly so we can chat about how to make sure these things are true or at least heading in the right direction.

A topic that’s come up with a few people lately is software design and architecture. Specifically, I’ve had a couple of comments along the lines of: “When we’re designing things, I want to contribute more, but I’m not really sure where to start.”

Now, we’re not designing huge new systems every fortnight. Each team receives a mix of stories, features and epics over time, so while each team gets their hands dirty with planning big stuff, in reality this big design only happens in each team once every few months. In the iterations in between, the team will often be building out new capabilities on top of the big picture sketch they planned at the start. (See The Hamburger Method of splitting stories, if you haven’t already.)

Because we expect everyone to be involved in design and architecture, but we only do it in anger every couple of months, we have a problem: we want people to be good at something that they do rarely!

Enter: Design Kata

Almost every skill is enhanced by using it frequently*, so the first idea that popped into my head was to increase the frequency at which we design software. The business only needs us to design new stuff every few months, and even then it’s not always big changes, so in order to skill up we’d have to manufacture some opportunities for design.

_{* I’m sure there’s brain research on that, but you can look it up yourself!}

You may or may not have heard of code kata before: they’re collections of programming practice problems where the goal is to learn something by practising writing code to solve a particular problem, then throw it away, and sometimes even doing it again in a different style. It’s typically code that wouldn’t even be useful to you at your job; you’re just doing it to practice.

So I thought we could do something similar but different, by designing software just for practice, and then throwing away the result, with a little discussion thrown in so people can share ideas.

I’m not under any illusion that this idea is entirely novel, by the way, but I hadn’t heard or read about anyone doing this before, so I thought it would be useful to write up what we’re doing.

---

Design Kata: The Process

We’ve run two Design Kata in our team now, so the process is still refining, but here’s what we’re doing at the moment:

Design Kata Preparation:

Invite the team and book a meeting room. We’ve been running these in the hour before lunch, and I think that is probably the best time. Compared to (i) first thing in the morning, (ii) straight after lunch or (iii) late in the afternoon, I think late morning is when people will have the most mental energy for designing something novel. The room must have a whiteboard or some other wall you can hang stuff on. It should be the quietest room available, as most of the meeting will be silent thinking.

Imagine a feature. Ideally, you want it to be something that is either in the same domain or very close to the one in which the team already works. It’s best if the feature is something meaty, maybe something which would take at least a month to build. A good source of ideas might be available to you if your Product team have a roadmap, or you could look at innovative features that competitors have which you don’t. Alternatively, if another team has just started on some big feature and no one has been tainted by seeing what they’re doing, you could use that. If you run out of ideas, just re-design Twitter or Facebook. 😉

Write some stories & print them big. The first time I ran one of these, I just wrote up the feature on the whiteboard: “Our customers will be able to X.” This resulted in quite a lot of questions before we started designing and quite a lot of head scratching during the design time as people tried to figure out what the feature actually entailed. The feedback was clear and unanimous: provide more flesh on the idea. The second time I turned the feature into about 15 stories, with both external and internal customers, and this worked much better. I also printed each story on A4 paper in the largest font that would fit. It’s also good to keep the stories in some sort of order, e.g. describing the core functionality first and then the supporting or frilly features, or bunching all the features used by the support team together. People who hadn’t gotten very far with their design the first time (because they were too busy wondering what it was they were designing) produced far more comprehensive ideas the second time around. Final tip on stories: number them. That way, as people draw their design, they can annotate it with the story numbers which helps them when they’re walking people through the design later.

Print off several copies of relevant architecture or design diagrams. Another great piece of feedback from our first session was “I don’t really know enough of our architecture off by heart to know where these new bits should hook in.” Assuming you have some existing architecture diagrams, and that your feature idea extends on your existing system, bring these along. I was worried it would be a waste of paper, but people used them quite a bit, and I’ve kept them for next time. Two mistakes I made with this in the second session, though, were (i) bringing irrelevant diagrams that just made it harder to find the useful ones and (ii) not brining enough copies of the relevant ones.

Running the Design Kata:

Bring:

• story sheets
• architecture or design diagrams
• magnets or Blu-Tak
• 2x blank A4 paper for each person attending
• (tell people to bring their own pens and notebooks)

Explain the purpose. Just so everyone is on the same page, explain that the point of the session is for everyone to spend a little bit of time practising design, and to share what they come up with so that others can learn from it.

Describe the format. People like to know what’s going to happen, so it can be good to explain the details of the following activities before moving on to them. (Or you could just have your team read this blog.)

Name the feature at a high level. Maybe write it at the top of the whiteboard.

Present the stories. One by one, stick each story sheet up on the whiteboard or wall with magnets or Blu-Tak. Read it slowly so people can let it sink in, and leave a pause after each one so that people can jump in with any burning questions.

Hand out the materials: blank paper for each person, and the architecture and design diagrams. Leave some extra blank paper in the middle of the table in case some people decide to start from scratch.

Ask if people have any clarifying questions. There shouldn’t need to be any long discussions, but if people think something is really unclear, you should deal with it here, otherwise it will bug them for the rest of the session. Avoid the temptation to become a Product Manager at this point and to start answering every question by delving into detail. Remember this is only a practice exercise, so the details don’t actually matter. I’ll often turn a question around by asking, “What do you think would make the most sense?” and no matter what the answer is respond with, “okay, let’s go with that.”

Make it clear what the designs should focus on. A design diagram could contain lots of different types of detail. If there are particular things you think people should be focussed on, call them out. One thing I usually ask people to annotate is which of the interactions in their design will be synchronous calls and which will be asynchronous messages. We’ve had some people invest thought into where crucial attributes of the data model will be persisted, and that’s also proved useful.

Encourage people to make assumptions. The stories will be rough and not well thought out. Rather than try to drill further into details during the design time, tell people to just make an assumption that seems to make sense and to note that down to share later.

Remind people to think about why they are making decisions. Some decisions will be no-brainers and almost everyone will choose the same path. Others will require some thought and perhaps a trade-off, and different people will choose different solutions. These parts often make for the most interesting learning at the end, so ask people to either specifically remember these decisions or to jot down a note about them as they go.

Tell people how long they’ll have. We tried 15 minutes the first time, which seemed to be a little short for many people. The second time we tried 20 minutes, and as 20:00 rolled around I asked, “Do people want another five?” and there was a majority of nods, so we went for 25. The right amount of time probably depends on the number stories and the amount of detail in them. I think around 20 minutes is probably a good mark to aim for, as it keeps it as a short, sharp ideation/practice activity rather than a drawn-out mini-exam. Remember it’s not a test and no one’s being evaluated, so it doesn’t matter even if most people don’t finish designing for all the stories.

Start the clock and start designing. This is the meat of the design kata but there’s not much to say about it. People should work individually, as quietly as possible. Questions are okay if necessary, but hopefully they’ve been covered earlier. The facilitator should also spend this time drafting a design. I didn’t do that the first time, but then my team said they’d be interested in seeing what I would do.

Give people time updates. Half way through and 2 minutes before the end are usually good points.

At the end, discuss what you’ve done, and why. Once everyone’s put their pens down, pick someone to go first and go around the table having each person explain their design. In particular, people should describe decisions they made along the way and, most importantly, why they made the decisions they made. You could allow a time after each presenter for others to ask questions (we haven’t done this yet, but it’s something I’d like to try). Just remind people that this is a good time for them to ask things like “I’d like to know why you did this….”, but that critiquing other people’s efforts is not on the agenda. The learning happens by practising and by seeing what others do, not by being told you’re wrong. Remember, even if you see a design that’s flawed in fundamental and catastrophic ways, this is only a practice and it won’t be implemented, so it doesn’t matter!

Review the session. It’s good to get feedback after a session like this, especially the first few times. I’ve been asking everyone to rate “How useful was this?” by writing 1 to 5 on a sticky note. After we’ve all had a look at the results, I’ll ask what we could do differently to make it more useful, which is where a lot of the tips from above have come.

Ask if people want to do it again, and make a date for the next session. At the moment, we’re doing this once every four weeks, which seems to be a good frequency. We’ll probably taper that off after a few rounds as people’s confidence with approaching real design work increases.

---

How useful are Design Kata?

I can only tell you how useful our team is finding them. After the last one, four people gave the session a 5/5 and three gave it a 4/5. That’s some pretty solid feedback, so we’ll be probably be continuing them until people stop getting value out of it.

Other Design Kata Ideas

There’s two other things I’m keen to try in the future. The first is to get people on the team other than me to come up with the feature and stories (mostly because I’m worried I’m going to run out of ideas pretty quickly and I hope others might have cool ideas up their sleeve).

My other idea is to try out a process used in the IDEO-inspired design sprints run at Google Ventures, where people place coloured dots on the parts of other people’s designs that they particularly liked, which creates a rudimentary “heat map” of where good ideas have appeared.

Update (September 2015): Our team came up with another idea as an outcome of a recent retrospective. There was an issue raised that we had trouble in our last planning session deciding which microservice an ancillary responsibility should live in, and we picked the wrong one, which resulted in some re-work. The outcome was that, in future design kata, we should deliberately discuss in which services particular responsibilities will lie – and why – in order to practice making those decisions.

Should your team do Design Kata?

Maybe! But only you and your team can really decide that. We’re not doing them just for kicks. We do them because a number of people in our team wanted to improve their design skills, and it’s important in our company to support them in doing that. Our context also includes a large, existing service-oriented system that we can easily pretend to extend with new designs, and a team of engineers who each has a fair amount of experience under their belt, so they’re not completely new to software design. If you’re in a similar context – people with a desire to improve their architecture & design skills and an environment where it’s easy to have practice runs – we can highly recommend design kata as an effective (and fun!) way to practise design skills.

Can you do solo Deign Kata?

If you don’t work in a team of software developers, or you’re in a team that wouldn’t find this useful as a team activity, you can of course practise this type of design kata yourself: just come up with an idea for a new system or an addition to an existing one and start drawing! Remember, though, that while a lot of the learning comes from just practising, there is also heaps to be gained from seeing how others would have done it differently, so consider finding a friend or two in the same situation and maybe ask them if they want to start a lunchtime group or a kata correspondence or something like that.

Have you tried this at home? Share your learning!

If you try this with your team, or you’ve tried it in the past, I’d love it if you could share any tips you have in the comments below so that others can learn from your unique experiences. Thanks in advance!

Image credit: ‘Karate Kids‘ by David Vega