The Architecture Game: An Approach for Learning

How Sawyer’s engineering team incorporates play into knowledge sharing.

I joined Sawyer a few months ago and set out to understand if there were any areas that needed improvement on the Engineering teams. During my early conversations with our software engineers, one area of the product kept coming up: the shopping cart. Every new product feature requires making modifications to the shopping cart code base — but there was a problem. Only two people were familiar enough with the existing cart architecture to make changes with confidence. This stood out to me as a huge opportunity to use knowledge sharing to solve a problem.

How could I get the ball rolling? During my time at Meetup, teams managed code ownership transitions with an exercise called the Architecture Game. This activity was well-regarded for being useful and enjoyable for every engineer involved. I never sat in on one, but was curious to recreate the game at Sawyer.

I asked around and discovered that Ken Shih, a software engineer at Meetup, had designed the game. Ken was kind enough to have a call with me to walk through how to plan and play it.

Unlike a traditional architecture walkthrough where a subject matter expert whiteboards or presents diagrams, the Architecture Game flips the knowledge transfer around. The students — in this case, the engineers learning the architecture — dictate what gets covered and when. This fully interactive approach to learning interested me. In past experiences, I had seen presenters spend too much time on one area or gloss over something important, resulting in the audience missing useful information.

Next, I set out to clarify the goal of the game:

Uncover the current architecture of a system, subsystem, or area of a feature/functionality that only one person or a small number of people have solid knowledge of.

The reason I wanted to focus on the current state is so every engineer would start with a consistent baseline understanding of it before attempting to improve it, add to it, or refactor it.

After talking to Ken, I wrote the rules to Sawyer’s version of the Architecture Game. I defined five roles: the Facilitator, the Architect, the Players, the Scribe, and Observers (a new role that I wanted to experiment with). The subject matter expert assumes the role of the Architect. The Players are the ‘students’, in charge of asking questions and guiding the discussion. The Scribe is a Player tasked with documenting everything uncovered. Observers, an optional role, could sit in on the game. The gameplay consists of players asking questions, with the goal of teasing out the full architecture for that area of the system.

Not knowing how much time we needed, I scheduled 2 hours for our first game and decided to be the Facilitator. The Architect and Players were chosen ahead of time, a couple Observers were invited, and I left the selection of the Scribe until we were all assembled.

How did it go?

We had two engineers join remotely for the game without any hiccups because we used a physical whiteboard in our office and pointed a camera to it so that everyone could see it. To kick things off I re-stated the goal of the game and went through assigned roles. One of the players volunteered to be the Scribe. I then handed things off to the Players to start asking questions and begin the knowledge share.

During the first hour, the group covered a lot of ground about the cart implementation. They soon discovered there were related topics that required a deeper dive at a later time and designated them ‘Parking Lot’ items. Tangents weren’t unproductive — instead, they were often tools to inspire future sessions. As the facilitator, I also nudged the group back a few times from conversations that took them away from the current architecture.

After one hour, everyone took a short break. When we re-assembled a different Player took over as Scribe and the discussion continued through the next hour. By the end of the game everyone had a complete picture of the overall cart architecture and a great list of follow-up topics.

In order to see how the team enjoyed the game, I sent out a brief survey to everyone who participated. The feedback was overwhelmingly positive and everyone said they would want to use this format again. One participant wrote, “I enjoyed the collaborative effort to understand a portion of the codebase that can be quite confusing. I also enjoyed hearing about the design decisions around the cart. The team asked some great questions that I haven’t asked myself.”

The Architecture Game will be played again at Sawyer, but a few things will change.

In our next iteration, I may eliminate the use of Observers and instead allow more Players to participate. The original thinking was to limit the Players to people who had the least exposure to the topic. Since I hadn’t defined the Observer role well, one person wasn’t sure whether they should chime in if they had information to answer a question. During the game I clarified that we want everyone to get accurate answers to their questions so anyone that can contribute to that should.

I also want to experiment with a “taking a turn” approach for questions. In our pilot Architecture Game, one participant noted that the more experienced engineers in the room were doing most of the talking. Everyone in a room should feel empowered to ask questions, share answers, and explore discussion topics.

Want to play the game with your team?

The Architecture Game proved to be a very fun and useful exercise. If you’re interested in implementing this for your team, here are instructions for running the game:

• In advance of the game, select one topic or area of existing architecture. This should make it clear to the group what the scope and boundaries are.
• There is one Facilitator who keeps the game moving and focused. This person should also ensure the environment and tone of the session are blame-free. This is not a time to criticize past decisions or suggest alternate approaches.
• There is one Architect designated for the game. This person should be able to accurately answer the most questions about the selected topic.
• There are 1–4 other Players
• One of those players is chosen as the Scribe. This person is responsible for documenting and whiteboarding during the game (on-the-fly) and publishing documentation after the game concludes.
• Additional people may join in as Observers. They will not play and should be expected to not distract or harm the game
• The Players (including the Scribe) take turns asking the Architect questions in order to get a complete picture
• The Scribe draws/writes as answers are provided, and adjusts diagrams as needed
• The Architect is not allowed to go deep into previous versions of the architecture or into alternatives or abandoned/future plans. This should be deferred to follow-up conversations. They are encouraged to explain why the current architecture exists if needed.
• The last 5–10 minutes of the game should be reserved for cleaning up the documentation and sending it out to everyone who attended. If you’re using software to create the diagrams during the game, this is easier. If not, just take photos and designate someone to convert it to digital graphs afterwards.