Architecture drawing exercise

When looking at teams of developers it's rare to find all members at the same skill level. Even in those rare occasions, they are likely to differ in their communication styles and in mental model of the system they are working on. On the other hand, it's important for team members to be able to communicate efficiently and to have a share common model of the application architecture.

In the team I lead there are members with different skill levels, and we are developing and supporting multiple production services. I wanted to simultaneously:

Here's an exercise I came up for achieving this.

Rules of the game

Players sit in a circle, for example around a conference table. They should have some space for themselves on the table, and they should have a clear idea of who the next person around the table is. At the beginning of the game, each player is given a peace of paper with a name of one of the team's services written on the top.

In the first round, which takes 7 minutes, each player must draw the architecture of the service named on their paper. They must not use any letters or numbers in their diagrams. Other symbols, arrows, etc are permitted. After they're done drawing they should fold the paper so that only the diagram is visible and pass it to the next person around the table.

In this way papers are shifted by one place, and each player is now presented with a drawing of an architecture diagram. In the second turn each player must guess the service that the diagram is depicting and write its name on the paper. This turn is a bit shorter, lasting at most 5 minutes. After the time expires, or everyone is done, each player should fold the paper again so that only the service name is visible and pass it on to the next player.

The third turn is the same as the first one, with all players drawing the service named on their papers, folding them and passing them on. The game continues with a succession of odd drawing turns and even service naming turns until papers have made a full circle around the table. At the end all papers are unfolded and the group compares and comments on their diagrams and guesses. Each player picks the best ideas for drawing the service they started with and presents the definitive diagram for it. Those diagrams can later on be documented and refereed back to when needed. Additionally, expressed ideas, iconography, patterns etc. become part of the common visual language of the team and can be used in future diagrams to convey ideas more quickly and precisely.

Takeaways from running the exercise

It was immediately apparent how fun the exercise was for all participants. We've had many laughs through the drawing and guessing parts of the game. It was equally fun to guess the service from others' diagrams and to despair over ones own predicament when having to draw them. The fun helped more recluse team members to open up, and encouraged experimentation while reducing the fear of failure for less experienced teammates.

It was also interesting to see the difference in approach between team members with more and less experience. The more senior people tended to use established diagram types and shapes corresponding to certain architecture component. For example using a cilindar for a database or storage component, rectangle for an application, etc. On the other hand juniors tended to freestyle more, with some of them drawing business processes in almost cartoon-like style.

The rule prohibiting the use of letters and numbers meant that team members had to come up with their own ways of labeling certain architecture components. In this aspect seniority did not appear to play a major role, as all participants approached the challenge with different levels of creativity. Common solutions included labeling third party technologies with their respective logos, and making up icons for internal applications that lack such branding. (As a side note, this got us thinking about developing branding for our in-house applications!)

In the end we agreed on a common set of symbols for representing general architecture components and iconography for particular services. We also created a canonical diagram for each of our team's services.

Review

Later on I collected direct feedback on the exercise from all team members in our by-weekly one-on-one meetings. They all reacted well to it, and reported having fun (that much was always obvious). What was left as an open question is if the gained knowledge warranted the time investment. In the end an equivalent effect might have been achieved if a senior developer on the team took the time to render the architecture diagrams for all services and had juniors examine it and read up on different types of technical drawings.

One benefit of the drawing exercise over this top-down approach is in its team building potential. Since all team members participate in defining the canonical diagrams and common iconography the sense of ownership over the final drawings is also shared. Additionally, those team members who benefit more from affirmation and positive feedback will find the inclusive nature of the exercise rewarding, since everyone's ideas are incorporated in the final design.

If spending some extra time on this type of exercise sounds like a worthwhile trade-off to you, then feel free to run it with your own team! If you do so, I'd love to hear your own results, reaction of your team members and any additional observations you might have. You can get in touch with me: