Architectural Katas

Rules

The rules are broken down by the different Phases of the exercise. However, one rule trumps all the others: Any other questions that are not already covered by these rules, you may ask the Moderator about. When in doubt, ask.

Preparation: Getting your project team together

The first step is to assemble your project team. There are only a few rules regarding the composition of your team:

• Co-workers may not be in a group together. Obviously in some cases (such as when this is being done internally within a company) this will be impossible; in that case, seek to avoid teaming up with people with whom you work regularly.
• Make sure you’re sitting a little distance from any other project team. You’ll want to make sure you can converse with your team without a lot of competition noise from other teams.
• None of you will really need a laptop. The point of this exercise is not to spend the entire time looking stuff up on StackOverflow or on Google/Bing/Yahoo. At the worst, you’ll want a silicon-based device to access this site, and to maybe help organize your thoughts.
• Procure supplies. However, having notepads, whiteboards (if they are available in the room), and/or flip-charts to scribble on and debate over are very helpful, and it might not hurt to score a few before the other project teams take them all.

Once that’s done, select your kata and proceed on to the Discussion Phase.

Discussion Phase: Figuring out what you’re building and building it

For the next “N” minutes or hours (depending on what the Moderator tells you), your project team will now examine the requirements for the kata as given, and work out a rough vision of what the project’s architecture will look like.

• You may ask the Moderator any questions you have about the project. The Moderator is your customer, your boss, your project manager, your IT ops guy…. Basically, the Moderator is everybody except you.
• Any technology is fair game. Customers really don’t care, most of the time, what kind of technology you use… until they care, anyway. Just because this exercise is being done at a particular conference or user group doesn’t imply the Moderator requires you to use that technology; if something else makes more sense, run with it! Just be prepared to defend its use during the Peer Review Phase.
• You may safely make assumptions about technologies you don’t know well. However, any assumptions you make under this rule must be clearly defined and described during the Peer Review Phase.
• You may not assume you have hiring/firing authority over the development team. No assumptions of developer All-Stars; assume that a development team roughly as skilled as the one you work with on a daily basis will be doing the implementation.

The Moderator will give you some kind of audio and visual cue when your time is getting low, and then at some point, time will run out and it will be time to move on to the Peer Review Phase.

Peer Review Phase: Presenting your architecture to the rest of the group

During this phase, your project team will be doing one of two things, either presenting to the rest of the group, or listening to other groups’ presentations.

If you are presenting, you must…

• … present a vision of your proposal to the rest of the group. If you have not yet selected a speaker (or speakers) for the project team, now’s probably a good time to do so. Remember that “brevity is the soul of wit”, and keep the presentation to a speedy minimum. The Moderator can describe the requirements of the project to the rest of the group if necessary, and will speak with the customers’ voice during your presentation if required.
• … answer questions from the others about your proposal. Remember, these are questions about the project, not about you or your overall technical skills. As difficult as it can be sometimes, try to remember that these are not personal assaults on your character or your professional integrity, but attempts to find the holes in your thinking that you’d rather be found before the project ships.

If you are listening to the other groups, then your job is to ask questions of the project team currently presenting. Please try to keep the questions constructive, but feel free to openly question any choice or decision that you think might not have been carefully examined or thought out. If the conversation devolves into a shouted “Yes it does!”/”No it doesn’t!” kind of back-and-forth, the Moderator may send you both to your room without dessert. Remember that project teams may assume anything about a technology they don’t know well, so long as that assumption is clearly spelled out; if they assumed something that you know to be false, by all means inform them of that, but bear in mind that someone else in the room may have different experience with it than you, and keep an open mind.

Voting Phase: Final feedback on the proposal

After each project team has finished their presentation, then we move to the voting phase. The Moderator will call out a “1-2-3”, and you will each individually give the project team an overall feedback vote:

• Thumbs up: You thought they nailed it. They had answers for all of the obvious questions, they had chosen tech that at least seems credible and feasible, and they have a basic vision of the project that doesn’t have many (or any) murky areas. This doesn’t mean they have every answer, or that they have already produced a UML diagram, it means that you have every confidence they could produce them given enough time.
• Thumbs “meh” (out to the side): You thought they missed a few things, enough to make you a bit uncomfortable that they really have a clear vision of what they’re trying to build. They forgot some key questions to ask the customer, they forgot some important aspect of the project, or they just in general didn’t give you the feeling that they really “got it”.
• Thumbs down: You thought they missed it, badly. They made major assumptions that you think had no validity to it. They never asked the customer any questions and got burned on a few bad assumptions as a result. They thought that using assembly language to build a website was a good idea. They really bungled the job, and you would never want to work on this project.

But all is not finished! Once the voting is complete, the ancient Klingon proverb must be heeded: “Revenge is a dish best served cold”. The project team departing the stage chooses the next project team, and we repeat again by going back to the Peer Review Phase for a new project team.