See all posts

Architectural Katas

by Tommi Kenakkala | 28 Sep 2022
Software architecture ● Software design ● Software engineering ● Software development ● Ways of working

Foreword

Continuous learning is part of Agile way of working. At Solita we tried out how the Architectural Katas -exercise is suited to learn software architecture designing skills together, and to “cross-pollinate” knowledge between teams and projects. Here’s how one such session held at a Solita office went.

(Thanks to Heikki Hämäläinen for promoting the Architectural Katas at Solita!)

Workshop session collage photo

Architectural Katas

What

The Software Architecture Katas is a method for learning how to design software architectures in a group and sharing that knowledge. It is a lightweight group exercise which requires from little to no preparation work.

Why

Software architecture design work is a practice which usually is not done continuously. Most design work is usually focused on the beginning phase of software projects. Also, software architecture design work may be an amendment of an already existing design. This leads to the problem of how you can learn and improve a skill, if you get to practice it only now and then?

Here’s where Architecture Katas comes to the rescue.

How

The Software Architecture Katas method is explained well by e.g. http://fundamentalsofsoftwarearchitecture.com/katas. Do check that out for more details, it is a quick read.

In short:

  • Select an organizer
  • Select a Kata
    • If you want to compare group results then select the same Architectural Kata scenario for all groups. We chose this to stimulate discussion and have fun together.
    • Alternatively, you may select a different Kata for each group if you want to study different use-cases in the same exercise session
    • List of katas or a random kata
  • Select one person to play the role of a customer
    • The customer shall familiarize oneself beforehand with the selected Kata. Don’t worry, they are straightforward!
  • Organize a meeting, for example 2 - 2,5h in total
    • A face-to-face meeting is most effective, but remote via shared screen is possible
    • Set time limits depending on the number of groups, for example:
      • 15 minutes for introduction and forming groups
      • 45 - 60 minutes for group work
      • 30 - 60 minutes for presentations and wrap-up
    • Form groups
      • Avoid having current team members in the same group
    • Customer presents the Kata scenario using 1 - 3 slides
      • Groups may ask questions from Customer after the presentation and during the group work
    • Groups move to a suitable place to do the group work using a whiteboard, post-it notes or any other preferred weapon of choice
    • After the group work timeslot is over each group presents their solution and reasoning
      • Other groups may ask questions
      • The other groups do a quick voting round. Groups vote if the solution is good for the scenario, if solution misses it badly or if solutions is something in between. Voting can be done, for example using hands: thumbs up, thumbs down or thumbs to the side.

Experiences

On innovation

Ideas and cogwheels CC0 1.0

In innovation what matters is quantity over quality, regardless of if you are doing it alone or within a group. Quantity means producing as many ideas as possible - both suitable and bad! Quantity is important because in innovation the best idea is usually a synthesis of several alternatives. Stopping after the first solution candidate is likely to miss variations which would make it even better. Keep in mind that there are many different approaches and solutions to a problem. Software specialists have the same problem as people in general: if you have a hammer, then all problems look like nails. That is why in teamwork it is important to encourage the quiet members of a group to bring their own point of view to the table. People have different points of view and different observations, ones which others may have missed.

On Architectural Katas

We found the Architectural Katas method to be a good fit for its purposes. Especially important is how the exercise is well suited for sharing knowledge between different project teams or teams from different organisations. Those typically work on different business domains and with different design challenges. Sharing approaches coming from such different environments is interesting and fun!

During Architectural Katas innovation and design happens first within a group. Then a second time during the presentation and discussion parts where the diverse ways to tackle the problems are shared, explained, and challenged. We enjoyed doing the Architectural Katas exercise. It was interesting and we plan to have the exercise regularly.

Thoughts on how to carry out the exercise

  • If a key skill is required to be included in each group, consider shuffling groups to balance the skills. On the other hand, you may accept this and see how it turns out.
  • People currently in same the work team should not be in the same exercise group. This way we avoid the “doing it like we always do” phenomenon and share the “cross-project” and “cross-domain” experiences.
  • If you have carried out the exercise already a few times and want to create variation, you can try having the Customer overlook mentioning some important quirk or a need. This is what often happens in real life. The constraint should be such that it can be detected when a group asks questions. This will teach the teams the importance of asking questions.
  • Alternatively, you may add a constraint or requirement, for example: “technology X cannot/must be used”.

Cheers, and see you in the next workshop!

References