Agile Modeling Sessions: An Agile Core Practice

An Agile Modeling Session is a facilitated, collaborative, inclusive, and evolutionary approach to modeling or planning that is organized with just enough formality. This article works through the following topics:

What Are Agile Modeling Sessions?

An Agile Modeling Session is a facilitated, collaborative, inclusive, and evolutionary approach to modeling or planning that is organized with just enough formality. Let’s explore each of these aspects one at a time:

Facilitated. Agile Modeling sessions need to be organized, led, and followed up. These are the responsibilities of a facilitator. An effective facilitator should have a background in Agile Modeling (AM), have facilitation skills and may even be a professional facilitator, and should not have any stake in the outcome(s) of the session.
Collaborative. Collaboration is at the heart of agile, and in particular Agile Modeling. Everyone should be involved with the modeling effort, including both team members and other stakeholders.
Inclusive. Adopt simple tools, such as whiteboards and paper, and simple techniques, such as free-form sketches, that allow everyone to collaborate. The more difficult the tool, the more complex the modeling notation, the harder they are to learn and apply and the less inclusive they become.
Evolutionary. The “answer,” if you find one, will emerge over time through discussions, sketching, moving paper around, throwing paper away, erasing sketches, working on different views over time, working on different views in parallel, and many other AM strategies.
Sufficient formality. As always, the level of formality will vary with the context of the situation that you face. In general, less is more.

An important observation is that I’m describing Agile Modeling sessions in terms of behavior, not in terms of artifacts (such personas and stories for example), nor in terms of purpose (such as UX design or technical architecture identification), nor in terms of time (such as initial modeling at the beginning of an initiative). How artifacts, purpose, and timing apply to Agile Modeling sessions is explored below.

What Agile Modeling Sessions Aren’t

There are other types of modeling sessions that Agile Modeling Sessions are not:

Model storming sessions. A Model Storming is a short, impromptu modeling session. I don’t consider to be an “Agile Modeling” session because they generally aren’t planned nor are they facilitated.
Joint application design (JAD)/Joint application requirement (JAR) sessions. This is a formal modeling session popularized in the 1980s and early 1990s, although some organizations still perform them today. JAR/JAD can be a great technique in the right situation, but it is too formal to be considered an Agile Modeling session.

Why Should You Hold Agile Modeling Sessions?

The primary reason to hold an Agile Modeling Session is to develop a shared understanding or vision about something (see types of sessions in the next section). Agile Modeling Sessions tend to end with one of three results:

You develop a shared vision/understanding. When you’ve fulfilled the purpose of your session, whatever that happens to be, stop!
You recognize that you’ve made progress. Sometimes you will have scheduled a certain about of time for an Agile Modeling session, you’ll do great work during that period, but you realize as a group you still have more work to do to come to the shared vision/understanding you hope to reach. So you’ll decide to schedule more time to continue the Agile Modeling session.
You recognize that you won’t reach a shared vision right now (if ever). Sometimes it’s very clear that there is significant disagreement between stakeholders and that at the current time you’re not going to reach an agreement. That’s ok, it just means that now is not the time to continue with this effort. When the situation changes you may decide to revisit this effort.

An interesting implication of these ending criteria is that it can be hard to predict how long an Agile Modeling session will actually take. This is discussed later in the How Long Are Agile Modeling Sessions? section.

Types of Agile Modeling Sessions

There are several common types, or themes, of Agile Modeling Sessions:

