The Vague Briefing
Hand out the problem statement and say “go.” Everything they need to know is in there somewhere.
Commonly affects: First-time facilitators, facilitators running katas outside their usual group.
The Anti-Pattern
Skip the introduction. Don’t explain what the kata is trying to achieve, what the deliverables should look like, or how much time teams have for each phase. If someone asks “what are we supposed to present at the end?”, tell them to figure it out. Context is a crutch real architects thrive in ambiguity.
For bonus points, don’t explain what an architecture kata is. Assume everyone in the room has done one before.
Why It Feels Right
You don’t want to over-explain and kill the exercise’s open-endedness. The problem statement is written down, the time limit is on the slide what more do they need? Over-briefing feels patronizing, especially with senior participants. Besides, figuring out the process is part of the challenge.
The Catastrophe
Teams spend the first 15 minutes asking each other “wait, what are we supposed to deliver?” instead of working on the problem. Some teams design a full system while others produce a single component diagram because nobody clarified the expected depth. Teams that have never done a kata before are completely lost while veterans charge ahead, widening the experience gap instead of closing it.
At presentation time, the formats are all over the place. Some teams present trade-off analysis, others demo a technology choice, others walk through a deployment diagram. The review becomes impossible because there’s no shared baseline for what “good” looks like.
The Rescue
Invest 5-10 minutes upfront to set the stage clearly:
- Objectives. Explain what the kata is meant to practice (e.g., “Today we’re focusing on identifying architectural characteristics and mapping them to patterns”).
- Deliverables. Be explicit about what teams should present: a context diagram? Component-level design? Trade-off analysis? ADRs? Name them.
- Time structure. Break down the session: X minutes to read and ask questions, Y minutes to design, Z minutes to present, W minutes for feedback.
- Ground rules. Can teams use the internet? Can they ask you questions during the design phase? Is there a specific notation expected?
- Experience calibration. If the room is mixed, briefly explain what an architecture kata is and how it works. Veterans won’t mind the 2-minute recap; newcomers will be grateful.
A well-briefed team hits the ground running. A poorly-briefed team hits the ground arguing about what the ground is.