Rules of Architectural Katas

Original rules are explained here: https://archkatas.herokuapp.com/rules.html.

The rules are broken down by the different stages of the exercise. However, one rule of thumb is: Any questions that are not already covered by these rules, you may ask the Moderator about. When in doubt, ask.

I. Preparation: Getting the project team(s) together

Team(s) will be selected randomly by the moderator. There are few rules to keep in mind:

  • Co-workers should 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.

  • None of the people will really need a laptop.

  • Use whiteboard / flipcharts as they’re better for the presentation later.

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

For the next 45 minutes, the project team(s) 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.

They may ask the Moderator any questions you have about the project. The Moderator is a customer, boss, project manager, 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 team uses… until they care, anyway.

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.

III. Review Phase: Presenting your architecture to the judges / rest of the teams*

There are two options here - either Moderator defined independent judges, or the other teams will be the judges of each other results.

During this phase, the project team(s) will be presenting their proposal.

Presentation:

  • Present a vision of the proposal to the rest of the group. 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 judges / others about the 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.

IV. (a) Voting Phase: peers vote

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.

  • 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 really bungled the job, and you would never want to work on this project.

IV. (b) Voting Phase: Judges vote

Group of judges (at least 2) will score the teams using the similar criteria as described above. Some sort of feedback should be given to the teams.