Exploring stakeholder needs. The practice Requirements Envisioning is a type of session where you focus on intial requirements elicitation. This practice is common on the teams, product teams working on the first release of their offering, or teams pivoting in a significantly new direction.
Exploring potential architecture/design. The practice Architecture Envisioning is a type of session where you focus on identifying one or more potential solution strategies. This practice is common on any team where they find themselves in a situation where they need to think through how they will approach implementing a solution before actually doing so. This includes teams, product teams working on the first release of an offering, teams adding significantly new functionality to an existing solution, or teams working with new implementation technologies.
Planning an endeavour. Planning and modeling are effectively the same thing – you think something through before you do it. In fact, SAFe includes a practice “Big Room Planning” which is effectively an Agile Modeling session where they’ve constrained it for that framework. More on this later.
Combinations thereof. As I described in the practice Iterate To Another Artifact, people tend to move back and forth between problem exploration, solution exploration, planning, and the detailed aspects thereof. Sessions where you focus just on X, whatever X is, tend to either expand their scope very quickly or result in a lot of “parking lot” items to be looked into later.

When Should You Hold Agile Modeling Sessions?

You should run an Agile Modeling session when you need to work through an important issue with the people who have a stake in that issue. There are several common times when Agile Modeling Session are run:

Ideation.
Inception.
Pivot points.
Initial visioning.

Earlier I indicated that Agile Modeling sessions aren’t descibed in terms of timing. That’s because you should run one when you need to, and that will vary based on the situation that you face.

How Long Are Agile Modeling Sessions?

An Agile Modeling Session should be just long enough. This will vary based on the context of the situation that you face. The question you will want to ask is “have we invested sufficient time to gain the understanding or vision that we were hoping to reach and can now safely move forward?” The length of time an Agile Modeling session takes will depend on the level of agreement amongst stakeholders, the willingness of stakeholders to negotiate, the complexity of the effort being explored, the risk involved, and the quality of facilitation.

The implication is that Agile Modeling sessions may last for several hours or even several days. I become concerned when I hear about agile modeling sessions that go longer than a week, although I have seen some teams spread a 2-3 day session out over a week or two due to logistics challenges of getting stakeholders into the room.

It can be difficult to predict ahead of time how long a session will take. I’ve seen sessions that I thought we could do in 2 days stretch to 4, and rightfully so when we discovered that the problem we were exploring was more contentious that previously believed. Similarly I’ve seen sessions originally planned for 3 days to be wrapped up part way thorugh the second day. My point is that you need to be flexible. I get concerned when people talk about these sorts of efforts being a sprint/iteration because such things are usually defined timeboxes, with 1 or 2 weeks being the most common lengths.

The Rules of Conduct in an Agile Modeling Session

I have always found it valuable to set a few simple rules of conduct when I’m facilitating an agile modeling session. The following rules are a good starting point, but you should develop your own set that is appropriate for your grpup:

Everyone participates in modeling. Modeling is a team sport. We will gain a better understanding, come to a better resolution, if we’re all actively involved.
The facilitator is there to facilitate. Agile Modeling sessions are facilitated by one or more people. They should guide the group through modeling, help keep things moving along, find ways to help people have effective conversations, help the people to get back on track when things get heated, and suggest different ways to approach the problem. In other words, they facilitate the group but they shouldn’t be there to contribute to the models. When a facilitator becomes one of the modelers it destroys the dynamic of the session by putting them in a position of authority.
Everyone has value to add. We should respect the fact that they’ve been invited to the session because they can provide important insights and information. This is an important aspect of psychological safety that will help people be actively involved in the session.
Be respectful and kind. If we want people to add value and to be an active participant then we need to make it welcoming to them. This is another aspect of psychological safety.
Be present. Put down your phone. Close your laptop. Avoid external distractions as much as you can and focus on actively participating in the session.
Respect the schedule. Be on time. Don’t force others to wait for you. Just like you don’t like having to wait for others to return from breaks, or to initially arrive to the session, nor do they.
There are times when we will diverge.. The aim of divergence is to generate ideas. During this period every idea is valid and worthy of consideration.
There are times when we need to converge. During times of convergence we want to come to an agreement, to come to a common vision. We need to be prepared to negotiate so as to narrow down our options to the one(s) we believe to be most appropriate.
Yes AND, not Yes BUT. Let’s build on the ideas of others.

How Do You Plan an Agile Modeling Session?

There are several activities that we must perform, ideally as agilely as possible, to successfully plan an Agile Modeling Session:

