Knowledge, like most essential resources, is not spread in a useful way. How can teams collectively get better at having a more homogenous and cohesive understanding about the systems they work on? What works best in the long run is to make it a practice. And that practice needs to be short so that it happens often. Little and often.
Bytesize Architecture Sessions was born out of iterating on solving this problem multiple times in multiple teams. This workshop format became so useful, I formalised it to help people try it out on their own teams.
Put simply, Bytesize Architecture Sessions is a series of short workshops. Each session focuses on a small slice of a system. A session lasts between 45 and 90 minutes, and has four well defined parts: Session Goal, Alone Together, Consensus and Summary. You can model your systems using different tools. I suggest starting with [C4 Diagrams](https://c4model.com/). After a handful of sessions, teams generally become more homogeneous in the understanding of their systems, improving the consistency of their vocabulary.
Ultimately, they are building the future of their systems together.
Some telltale signs that a team would benefit from Bytesize Architecture Sessions are when they are facing these difficulties:
- Silos. Due to many factors, teams can end up in silos of knowledge, which makes any large project a lot more painful than it already is.
- Technical Debt. The system has grown and small problems has not been addressed timely. Understanding how to solve the debt while still shipping features requires in-depth understanding of the impacts of potential change.
- Evolving teams. It is difficult to maintain cohesive knowledge in a team that has changed over time.
- All of the above. but compounded and complicated with process problems
Before the session, prepare people. Invite the people with high influence in the system and make sure they know the modelling tool of choice you are planning to use.
As we can see on the diagram above, each Bytesize Architecture Session consists of four parts.
Goal
This part of the session should take five minutes or less and it’s about having a _Goal_ for the remainder of THIS session. A good first session is to model the system that the team actively works on *as it is right now*. Bear in mind that the attendees will have a handful of minutes or less to model this. If the system you are trying to model is too big, choose a subsection to focus on.
Alone Together
This section is the heart of Bytesize Architecture Sessions, it should take ten minutes or less.
First, set a timer for three to five minutes. During this time everyone works individually and quietly on the modelling goal that was just set. After the timer elapses, each person explains their own diagram to the rest of the group while everyone else listens.
This might be atypical, here are few reasons why it’s useful:
- The quiet time allows people to work and think individually, without other voices interfering.
- It helps people focus deeply on the aspect of the system the session focuses on
- Higher engagement levels on the topic for the rest of the session
- Helps participants self evaluate their perceived understanding of the system, highlighting areas where they can focus on learning more
- Understand how other people in the team think of the systems
Consensus
The longer part of the session, lasting between 20 minutes to half an hour.
Consensus is about coming together to create one diagram from scratch with the combined knowledge of the team and the just acquired insights.
It’s normal for things to get a little hectic. As a group, keep on topic by focusing on the goal. The discussions are the important thing here. This is where the team does the knowledge sharing. The model they are building together is an artefact that helps them recall and structure that knowledge.
Summary
The last few minutes of the meeting.
Some retrospection on the workshop. This part of the session is about reviewing what was achieved and what needs to be done next. This step is important because people get a chance to inspect what they learn and how they feel about what they just learned, which helps them learn better.
Do it again!
It is ideal to do the next Bytesize Architecture Session in a week or two. It shouldn’t be so often that it overwhelms people and it should be often enough to keep familiarity with things discussed.
Bytesize Sessions can be used for continuous learning. It’s also possible to set long running goals, for example Bytesize Architecture Sessions can be used to help create a Target Architecture or enable inter-team communication for a complicated piece of work.
Benefits
These are some of the benefits I observed after conducting several Bytesize Architecture Sessions with various teams
* Think in terms of their systems as a whole
* Develop skills in systems modelling
* Learn how to model systems **together**, which improves team dynamics
* As more sessions happen, they increasingly have an **homogeneous** understanding of the system
* See the value of having a shared mental model
* Have better tools to model potential solutions
* Learn to actively listen
It is hard to overstate how important it is to have a valuable mental model. Studies prove that mental models are particularly important when making difficult and time constrained decisions (Besnard et al. #). [^BGB] .
[^BGB:]Denis Besnard, David Greathead, Gordon Baxter. When mental models go wrong. Co-occurrences in dynamic, critical systems.. International Journal of Human-Computer Studies, 2004, 60 (1), pp.Pages117-128. 10.1016/j.ijhcs.2003.09.001. Hal-00691813
Session Logistics
In person
In person sessions tend to take longer. Kicking off the meeting and the consensus section tend to take more minutes than if running online.
Some things you will need:
* Paper and pens for each of the attendees. This is for the section called Alone Together
* Whiteboard, whiteboard pens, whiteboard eraser. This is for the Consensus section
* Sticky notes. This is for the Summary at the end of the session. They can also be handy on the Consensus section depending on team dynamics
Online
Start with some rules. Since this is a workshop where everyone is expected to actively participate, tell everyone to turn off notifications on their computers. Depending on the people in the meeting, ask them to turn off their messaging systems (slack, teams, etc) with the promise of reminding them to turn it on again at the end of the session.
You can use any video call software you have access to. A good complement to the video call is an online diagramming collaboration tool.
Since attendees are all remote, timing is more important. Be strict with it.
Hybrid
If some of the guests are in one location and others are remote, run the session as if it was online. People in the same location will benefit from being in different rooms.
Andrea Magnorsky is a programmer and entrepreneur currently based in the New Zealand. She is a founder and is well-known in the programming community for her contributions to functional programming and software architecture. Magnorsky has over 20 years of experience in the software industry and has spoken at well-known international conferences and events on topics such as game development, functional programming, and software architecture. She is the creator of Bytesize Architecture Sessions.
Some of the initiatives she played a key role in:
- In the 2010s Magnorsky co-founded BatCat Games, a PC and Console game development company in the Republic of Ireland. She left the company before the end of the decade.
- Kats Conf. A programming conference that ran twice in Dublin, Ireland.
- Global GameCraft . A community that runs game jams, mostly in the Republic of Ireland. There were some events in London, Derry and New York.
- She also has an interest in History and Philosophy of Computing. These are some talks she created on the subject: