Bytesize Architecture Sessions are a workshop format that helps teams understand the systems they work on. Each session focuses on a small slice of a system. After some sessions your team will become more homogeneous in the understanding of their systems, grow a consistent vocabulary and ultimately build tools to design the future together.

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.

Consider using Bytesize Architecture Sessions if you experience any of the following common difficulties:

• Codebase Knowledge. Planning for large work requires a solid understanding of current systems. Teams can end up with silos of knowledge, and not see the big picture
• Technical Debt. The system has grown and accidental complexity has not been addressed. Understanding how to solve the debt while still shipping features requires some planning
• Evolving teams. It is difficult to maintain cohesive knowledge in a team that has changed over time
• All of the above, likely compounded with process problems

These are some of the improvements that have been consistently observed after running a series of Bytesize Sessions with different teams. The teams

• Think about their systems
• Develop skills in systems modelling
• Learn how to model systems together, which improves team dynamics
• As more sessions happen, they increasingly have an consistent understanding of their system
• See the value of having a shared mental model
• Have better tools to model potential solutions
• Learn to actively listen

Bytesize Sessions are especially valuable for new members of the team or those with less experience. This is especially true in teams that don’t do pair programming or have deep silos. The Sessions “open up the ‘world’” It is hard to overstate how important it is to have an accurate mental model.

Before the session, prepare people

One of the main objectives of the Bytesize Sessions is for a team to have a homogeneous understanding of the system they work with. The right people to attend are all the people that have a high level of influence on that system.

Start with a group of people. Invite those that know about what needs to be done, those that build the system, and those that understand the stakeholder requirements best. If not sure, start with the people in the Stand Up. If there are more than ten people in the guest list, consider breaking the meeting into smaller groups. Bytesize Architecture Sessions work best with up to 10 people per session.

The recommended modelling tool when starting is C4. If the team is not experienced with it, train them on it before a Session. During a Bytesize Session the attendees should focus on modelling, not the modelling tool of choice.

Running a Bytesize Architecture Session

The key to a good session is ensuring everyone knows what they need to do, that they don’t feel lost. At the start of the session explain the overall format, then for each part delve into the specifics.

Goal

This section of the meeting should take about five minutes and it’s about having a Goal for this particular 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.

It’s good to have a suggestion of what to model before starting a session. However the final goal should be the result of team agreement.

Before moving on to the next section, check that every attendee understands the goal and how the rest of the Session will work.

Alone Together

This section should take ten minutes or less.

For the first part of this section set a timer for three to five minutes. During this time everyone works individually and quietly on the same modelling task. After the timer elapses, each person explains their own diagram to the rest of the group, while everyone else listens.

This modus operandi might be atypical, here are few reasons why it’s useful:

• The quiet time allows people to work and think individually, without other people’s voices. It strengthens their focus 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 twenty to thirty minutes. Set up a timer and be strict with it.

Consensus is about coming together to create one diagram from scratch with the combined knowledge of the team.

It’s normal for things to get a little hectic. Consensus doesn't mean avoid disagreement, it means the group working together to understand how things work, to work through the issues.

The work stops when the timer elapses, if the model is not finished, the continue the next session.

Summary

The last few minutes of the meeting.

Basically a mini-retro about what just happened. This part of the session is about reviewing what was achieved, what needs to be done next. Set a timer for one minute, have people write about what they learned and any other feedback in sticky notes.

Do it again!

Repetition is a great way to learn, it is ideal to do another session in a week or two. It shouldn’t be so often that it overwhelms people and it should be often enough to keep what was discussed on the top of people's minds.

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 create a Target Architecture or help enable inter-team communication for a complicated piece of work.