Having completed a worked example of the kata over the 7 previous articles, let’s look at how we can use the concept of kata as both a workshop activity and as a recruitment tool…
This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.
Here are the previous articles in the series:
All these articles will be focused on the same kata; “I’ll Have the BLT“. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.
Below is a quick summary of what we’ve covered over each of the previous 7 articles. And if you’ve been studiously following along, you’ll see that there’s quite a bit of time needed to work through these sections, identify and reflect on the assumptions you’ve made along the way and iterate over your solution. All in all, it’s a great activity for a rainy day stuck in Covid-19 isolation!
However, there are other ways of using kata which provide different outcomes which still include most – if not all – of these steps. The two approaches I speak of are:
- Using kata in a time-boxed workshop to build solution design and collaboration skills within a team,
- Using kata in recruitment to identify solution design skills in candidates.
I’ve run these sorts of workshops for many groups here at ThoughtWorks and they largely follow the format described by Ted Neward, although I do have some slight tweaks to his process:
Code of Conduct
To make the workshop a safe and inclusive space for participants, irrespective of background or degree of extroversion/introversion, I’ve settled on the following Code of Conduct for my kata workshops:
In short, it says: don’t be a dick, do be inclusive, focus, and criticise ideas, not people.
Largely due to the number of possible communication paths in groups of various sizes (see below), my ideal group size for these workshops is 3, with a preference to groups of 2 rather than 4 (but preferring a group of 4 to people working individually). With groups exceeding 3, the group often splits into subgroups and then suffers from late integration of work.
Within ThoughtWorks, I typically time-box these workshops to 1 hour (which is a tight stretch, but achievable) and use the following time guide for the activity:
which looks like…
If the group(s) are doing their first kata, I’ll be more firm with these time limits to ensure they pay some attention to the role, responsibilities and business processes instead of diving straight into technical solution diagrams.
If it is a single group participating, then I’ll drop #6 and reallocate that time to #5. Sometimes if the group is doing a kata for the first time and I know they’ll have more opportunities (e.g., I’m running a series of these workshops with the same people), I’ll also drop #6 just to take away the concern of sharing their kata with a broader audience.
If I have the luxury of more than on hour (e.g., 90-120 minutes), I’ll make sure to include lots of time for sharing kata between groups. There are always great learning moments when groups see how common/different other solutions are to the same problem. This is basically the Peer Review Phase as described by Ted Neward.
When I play the Moderator, I’m a lot more lazy than Ted Neward suggests:
“The Moderator is your customer, your boss, your project manager, your IT ops guy…. Basically, the Moderator is everybody except you.”https://archkatas.herokuapp.com/rules.html
My default Moderator behaviour is to push the groups to make all the assumptions necessary to build a suitable solution to the problem. Specifically, I don’t play the role of the Customer, largely because of the logistical issues with doing so in a workshop with multiple groups, but also because I want attendees to think deeply about the problem domain.
The Voting Phase
I don’t do it. Groups are perfectly capable of self-concluding how well their solution fits the kata without peer voting.
If I have the opportunity to run the same people through multiple kata exercises (normally over a period of several days/weeks), I take the following approach:
- Start with an accessible kata (“I’ll Have the BLT” works well in this respect, as does Check Your Work and You Look Good In Print.
- Run a second exercise with a different kata (same groups or different ones) and the same approach, but preface it by announcing a specific focus on a cross-functional requirement. Some kata are better suited to specific cross-functional requirements than others. For example:
- Run a third exercise with a different kata (same groups or different ones) with the same approach, with a focus on a different architectural style. For example, switch from predominantly synchronous integration to message-based asynchronous integration.
- Return to the original kata as used in #1 (same groups or different ones) and compare the quality of the resultant solutions. Hint: they should be far more detailed and suitable from #1 to #4.
If you end up in the ThoughtWorks recruitment process (at least for Australia) and are an experienced engineer, there’s every likelihood you’ll have a kata interview at some stage. Effectively these similar to the workshops described above except:
- You are in a team of 1
- There are less need to pursuea formalised process (e.g., Roles -> Responsibilities -> Business Process, etc) to arrive at the solution
- There will likely be more questions from your interviewers challenging your assumptions and design decisions along the way.
If you want to use kata as part of your recruitment process, here is the advice I give people who are conducting these types of interview for the first time:
Areas of focus
Kata gives the ability to assess a candidate across a number of areas:
- On-the-fly solution design (including communication skills)
- Technical breadth
- Technical depth
Assessing each of these areas requires forming answers to a variety of questions through the interview as the candidate’s solution starts to take shape.
How well do they convey their solution design thinking? Is it overly technical? Is it overly business-focused? For example, have they identified the key actors? Have they pieced together a reasonable business process flow involving the actors, capabilities and potential systems?
Is there a logical progression to the way they decompose the solution? Or are they jumping around randomly making it hard for the audience to follow? Have they identified the key capabilities that need a home in the solution?
How comfortable are they with speaking their mind? Do they seem flustered or generally comfortable/confident with the exercise itself?
There are usually statements in each kata which have no real impact on your solution – have they identified these and explicitly discounted or deprioritised them?
Have they brought any relevant domain knowledge to the problem? Have they mentioned typical constraints for the domain? Likely drivers for the solution? Is their natural domain knowledge a good fit for the solution? Have they expressed knowledge of relevant local or international regulatory bodies/rules impacting the domain?
Being aware of the time constraints, have they started building the solution early enough in the interview, or spent too much time digesting the problem itself?
A well considered solution to most kata could include aspects of:
- Software design
- Hardware selection
- Database design
- Application security
- Network security
- Operational concerns (logging, monitoring, etc)
- Data engineering
Time constraints will prevent candidates touching on all of these aspects, but strong performers should be capable of speaking intelligently to most of them. As interviewers, you may want to steer them in certain directions to test their knowledge in one of these areas.
For the non-practising candidate, this is the area where their lack of recent engineering experience will be most apparent, but it is still worth understanding where their knowledge stops.
Often the solutions produced by these people will lean heavily on project experiences they’ve had, so they might end up squashing a known tech stack awkwardly into the kata domain.
Good deep pockets of exploration can be found in the “I’ll Have the BLT” kata by asking the candidate to focus on:
- The data model – particularly around customer ownership and promotions
- Integration approaches – particularly when dealing with existing walk-in customers and online orders
- Inventory management – to allow promotions to minimise the amount of waste
Recruitment Kata – Conclusion
Kata interviews tend to favour generally confident speakers (who wont be flustered with the dual need to think and explain) who can draw upon enough experience from a “close enough” project in their history. If you think this is the case, try to nudge them off the beaten path and into areas they may not have experience with.
It’s all over to you now, dear reader – pick your first kata and enjoy!
Did you find this article useful/interesting?