Schedule a modeling room.
Schedule breakout rooms (optional). Sessions with large numbers of people. Converge and diverge stategy. Floaters between breakout sessions.
Identify a facilitator(s). For large sessions may need junior facilitators
Identify one or more note takers.
Identify the purpose.
Identify preparation requirements. Pre-reads,…
Identify roles.
Identify a schedule. Breaks, have buffer time
Schedule participants. Identify the length of time committment.
Share the rules..
Get materials. Stickies, whiteboard markers, permanent markers, flip charts, index cards, ….
Schedule food and beverages..

How Do You Facilitate an Agile Modeling Session?

Although the following list is something that professional facilitators do naturally, it’s always good to have a reminder:

Setup the room(s) beforehand.
Obtain agreement around the rules.
Obtain agreement around the purpose of the session.
Describe how the session will run. Schedule, break out rooms.
The facilitator(s) must lead by example. Respect the time, respect others.
Model agilely. See Supporting Practices below.
Have fun.
Determine whether you have, or have not, achieved the purpose of the session.
Determine how to follow up. See the next section.

How Do You Follow Up an Agile Modeling Session?

There are several things that are likely to be produced during an Agile Modeling session:

Models.
Action items.
Risk list.

Earlier I indicated that Agile Modeling sessions aren’t descibed in terms of artifacts. That’s because you should produce the artifacts that you need to produce, to the extent that you need to produce them, and in a manner that the audience for those artifacts require. These factors will vary based on the situation that you face. Hence the importance of the following supporting practices.

Supporting Practices

Several Agile Modeling practices are commonly applied during Agile Modeling Sessions:

Active stakeholder participation. Active Stakeholder Participation
Inclusive modeling. Inclusive Tools and Techniques
Just barely good enough (JBGE). Just Barely Good Enough(JBGE) artifacts
Multiple models. Multiple Models

Strategies Similar to Agile Modeling Sessions

There are several strategies that have been developed since Agile Modeling sessions were first developed in 2002. They are:

Big room planning. This is a practice in SAFe where the overall team, everyone in the program, gathers for several days to plan out the next release that they are going to work on. These sessions tend to focus on requirements, architecture, and planning in an evolutionary manner. Done right this is an Agile Modeling session.
Google design sprints. Google evolved a technique very similar to Agile Modeling sessions, and in fact I’d argue that they really are Agile Modeling sessions when they’re done right. Unfortunately my experience is that they’re often done wrong, often because they devolve into a UX design sprint rather than what Google actually advises. Google unfortunately choose a poor name for the technique, Design Sprints are not just about design (which is what confuses the UX people) and as I described above these sorts of sessions really aren’t a normal sprint (once again Scrum terminology messes people up).
UX design sprints. UX design sprints, when done “right,” typically lead to a great UX design. Unfortunately, because they tend to focus on UX and not on a more holistic view, the great UX design tends to be difficult/expensive to implement in practice. Worse yet, because stakeholders actively participate in these efforts (I hope), or at least because the results of the UX design sprint are eventually demoed to decision makers, the team often makes promises that they can’t actually keep. And I often see far too much effort invested in UX artifacts such as storyboards and UI specifications, which is a classic result of over specialization of skills. Far better to have a multi-disciplinary team and at least a few generalizing specialists to round things out. And, as mentioned above, it’s not really a sprint.
X mapping/modeling sessions. In this case, X is your modeling technique of choice and we’re using the term “mapping” instead of “modeling” because agilists just can’t admit that they model (but mapping is ok). Examples include user story modeling sessions, data modeling sessions, impact mapping sessions, and many other. These sessions can be valuable but run the risk of going in the wrong direction because they’re too narrowly focused. Limiting yourself to a one, or a small handful of techniques, is convenient at the time but runs a significant risk of going down a rabbit hole. Also, I should point out people have been doing focused modeling sessions like this long before Agile Modeling (although calling them mapping sessions came after AM).