Visual Collaboration Tools

Handbook for software engineering teams

João Rosa, Kenny Baas-Schwegler, Nick, Mathias Verraes, Stefan

Hofer, Henning Schwentner, Cédric Pontet, Trond Hjorteland, Pim,
Krisztina Hirth, Zsofia Herendi, Julius Gamanyi, Paul de Raaij,
Michael Plöd and Nancy Beers
This book is for sale at http://leanpub.com/visualcollaborationtools

This version was published on 2020-05-14

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

A word about teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Facilitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Campfires instead of meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Facilitator as magician . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Preparing a Visual Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Phase 1: Preparations for the session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Phase 2: Lighting the campfire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Phase 3 and 4: Visual collaboration towards the climax . . . . . . . . . . . . . . . . . . . . . . 11
Phase 5: Wrapping-up and extinguishing the campfire . . . . . . . . . . . . . . . . . . . . . . 12
Phase 6: Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Tips and trick for working remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Six Trumps: The Brain Science That Makes Training Stick . . . . . . . . . . . . . . . . . . . . 13

Visual Collaboration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Bounded Context Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Business Capability Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Context Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Decision Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Domain Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Domain Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
EventStorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Example Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Impact Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Interactions Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Mikado Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Quality Storming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
User Story Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
The Wall of Technical Debt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Wardley Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
CONTENTS

Field Stories for a tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

An Impact Mapping Workshop to Make Out The Right Decision Between Hundred
Possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Improving your Organizational Continuous Delivery capabilities with EventStorming . . 135
Gathering quality feedback at #play14 with EventStorming . . . . . . . . . . . . . . . . . . . 143

Combining tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Wall of Technical Debt and Mikado Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Introduction
By our nature, humans are visual creatures. Throughout times, we had created different ways to
communicate visually. We wrote in caves, and the Egyptians created hieroglyphs, then the alphabet
appears and more recently the icon fonts. These are examples where we excel in the creation of ways
to communicate visually.
Fast-forwarding to today, software engineering is commonplace in most of the organisations. Even
if the organisation is not on the software business, e.g., is not selling software, it is most likely that
they have a software engineering team(s) creating software for the internal processes.
The book is intended to create a shortlist of visual collaboration tools to aid software engineering
teams. It will describe the visual collaboration tool, the benefits and drawbacks. In the end, it will
explain different ways to combine the various visual collaboration tools to maximise the learning
process for the team.
Everyone involved in the software development process can benefit from this book. Software
developers, testers, architects, system administrators, product owners, managers, C-level executives,
they are all (in different capacities), involved in the software engineering process.
We got the idea for this book from the format of the liberating structure with our experience with
combining visual collaborative tools learned from the Domain-Driven Design community. We tried
different techniques in different contexts, and sometimes we failed, and other times we had success.
We are sharing what we learned; we firmly believe that we need to keep learning to deliver quality
software. That is why we, Kenny Baas-Schwegler and João Rosa, started our journey to find, explore
and curate these tools into this book. Find other people who could contribute and learn together as
a community!
The visual collaboration tools are ordered alphabetically. You can read the book from beginning
to end, or pick what is sound for you. We believe the field stories will provide light on how
the community use it. Context is the queen! If you have experience with any of these visual
collaboration tools, contact us. Your experience is valuable! Same applies for visual collaboration
tools or combinations that are not mentioned in this book.
Let’s collaborate!

• Kenny Baas-Schwegler & João Rosa

A word about teams
By Paul de Raaij
When you are talking about your team, who is it that you are talking about? Is it the scrum team
you are part of? Is it the group of colleague architects you work with once a week? Or is it another
composition of people?
Hopefully, you feel and are part of a team. A group of people you feel connected with. A collective
you work closely with and share interests or goals. Or in the worse case, you are part of a team
simply due to hierarchy. In any circumstance, you are part of a team.
However, we work and interact daily with people that are not part of that core team. For example,
when refining a user story you interact with a subject matter expert from the business. An architect
might help your team in drafting an architecture for your solution. Third-party systems require
integration and often close collaboration with the support team of a service provider.
As a consequence the dynamics between the people involved in the interaction change. It is not the
same as when you are collaborating with your core team. For the team members you know, you are
aware of their quirks and have come up with mechanisms to cope with those quirks, albeit good or
bad. Each time a different person interact with you and your team the psychological safety changes.
As a result, a member of the team might speak up less, put its ego on the front or not challenge
an assumption that is been put on the table. Important knowledge will not be brought up and the
outcome of the interaction will be sub-optimal.
The visual collaboration methods, as described in this book, can help tremendously to increase the
psychological safety for all participants in the interaction. It provides structures and opportunities
for everyone to speak up. In my experience, I have seen better outcomes of meetings that prevented
weeks of effort go to waste because everyone was able to put their knowledge to the surface without
being overthrown by whoever spoke the loudest.
Facilitation
There are debates in the community if a visual collaborative workshop needs a facilitator, and who
should do that. I believe anyone can facilitate a visual collaborative workshop and the best way to
start is to try, fail and learn. When we try and experiment, we must do it in a safe environment,
where failing is tolerated and to be expected. Doing it outside of that safety can have some dangers
when trying. If we don’t have approval from people with higher rank, don’t have their consent we
might be stretching our rank, especially when it fails. People who have a higher rank might not
understand why we need to change the way we work. We need someone with experience there to
manager that. Visual collaboration can also unearth social conflicts in groups and organisations. If
we don’t have the meta-skills of an excellent facilitator to deal with these, it can cause more harm.
That is why most of this chapter came straight out of the superb book Building Tribes by Jitske
Kramer and Danielle Braun. I think it gives us great insights and lessons from anthropology we can
use in visual collaborative modelling. Insights that help guide us in dealing with the social issues
that can arise during visual modelling.

Campfires instead of meetings

In the book, they explain that currently, meetings insides offices are usually being held partly online
through email, Snapchat, skype, zoom etc. However, real contact can only happen when people meet
in real life. Face to face, we can better interact and dump real stories, stories about courage, talking
about tension, sharing failure and sadness, and it is here where we can exchange the best ideas.
They don’t say we won’t be able to do these visual techniques remotly. However as Jitske and
Danielle wonderfully explain in their books, culture forms around these interactions. In these
interactions we are in contact, in real conversations with each other and have more meaningfull
dialogues. Yes we will have good outcomes through zoom, skype or any other digitale meetings.
However it is much more effective to do these in conversation where peoples have the fullest
attention for each other. That is why they call out that we never ever do a ‘meeting’ anymore,
but to organise campfires with real contact. Sometimes litterly, sometimes figurativly speaking. A
campfires is sometimes where we have real conversation, with the fullest attention for each other,
and to discuss agendapoints and the goal of the get together.

Facilitator as magician
A campfire always needs someone to light the campfires. In practice, everyone can do this. Jitske and
Danielle make the comparison with magicians, a tribal role they describe in their book. Magicians
are the people a tribe needs, that has unique skills and tool, hold a lot of information and are the
Facilitation 4

one people will look at when they need a miracle. However, they always need recognition from the
people in power, the chiefs. If not they will end up on the stakes like warlock and witches did in the
passed. Nowadays that usually means getting fired or banned from that group.
We find these magicians usually in the role of a consultant, coaches, trainers, people who have a
free role, or work at HR. They are the people that bring other people together to make magic. Jitske
and Danielle describe in their book these six fundamental factors if someone is the facilitator for
starting campfires:

• Techniques and skills

• Posture, metaskills and charisma?
• Holding space: don’t be afraid of chaos and conflicts
• Attention area of the magician
• Ranking and place in the group
• Magician or witch

In the following paragraph, I will explain what this means for facilitating a visual collaborative
modelling session.

Techniques and skills

Everyone can learn techniques and skills to facilitate; it is one of the reasons João and I wanted
to curate this book. This book will teach you by reading how to use several techniques and tools
for visual collaboration. We hope you get the information you need from reading this book so that
you can start lightning campfires yourself. Because through failing, we will learn and acquire new
insights and become better and more successful.
Another way to get new insights and learn is by having conflicts. As with the paradox of failure and
success, to create peace, we need to make conflicts. People tend to avoid failure and conflict, which
is a real shame because we can learn so much from both and grow as humans. Since humans try to
avoid conflict, it is the job of the facilitator to guide the group towards and into these conflicts.
Whenever tensions and stakes gets too high people will show what Myrna Lewis in her Deep
Democracy the lewis method calls edging behaviour. Like a cat that starts licking itself during a
staredown with another cat. Humans also show edging behaviour; grabbing their phone, doodling,
turn mute, looking at their phone, let the same conversation cycle. Everyone knows that feeling
when a conversation keeps cycling back over and over again. That is edging behaviour of the whole
group.
Whenever people or a group shows edging behaviour or a conversation starts to cycle, we are missing
insights as a group. Not only are we missing insights, but we also won’t get the full collective buy-in
from the group. People will feel left out or unheard, which in turn resolves into tension and unspoken
frustration. People start to resist, first openly with jokes, but finally stopping conversation or not
participating anymore. In Deep Democracy, we call this the resistance line.
Facilitation 5

The resistance line

In these tensions, perceptions and implicit insights is where the real innovations lie. So it is the job
of the facilitator to gently guide the group or team in these tensions to discuss them, Myrna Lewis
calls this kissing them over the edge. A good facilitator can do this by stating what is happening at
precisely the right moment. Too early and the group didn’t feel it yet and will dismiss it, too late
and the group already mentally checked out unable to return them. In deep Democracy, we call this
giving out a weather report. Tell what you observe, state the fact and wait for the group to solve
the problem themselves, or if it is too much of a hotspot the facilitator need to guide them into the
debate or conflict. See Deep Democracy the lewis method for exactly how to do that!

Posture, metaskills and charimsa

Everyone can learn techniques and skills given enough time and experience; for one, it will come
more natural than to others. However, posture, meta-skills and charisma are much harder to learn.
It requires a lot of self-reflection and inner work. And sometimes it is not even possible to facilitate,
because of our background people won’t feel safe to share their knowledge. As a facilitator, we are
the people that make sure the conversation flows so that the group can say what needs to be said.
A facilitator cannot have stakes, need to stay neutral, protect the group, be a leader and push and
pull the energy of the group. A facilitator needs to be ready for the unexpected, for conflicts, for
polarisations to pop-up and manage, to get all the wisdom from the group to get the most effective
outcome and that the whole group can go along with, without resistance.
There are many meta-skills one can learn, but in my opinion, the three meta-skills Myrna Lewis
described in her Deep Democracy method are the most important; Neutrality, super listening and
compassion. Neutrality to really accept and be open for all different insights, without judgement,
regardless of who it is, or who is not there in the group. Neutrality is standing for everyone in the
group and no one. Super listening to not only hear but also observe, feel the energy of the group by
being fully conscious. Compassion in finding ourselves in others, genuinely accept their opinions
without judgement, how wrong we might find them.
Facilitation 6

Holding space: don’t be afraid of chaos and conflicts

Conflicts, like failures, are moments we can learn and understand each other. If we always agree
with each other, we will never progress or have new ideas. Visual collaboration is the best moment
to get everyone there current mental models out to discuss these. You can imagine that it can cause
debate or conflict to arise. As a facilitator, we must create and hold the space so that the group can
work in that energy, safely exchange ideas, or dive into the conflict so that people can learn. Make
sure that when we start, we create the space that is needed, and slow down and give silence to hold
that space when conflict arises.

Ranking and place in the group

Even though we mastered all the skills, have years of experience with facilitation, it can happen we
are not the right person to lead a visual collaboration. The ranking is essential to be aware of, even to
the group. Ranking can make or break our sessions, and it isn’t only hierarchical, it is social as well.
As the CEO or a close relation toward that CEO, people might not trust us, that is a hierarchy. As a
tall white man, people may fear you, and as a person with a diverse background who is small, people
might not accept you, these are social. I once facilitated a session with a colleague and my wife. My
colleague and I are both tall white man, so the group accepted us as a high enough social rank to
lead. However, people did not feel safe to share everything with us. People didn’t feel threatened by
my wife, being from a diverse background. They opened up to her, gave her information that was
essential to the group process. We together made a difference that each one of us alone could not.
Be aware of that ranking, of our social powers.

Getting burned at the stakes

Although visual collaboration can be significant, as mentioned earlier if it does not deliver, we might
get burned at the stakes, especially as a facilitator. Even though we think the session ended good,
did we have buy-in from everyone? Didn’t we overstep our boundaries given to us by the people in
power? Do people want to connect? If we are not careful, the group or the people in power might
turn against us. We call this getting burned at the stakes. Getting fired, being bullied, or we lost our
changes and people will never ask us back again.

Authors, attribution and citations

Book: Building Tribes - Reisgids voor organisaties; Jitske Kramer, Danielle Braun; 2018
Book: Sitting in the Fire: Large Group Transformation Using Conflict and Diversity; Arnold Mindell;
2014
Deep Democracy the Lewis Method¹
Kenny Baas-Schwegler(@kenny_baas²) - Author of the article
¹https://deep-democracy.net/
²https://twitter.com/kenny_baas
Preparing a Visual Meeting
Holding a visual collaboration session with impact, I use the six phases Jitske and Danielle describe
in their book Building Tribes.

• Preparations for the session

• Starting the session, or as Jitske and Danielle call it ‘lighting the campfire’,
• Visual Collaborating - the session itself
• The climax
• Wrapping-up and extinguishing the campfire
• Retrospective

Each of the visual collaboration techniques you will read about in the book, we can use these six
phases. We will only get the full benefit of these sessions if we cater to all the needs in these six
phases. It is about the attention and the intensity, not the amount of time. Visual collaboration will
only work when people want to collaborate and listen to each other. Else we might as well skip it
and don’t waste our time. The phases might also look different depending on the tool used; you can
read more about it in the tool explanation.

Phase 1: Preparations for the session

As we all know, or should know, preparation is vital for an impactful visual collaboration session.
We need to know with whom will we prepare it, or can we do it alone? What is the goal of the
session and which visual collaboration tool shall we use, or do we need to combine them? Given
the tool, what room setup do we need? How many wall space, what equipment? Who do we invite,
which perspectives do we need? Who will facilitate, who will scribe? We need to account for all
these questions in the preparation of a visual collaboration session.

Who to invite?
The most asked question is “Who do we invite in these sessions?”. Better is it to ask ourselves which
different perspectives we will invite? Effective visual collaboration is all about getting a group of
people together with diverse perspectives. Will we be talking about the customer, then we at least
need someone who understands there need. Will it impact our colleagues who use our software,
perhaps invite them. Are we changing the way we interact with other teams, bring them along! Can
we plan our work independent from other teams in the department, if not then perhaps we need to
make the group together with that department? Good visual collaboration requires a diverse group
of people with different perspectives, think about the following people:
Preparing a Visual Meeting 8

• Kinship: Team members, project groups, guilds, people of other teams in our department.
• Leaders: Managers, Key figures, dungeon masters
• Perspectives: Which perspectives cannot be missed. Who are we impacting? The classic
mistake is thinking internally instead of externally like the customer. If we cannot invite these
perspectives, how can we represent their view? For instance, invite UX designers or customer
researchers to be the voice of the customers.
• Competence, skills, knowledge: Do we need specific expertise like someone from security or a
data-researcher
• New perspectives: Do we have enough ‘weird’ people in the room. People that annoy us, people
that are in our allergies zone, new people. People who are not in our ‘normal’ zone are most
likely to give us the insight we need. That also accounts for our competition. We always require
new insights.

If you’re always trying to be normal, you will never know how amazing you can be.

• Maya Angelou

Who will facilitate and how?

A facilitator is not one person or a specific job. Anyone can be the magician to light the campfire, to
make the conversation flow. Inside the team, someone from another team within the organisation or
an external person. Sometimes a team member tried to facilitate, but it did not work, but as soon as
that external consultant got hired it all worked out. Outside perspective sometimes gets more valued.
However, let’s not call in an external facilitator for every visual collaboration we do. There are a
lot of magicians out there within the organisations, from agile coaches to architect or the engineers
within the teams. Just be mindful of the ranking at play, and how neutral that person can be and
needs to be. Finding the right person for the job is essential!
Depending on the size of the group and the visual tool we want to use to support our session, we also
might need more facilitators. Always have the main facilitator, we cannot have two captains on a
ship! Decide who leads and who co-facilitates. The co-facilitator can make or break the session.
It is the person who will be less of an active participant and more of a passive participant. I
take my learnings from the method participant observation used by qualitative researchers like an
anthropologist. The method describes several types of observations:

• Non-Participatory: No contact with population or field of study

• Passive Participation: Researcher is only in the bystander role
• Moderate Participation: Researcher maintains a balance between “insider” and “outsider” roles
• Active Participation: Researcher becomes a member of the group by fully embracing skills and
customs for the sake of complete comprehension
• Complete Participation: Researcher is completely integrated in population of study beforehand
(i.e. they are already a member of particular population studied).
Preparing a Visual Meeting 9

As the facilitator, it is good to be an active participant. However, if we are alone, we might want to
sometimes step out towards moderate or even passive participation. If we are with two facilitators,
the facilitator can stay active while the co-facilitator can stick mostly in passive participation. If we
are active, we are more preoccupied to really feel the energy of the group, to super-listen what is
happening in the group. And we might miss a lot of social cue’s. Having that passive participant in
the back can tremendously help spot hot-spots and edging behaviour in the group that will help the
group progress if discussed.

The required setting

The right space is essential. Nothing can kill an intense visual collaboration of a day without having
fresh air, enough breaks with food, daylight or enough space. Visual collaboration is also a creative
process; besides the need for the practical, the proper surrounding can also really help spark that
creativity. Have you ever have a disco party without suitable lights? We can still dance, but having
disco lights present with a smoke machine helps the party get started. Don’t even get me started
about a light floor that will make the party a hit! A lot of organisations cater for the practical, but
never stand still how good surroundings also affect our meetings like it does with parties.

Phase 2: Lighting the campfire

Then the time has finally come, and the session will start! People will join the session and are still
pre-occupied with previous sessions, conversations, maybe they are still tired, or something is up
in their personal life that makes not present at the session. It is essential for the facilitator now to
welcome the people in, show the correct energy so that people can make the transfer from before
the session, towards the session. The facilitator needs to create ‘space’ now for the group of people
who now want to make a difference by using virtual collaboration. It is the first time that the group
makes contact with each other. Without that personal contact, no tooling will help here.

Check-in
With the check-in, we make sure the individuals that got together can become a group by allowing
everyone to become present in the session. The check-in is a conversation model from the lewis
method of Deep Democracy. Sometimes a check-in can be 5 minutes, sometimes it might take a day,
and that is fine. I always advise to do one, and I don’t do one without! The basics of a check-in are
a few questions that are relevant for the meeting. For example, what do we want as outcomes for
the meeting, what are the challenges you think we might face, what are our hopes for the meeting?
Remember, the more specific we make it for the session, the better the session goes.
The check-in starts when the facilitator introduces the concept of the check-in and the rules:

• It is is no dialogue, we don’t have a conversation or debate. We share and dump and hear where
everyone is.
Preparing a Visual Meeting 10

• We do it popcorn style, so not pointing out people to talk, not making around. People do the
check-in when they feel like doing it; ‘pop when you are hot. Don’t wait too long cause you’ll
get burn’.
• Everyone does a check-in

After we explained the rules, the facilitator asks the questions and then leads by example by
answering them, setting the tone for others to join in. It is crucial to speak from the hearth, show
vulnerability when needed. Don’t make it a rational check-in. The co-facilitator check-ins when the
person feels the group needs a nudge to move on. When everyone checked-in the facilitator wraps-
up by making a summary of what has been told. It is the most challenging part, and we want to
discuss what is said, not who why and what a specific person said. It is crucial people felt heard and
recognised themself in the summary.
We end the check-in by asking people if now they want to react to what has been said. Doing that
might instantly trigger a conversation. When that happens, and people already start the collaboration
do not forget to visual complexity straight away when needed!

Outcomes, Agenda, Roles and Rules

In his book Visual Meetings David Sibbet explains that they found out there are four things that are
most productive to get clear; The Outcomes, Agenda, Roles and Rules, in short OARR. Making these
four things visual and clear at the start of our meetup makes us look prepared. It also helps clarify
to people why they are here, who they will be working with, what they will be doing and who does
what. According to the team performance model by Drexler/Sibbet based on the work that Arthur
Young describes in his Theory of Process. There are four flows of activity in a meeting:

• The flow of Attention

• The flow of Energy
• The flow of Information
• The flow of Operation

Once we managed the flow Young argues that all processes move from having no constraint in the
beginning, when they are merely potential and a sense of purpose, to having lots of constraint at the
point we are assigning a budget or allocate real people to a project. Once we cross that line, we get
to the enactment of implementation and high performance. By using such a simple template as the
one above we can start managing the flow. Combined with a powerful check-in and, we will have
all the ingredients for a successful visual collaboration!
Preparing a Visual Meeting 11

Team performance model Drexler/sibbet

Phase 3 and 4: Visual collaboration towards the climax

Each Visual collaboration will be different from the other. It has its own build-up, energy and
focus. In the tools sections and the field story, you can read up about these tools and how to
use them effectively. Combined with the facilitation and preparation described in these chapters,
you are bound to have real conversations with people. Groups form around interaction, and the
visualisation is supporting those interactions. Ruth Malan has been talking a lot about Visualisation
in Software Architecture. She says “Conversations are so important, but conversations with visual
models (diagrams of facets of the system) help see what we mean — helps break ground and
create common ground”. She then goes on saying “Create visuals together in a conversation is
an important point, but there’s also more than “speaking for” (or writing about) that is in play.
Sketching, diagramming, modeling, together is a way to bring more minds to bear, to explore/probe
the design context and options/possibilities.”

“Coupled, their interplay and overlap, facilitate the emergence of new perspectives.
Actively interweaving multiple strands of thought Creates common ground.”
— Nick Sousanis (@Nsousanis), Unflattening, pg 37

As I hope you understand by now, we form groups around interaction, but it is essential to visualise
these interactions to become more effective at what we do. At each visual collaboration session, we
Preparing a Visual Meeting 12

do just that, and we work towards a climax. Every visual collaboration session works towards action
at the end. A symbolic act or decision, depending on the outcomes of the session.

Phase 5: Wrapping-up and extinguishing the campfire

At some point, the time is up, or the outcome has been reached, and it is time to extinguishing the
campfire. Just as we started the session with a ‘rite de passage’ with a check-in, we now need to do
the same with a check-out. It is time to wrap up and say goodbye to the group and, to the interactions
we had and have a few last words. We can do it by asking a few questions; what are your thoughts
after the session? What hit home to you during the interaction? Or ask for any feedback about
the session and how people would have seen the meeting different. We will use the same style as
the check-in, sharing and dumping in popcorn style. It is vital to create that space where people
can express their lingering emotions and that it is okay to express them without any rejection. Be
prepared that a group can start another discussion. Wrap it up for a next meeting. Is it not possible
then start the session all over again with a check in!

Phase 6: Retrospective
Everyone is gone, now it is time to clean up and document the outcomes. It is also time to already
reflect, share feeling and first insights of the session. What went well, what could have gone better
and how are we feeling about the way we facilitated. Here it is important to discuss how the
interaction went in the group. How was everyone participating, is everything said that needed to
be said. Did we lack certain perceptions in the group, or did certain perceptions not emerge? Do we
need to speak with certain individuals after the session. Everyone is different and there is a specific
group of people that need to let all the information and cues sink before able to have insights that
are vital for the group. Do we need to plan another session, and what are we going to do different.
Make agreements on follow-ups to make the next session even better!

Authors, attribution and citations

Book: Building Tribes - Reisgids voor organisaties; Jitske Kramer, Danielle Braun; 2018
Book: Visual meetings - How Graphics, Sticky Notes and Idea Mapping Can Transform Group
Productivity; David Sibbet, 2010
Deep Democracy the Lewis Method³
grovetools-inc visual planning templates⁴
Ruth Malan(@ruthmalan⁵) - Source of knowledge and wisdom in visualisation for over 15 years.
Kenny Baas-Schwegler(@kenny_baas⁶) - Author of the article
³https://deep-democracy.net/
⁴https://grovetools-inc.com/collections/visual-planning-templates
⁵https://twitter.com/ruthmalan
⁶https://twitter.com/kenny_baas
Tips and trick for working remote
Giving the situation we are in, which is the COVID-19 outbreak, most of us need to reinvent how to
do visual collaboration remotely. There is still a lot to discover; however the basic setup described
in the previous chapter doesn’t change. It is even more vital to focus on the interaction of the group
doing these sessions remotely. A good check-in makes the difference here. However, tools are more
crucial to use, and preparation of these tools are much more critical. We usually have a bag of tricks
with stickies and a wall, but now we need to make sure we have a stable internet connection, good
camera’s we can turn on and of course a good virtual whiteboard to work with.
The only problem is, all these tools are usually for the privileged. We want to see what works and
can work with our team or group. If some don’t have a stable internet connection, we need to make
sure they are still included. Preparation is getting so much more important—also, empathy towards
people in specific contexts. What can we do to make the session better online, which is not only
bounded by tools, but tools can be the restriction. We are still learning in this area.

Six Trumps: The Brain Science That Makes Training

Stick
It is still too early to know what works well, but my key heuristic in giving session is to blend in the
Six trumps described by Sharon Bowman:

1. Movement trumps sitting.

2. Talking trumps listening.
3. Images trump words.
4. Writing trumps reading.
5. Shorter trumps longer.
6. Different trumps same.

As we continue to work on the book, I will add more and more of my heuristics on how to deal with
online visual collaboration. The first ones that I now use successfully are:

• Shorter trumps longer & Movement trumps sitting. -> Every 20 minutes you want to take a
break and let the participants move for at least 3 minutes
• Shorter trumps longer -> Split the session up in sections of two to three hours. Making the first
one possible longer for a good long check-in.
• Different trumps same & Talking trumps listening -> Switch the person who drives and changes
the stickies on the board every five minutes.
Tips and trick for working remote 14

Authors, attribution and citations

(Six Trumps: The Brain Science That Makes Training Stick)[https://bowperson.com/wp-content/uploads/2014/11/Six
Kenny Baas-Schwegler(@kenny_baas⁷) - Author of the article
⁷https://twitter.com/kenny_baas
Visual Collaboration Tools
Bounded Context Canvas

What is made possible

The Bounded Context Canvas is a design-aid for designing Bounded Contexts. Bounded Contexts are
sub-systems within a larger system, aligned with specific areas of the problem domain the system
represents. In software development, Bounded Contexts can be implemented as microservices or
modules in a monolith.
Using the Bounded Context Canvas forces us to consider the key elements of the design of an
individual Bounded Context. Ensuring that key design information is captured allows us to challenge
the design of our Bounded Contexts more deeply and consider alternative designs.
Bounded Context Canvases can also be stored as artefacts. They serve as a reminder of the key
characteristics of Bounded Contexts for existing team members, new hires, and people working in
other teams. It can also be shared with domain experts, allowing them to provide input into the
design and ensure the software system is aligned with the domain.

Bounded Context Canvas

Visual Collaboration Tools 16

How to use it
For each of your Bounded Contexts:
1. Draw the canvas on a large sheet of paper, flipchart, whiteboard, or digital tool like Miro.
2. Starting at the top left and working down the left column and then down the right-column.
3. If you don’t have the information required to fill in a section, it’s time to break out another
modelling activity like EventStorming to find the missing information.

Preparing the workshop

There are generally two types of workshop you can apply the Bounded Context Canvas to:
1. Assessing the design of an existing system
2. Designing or re-designing a system
For an existing system, you should arrive at the workshop with a visualisation of the existing system.
A context map, a bullet list, or some other type of visualisation of the sub-systems in your software
architecture.
For a new system, first create an EventStorm of the system and then create an initial collection of
potential models, ideally as draft context maps.
For either type of workshop, split participants into small groups of up to 4. Ask them to identify the
most important or most interesting context and create a canvas for it. Then repeat for other contexts
in the system.
You may not have time to create a canvas for every context, so as a rule of thumb, allow 30 minutes
for the first canvas, and 20 minutes for each subsequent canvas. Encourage teams to make a note of
“hotspots” - parts of the design they think need further discussion. And then use dot-voting later to
review the most important hotspots.
Ultimately, there will always be a choice to make between breadth of design vs depth. Decide up-
front based on your goals, but be reactive to what you learn during the workshop. If possible, plan
your time to create a canvas for each context, and then have a second iteration to go deeper and
explore alternative designs.

The workshop

Why?

The workshop can be used to assess the design of an existing system, design a new system, or as
a training exercise to teach attendees how to design better Bounded Contexts. These are all useful
activities because they improve the design of a system by:
1. Producing more modelling options, increasing the chances of creating a better design
Visual Collaboration Tools 17

2. Identifying problems at the design stage where they are easier to fix
3. Allowing a team to collaboratively design Bounded Contexts and combine the whole team’s
knowledge
4. Enabling domain experts to guide architectural decisions through deeper, and more structured
conversation about the design in business-relevant terminology

Purposes

Tips and Traps

• The description section isn’t just filler; it serves a real purpose. It’s extremely common for
people to struggle to articulate the purpose of a Bounded Context and its main responsibilities
or to realise while explaining that it has too many or misplaced responsibilities. It’s also very
common for people to disagree on the purpose of a Bounded Context. Writing down the
description forces people to fully evaluate their fuzzy thoughts and feelings.
• Almost every word on the Bounded Context Canvas should be domain language from your
Ubiquitous Language. Ask your domain experts if there is anything on the canvas that they
don’t understand.
• Use the “Messages Consumed and Produced” section of the canvas to explore alternative
models. Ask lots of “what if?” questions?
- What if we moved this responsibility into another Bounded Context?
- What if we break out these two responsibilities into a separate context?
- What if we take these two responsibilities from this context, and those two responsibilities
from the other context and merge them into a totally new context?
• Dependencies between Bounded Contexts represent greater friction to change, both technical
and social. So be especially diligent in looking for ways to remove dependencies. For each
dependency, ask “what would it take to remove this dependency?”. Then evaluate the pros,
cons, and fixes.
• Remember that the Bounded Context Canvas is not exhaustive. There are other aspects of
Bounded Contexts that need careful design: the technical architecture, and the organisation of
the teams. These are great topics to explore after you have used the Bounded Context Canvas
to create a solid starting point.
• When creating the first canvas, allow for at least 30 minutes and take your time to consciously
discuss and complete each section. If teams rush the first canvas, they will rush all of them
and miss out on the key benefit which is uncovering more details, discussing trade-offs and
exploring alternative models.
• Use post-it notes so that it’s easy to change your mind and explore alternatives.

Authors, attribution and citations

Nick Tune invented the Bounded Context Canvas. Over the course of a few years consulting and
running DDD workshops, he built up a set of implicit heuristics for designing Bounded Contexts.
Visual Collaboration Tools 18

One day he converted them into a convenient checklist. Over time the checklist evolved a little
bit and eventually it was trialled in canvas format. People found the canvas format easier to use,
especially for collaborative purposes and so the canvas format has prevailed.
Nick has been using the Business Model Canvas since 2012 which was a definite influence in his
decision to create the Bounded Context Canvas.
Visual Collaboration Tools 19

Business Capability Modelling

What is made possible

A business capability is a particular ability or capacity that a business may possess or
exchange to achieve a specific purpose or outcome.
-Ulrich Homann, A Business-Oriented Foundation for Service Orientation⁸, Microsoft
Developer Network 2006

Business capability models are frequently used in enterprise architecture as a way to describe a
company in a holistic way, representing the organisation’s business model independent of the
structure, processes, people, or resources like IT systems, buildings, materials, hardware, tools, know-
how etc. Everything is included, every nut and bolt; nothing belongs outside of the model, and its
premise is an outside-in perspective of the company as it strictly describes what the company is
capable of – its abilities.
Business capability modelling is related to the resource-based view⁹ of the firm and often regarded
as an extension to it as it also supports other value configurations¹⁰ in addition to classical value
chains, like value networks¹¹ and value shops¹². This type of modelling may sound academic and
something that only the business and enterprise architects care about, but it is quite tangible and
widely applicable. Simply put, the capabilities are what the business regard itself to be capable of,
what its competence is, both for internal and external parties. What makes the concept a bit hard
to grasp is that they inherently describe what the company does, not how. It is an abstraction of
the business reality that sets them apart from classical business process modelling, which usually
focuses on how things are done. This abstractness also makes the capabilities inherently more stable
than other approaches as they do not change when their implementation does, like automation using
the software. The only reason for them changing is company strategy adjustments, such as deciding
to pivot, extend, or moving out of some business area.
This strict and abstract business view give its enabling components, be it roles (people), processes,
information, and resources an explicit business context. An interesting aspect of this vantage point
is that the capabilities need to be fairly self-contained, meaning it must be able to deliver on that
capability in relativity independent manner. Furthermore, the capabilities are naturally hierarchical
and decomposable, meaning that one top-level capability, e.g. Sales, will contain a number of
capabilities which again will contain another set. The number of levels differs based on the size
and complexity of the enterprise, but 3-4 levels are common.
⁸https://cdn.ymaws.com/www.businessarchitectureguild.org/resource/resmgr/homann_article_on_capabiliti.pdf
⁹https://en.wikipedia.org/wiki/Resource-based_view
¹⁰https://cio-wiki.org/wiki/Value_Configuration
¹¹https://en.wikipedia.org/wiki/Value_network
¹²https://en.wikipedia.org/wiki/Value_shop
Visual Collaboration Tools 20

Example from an internet service provider.

Although it may seem that business capabilities are something that only business and enterprise
architects care about, they can be used to a lot more than strategic planning and documentation,
some of which may even be relevant for developers and software architects. Especially their inherent
independence and logical boundary fits well with the SOA/microservices principles of autonomy and
explicit boundaries, as well as the concepts of bounded contexts from domain-driven design. Even
without having a defined business capability model at hand, the concept can be used to identify those
services as a heuristic. Can you match the suggested boundary to something that can be characterised
as a business capability, you may be onto a good autonomous service.

How to use it

Preparing the workshop

Before inviting people to participate in a workshop, it is always important to be explicit about the
expectations. Whether the goal is to define a big picture map of the whole enterprise or if it is
detailing the lower-level capabilities defines who needs to be involved. For the top-level mapping
senior business leaders, enterprise architects, and business architects from across the enterprise are
needed, while for the detailing of specific capabilities people with deep knowledge of that part is
required, like product managers, system matter experts, and software architects. Although it can
seem sensible to try to create a full capability map, going all the way from the top to the lower levels
of the hierarchy, the effort will most likely overshadow the benefits. Therefore adjust the initiative
to the specific goal at hand, be it creating a top-level model to be used for business modelling or to
modularise a software monolith belonging to one of those top-level capabilities.
Another decision that should at least be considered upfront is whether to go for a mostly top-
down or a bottom-up approach. In the former, the top levels are identified first, detailing the
other levels in succession, while the latter starts with gathering as many capabilities from any
level and then mapping them in hierarchy afterwards. Often a combination of the two works well,
Visual Collaboration Tools 21

but an enterprise-wide business capability model can be hard to reconcile without some top-down
perspective and involvement.
Regardless of the approach chosen, the goal is to capture and document the capabilities that represent
what the business does now and what it desires for the future. In most companies, some sort of
business model and business architecture already exists and should be brought to the workshop as
input, be it value chain analysis, business processes, and business plans. Even existing org charts
can be interesting for inspiration, as well as a list of core business entities. For some industries there
even exist publicly available reference models that can be beneficial to take a look at.

The workshop

As this is a highly collaborative workshop where all participates must be able to engage well and
have full attention to the task at hand, any storming type technique can be used. One example could
be to get everybody to write down all capabilities they can think of on a sticky note and share them
with the group when ready. This works especially well for the bottom-up approach. It is also fine
for top-down, but then care should be taken to make sure one layer is in focus at the time.
Remember to cover the entire enterprise, both internal and external capabilities; some capabilities
may be delivered by strategic partners and collaborators – sourcing must be included as it is part
of running the enterprise. The number of capabilities for each level varies a lot from business to
business, as well as the level of detail one wants on the lower levels, but on the top level, 7-10
capabilities are common.

Example of a simple capability map.

Visual Collaboration Tools 22

The initial iterations should probably focus on identifying the capabilities and giving them good
names (nouns or, even better, verb-nouns). A good way of documenting the full set of identified
capabilities is to draw a graph similar to the one shown above or a set of nested boxes as lower-level
capabilities are framed by their parents. The hierarchy is strict, where one contains the other, but
there is no hard rule to what belongs to which level. Some heuristics may apply though, e.g. that the
top-level is foundational in nature and can be found in many industries, such as develop products,
manage the business, and partner collaboration, while the second level often is a grouping of the
more concrete level three capabilities, like sales planning, purchasing, and customer analytics.

Example of documenting a capability map.

There are a number of tools available for this, like Archimate, LeanIX, and Ardoq, but simply create
it in your favourite drawing tool like Visio, Gliffy, and PowerPoint works fine too. You can also
include the components, i.e. people, data, processes, and tools, in here as well, but in large sets that
gets a messy quickly and will often require more details than just names. Therefore, additional
documentation for each capability is often needed, like this example of a lover level capability
illustrates:

Example of documenting a capability.

Visual Collaboration Tools 23

Keep the description brief and concise, e.g. using a template like “The ability to…so that…”, and take
care of describing it in business terms with a business outcome. Consider also documenting any
dependencies to other capabilities, e.g. messages reacted to or published.
Iterate on the model until a consensus is reached, which will take several sessions and different
peoples involved. But do not fall into the trap of making the model for its own sake – models should
be useful, not complete.

Why?
What makes business capabilities so versatile is their descriptive nature, that they define the problem
space well and says nothing about the solution space. They are a good foundation for a lot of more
detailed modelling, being stable from the business perspective and only change when the business
itself changes.

Purposes

Examples of usages follows:

• An outside-in and holistic perspective of the business, used for:

– Document the business.
– Business consulting and common business language.
– Strategic planning, finding which capabilities are the differentiators and what are sup-
porting. Can be combined with a Wardley map to see how they can evolve over time.
– Business analysis, like heat mapping for maturity, effectiveness, performance, duplication-
s/overlap in mergers, and more.
• Technical modelling:
– Data management/system of record as information is related to specific capabilities.
– Service modelling, i.e. defining the boundaries for the services in SOA/microservices.
• A way of structuring your organisation, the teams and departments, connecting them to
specific business outcomes as defined by the capability.
• Planning your product roadmap, e.g. focusing on the strategic capabilities.

Tips and Traps

• Try to cultivate the outside-in perspective, focusing on the what and not the how. It is very
easy to get lured into the processes used to deliver the capability, but focus on the problem, not
the solution.
• Do not use the org chart as a template, only as inspiration at best. For old companies where
parts of the organisation have been stable for a long time can be indicative of a capability. The
organisation is about how to deliver the capability, not necessarily what it is.
Visual Collaboration Tools 24

• Do not use existing IT systems for inspiration either, which may be supporting several
capabilities.
• A common anti-pattern in service design is basing them on business entities/objects, like
product, customer, order, and account, and it is just as problematic as a source for capabilities.
Their life-cycle can be of interest though, since the capabilities often work with them at
different times, and those transitions can be indicative of crossing boundaries.
• Take inspiration from existing business processes, especially those that are long-lived such as
customer journeys. They have steps that may match well with capabilities. Be careful with
short-lived ones though, such as sales and order processes, as they probably belong to specific
capabilities.
• Identify and have a focus on the beneficiaries of the outcome of the capabilities, be it customers,
partners or other internal functions. As always, keep the user in mind.
• There is a lot to naming things, so also for capabilities. As they are focused on the what and
they are about the ability to do something, try to enforce the naming convention of verb-noun
and avoid using generic terms like “management” which does not say much. For example, use
“Sell Services” instead of “Sales” or “Generate Invoice” instead of “Billing”. Make the implicit
explicit.
• View every capability as independent, meaning that it can deliver most of its outcome with
no hard dependencies to other. It can of course react to changes elsewhere, but should not be
blocked.
• View a capability as a black-box, with its own people, data, processes, and resources. A nice
heuristic is that it should be “outsourceable”, maintained by a team far away.
• Capabilities are unique and should not overlap, meaning that the role and outcome should not
be found elsewhere. This is why the focus on what is so important and not how which may
very well be duplicated.
• It may be advantageous sometimes when starting from scratch for somebody to build a straw
model before inviting busy people to contribute to it in the workshop. Utilise Cunningham’s
Law¹³.
• When using the capabilities as inspiration for service design, be aware of other concerns like
shared data, transactional boundaries, the number of interactions, tight runtime coupling, and
work processes might be just as critical, especially in the lower levels.

See also Defining the Business Capability - A Cheat Sheet¹⁴ for more good tips.

Authors, attribution and citations

• Enterprise Architecture as Strategic Differentiator¹⁵, Ruth Malan and Dana Bredemeyer, Cutter
Consortium Enterprise Architecture Executive Report, Vol. 8, No. 6, 2005
• A Business-Oriented Foundation for Service Orientation¹⁶, Ulrich Homann, Microsoft Devel-
oper Network 2006
¹³https://meta.wikimedia.org/wiki/Cunningham%27s_Law
¹⁴https://www.bainstitute.org/resources/articles/defining-business-capability-cheat-sheet
¹⁵https://www.cutter.com/article/enterprise-architecture-strategic-differentiator-388826
¹⁶https://cdn.ymaws.com/www.businessarchitectureguild.org/resource/resmgr/homann_article_on_capabiliti.pdf
Visual Collaboration Tools 25

• From Capabilities to Services: Moving from a Business Architecture to an IT Implementation¹⁷,

Ulrich Homann & Jon Tobey, Microsoft Developer Network 2006
• TOGAF Series Guide: Business Capabilities¹⁸
• Contribution from experiences by Trond Hjorteland¹⁹ (scienta.no²⁰) at a diverse set of clients,
both public and commercial.

¹⁷http://www.inthesandbox.com/msba/Shared%20Documents/From%20Capabilities%20to%20Services%20-%20Moving%20from%20a%
20Business%20Architecture%20to%20an%20IT%20Implementation.pdf
¹⁸https://publications.opengroup.org/g189
¹⁹https://www.linkedin.com/in/trondhjort/
²⁰https://www.scienta.no/
Visual Collaboration Tools 26

Business Model Canvas

What is made possible

Finding bounded contexts doesn’t start by coding but it starts by understanding the business domain.
You need to understand your business’ model in order to be able to help them solving their problems.
But how can you learn about the business model? Business Model Canvas (BMC) is a very powerful
tool to visualise the business model. This was introduced in 2008 in Business Model Generation
book.

How to use it

The audience

Your audience really depends on the purpose. You can visualise the business model with the
company’s business development team to work out a business strategy, or you might want to map
out the business model with dev teams around you in order for everyone to be aware with the
business domain they are working on. Business Model Canvas can be also very powerful when just
using it to understand a specific project’s scope or team’s behaviour. Or even if you want to assess
how an upcoming feature / epic is aligned with the business.

The timing

You can do a workshop on Business Modelling any time. But I would definitely recommend it in the
following situations:

• When a business unit changes around you

• when the organisation changes and it affects the business unit in which you work / deliver
value
• When you want the dev team/s to be aware with the business model
• When there is a new project and you want to see how it will work out (this is a completely
new approach)
• When you want to do a fun team building whilst learning and modelling together (like doing
the BMC even for a fake business will give you a chance to have an engaging session with the
team)

In terms of the lengths I would aim at least an hour long session (which probably will have outcomes
also like questions, assumptions and ToBeDiscussed items).
Visual Collaboration Tools 27

Content

Business Model Canvas has 9 sections that can really describe any companies from the smallest to
the largest. These 9 sections are the followings:

• Customer Segments: To whom do I add value? Who are my most important customers?
• Value Proposition: What problem do I solve for my customers? Why do my customers pay for
my product?
• Channels: How do I sell and deliver the product?
• Customer Relationship: How do I signal changing customer needs? How do I stay top of mind?
• Revenue Streams: What are the main sources of revenue?

These 5 above are all the aspects of a business that the customers can see.
The following 4 are all the internal organisational aspects of the business:

• Key Activities: What are the most valuable activities to provide the value proposition?
• Key Partners: Who are the key partners without whom my business wouldn’t run?
• Key Resources: What are the most valuable resources?
• Cost Structure: What are the main costs to create value?

Running a BMC workshop

1. Discuss the goal and the business you are going to work on with the audience. If you are doing
it with a fake business, put a mission statement together and also give the business a name so
making it easier to relate to that during the workshop.
2. Explain BMC and what each section means.
3. Draw the BMC frame on a whiteboard.
4. Let people have their own thoughts come to the surface first so leave time for them to
individually write down ideas on post-its (to any section of the BMC).
5. Then ask people to put their post-its into the proper section of the BMC. Spend a little bit of
time on merging the duplicates (when people wrote the same thing basically).
6. Start discussing the canvas and put up other ideas, thoughts together.

I would recommend to go from the customer segment: whom do I add value? From here you can
continue with the value proposition: what value do I add to which customer segment. It worth to
have the same colour for the corresponding customer segment and its value proposition.

7. It is very important to capture your questions in the meanwhile (usually on pink post-its) and
mark everything that is an assumption in the BMC. These are very valuable results that you
can take away and discuss / clarify with the appropriate people.
Visual Collaboration Tools 28

Why?
The goal is that you can learn about the business’ model so you can make sure you know and
understand how you can create value for your company, how you contribute to the business’ success
and you also can solve problems for them in a much more effective way.
It is really not about asking for requirements any more but you need to actively contribute in business
success.

Authors, attribution and citations

Alexander Osterwalder and Yves Pigneur - authors of Business Model Generation book
Zsofia Herendi (@ZHerendi²¹) - contributed this article.

²¹https://twitter.com/ZHerendi
Visual Collaboration Tools 29

Context Mapping

What is made possible

The Context Map represents a holistic view of the supply and service relationships between Bounded
Contexts and the corresponding teams. Large parts of the enterprise architecture concentrate
primarily on call relationships between systems. They show which systems offer which services as
providers, they also show which consumers call these services. Also, there is sometimes a technical
consideration of these relationships. For example, it is often indicated whether an interface is a
RESTful resource or a SOAP WebService. Integration middleware such as Messaging Brokers or
Enterprise Service Buses (ESBs) finds their way into those diagrams. The Context Map digs deeper
into those relationships and ignores most of those technical aspects. It is, therefore, an addition to
diagrams explaining call relationships and not an alternative to them. In my experience, the Context
Map helps in the following areas by making implicitly hidden complexity explicitly visible in less
obvious areas of communication between Bounded Contexts:

• Power and influence relationships between teams

• Propagation of domain models
• Governance aspects

How to use it
This part of the chapter is dedicated to the practical application of Context Maps. Although both
Eric Evans and Vaughn Vernon primarily speak of applicability to already existing systems, I think
that you can also apply the Context Map to newly developed systems.

Open-host Service

We often identify Bounded Contexts that offer services to a variety of consumers. Of course, it
makes little sense to implement a separate service for each of these consumers and to translate the
model specifically for each of them. It, therefore, makes sense to provide a uniform interface for
all consumers. Each client must integrate against this interface. Eric Evans defines the Open-host
service in his DDD Reference as follows:
“Define a protocol that gives access to your subsystem as a set of services. Open the protocol so that
all who need to integrate with you can use it.”
The most important features of an Open-host service are:

• One interface for all consumers

• The interface is ideally implemented via a generally callable API (WebService, RESTful
resource, ..).
Visual Collaboration Tools 30

A public API is an excellent example of an Open-host Service. Please note, however, that the
Open-host service does not make any statements about whether this interface is synchronous or
asynchronous in character. One can also regard the publishing of generally relevant events as an
Open-host Service.

Conformist

The Conformist is all about model propagation: the model of another Bounded Context / Team
propagates into the domain model of another Bounded Context. The existing Domain-driven Design
literature often speaks of the Conformist as a possible solution for tricky situations “in which the
upstream has no motivation to provide for the downstream team’s needs” and in which “an interface
tailored to the needs of the downstream team is not in the cards” (from the DDD Reference)
Even though I can entirely understand the motivation from Eric’s blue book and think it’s right, I
believe that the Conformist can be viewed more extensively. First of all, we should be clear about
what possible motivations there are for becoming a Conformist.
One possible reason is convenience. This reason is also very explicitly mentioned in the existing
literature. The downstream team “eliminates the complexity of translation between Bounded
Contexts by slavishly adhering to the model of the upstream team” (from the DDD Reference).
A downstream team can also be forced to become a Conformist. This constraint can come either
through API Terms of Use Agreements or through general enterprise architecture rules. In the case
of Terms of Use Agreements, consumers of mostly commercial APIs are forced to adhere to the
given model slavishly. Corresponding passages in user contracts explicitly forbid client developers
to change the structure of the data used. Although such things rarely occur in reality, I have been
confronted with such restrictions several times during my career as a developer and architect. The
second type of “coercion to Conformist” usually comes from within, generally from the direction
of central business architecture governance boards. They force downstream teams to use upstream
models, especially if they are part of an enterprise-wide model.
The last reason to be a Conformist is of a voluntary nature. The downstream team considers the
model of the upstream side to be incredibly useful and suitable. It, therefore, adapts to the model
out of conviction rather than convenience.
I think that all these reasons to be a Conformist are valid, even if they are not mentioned to this
extent in the literature. However, the result does not change: a Conformist is downstream and it
slavishly adapts to an external model coming from an upstream team.
When mapping existing systems, the Conformist provides valuable insights into how the individual
systems are interwoven with each other and how models propagate themselves in this network.
When using the Context Map Patterns in upfront design, I recommend using the Conformist only
when a team is convinced of the quality of an external model or when it is desired to significantly
constrain a team’s position of influence.
Visual Collaboration Tools 31

Anticorruption Layer

Let’s be honest: most models of historically (and sometimes also hysterically) grown legacy systems
are horrible. They are not very expressive; they are mostly very fragmented and can often only
be understood with a good deal of knowledge about the internals and the domain of these legacy
systems. In an ideal world, nobody wants to pull these models into her application in the form of a
Conformist.
For this reason, there is the Anticorruption Layer. The task of this pattern is to translate an
external model coming from the upstream into a “new” internal model at the downstream level.
The complexity of such a translation naturally depends strongly on the respective requirements.
There are quite simple Anticorruption Layers that don’t even deserve the name Layer. However,
it is also possible to create very sophisticated Anticorruption Layers. Especially with challenging
demands on the Anticorruption Layer, it doesn’t do any harm to take a look at the Facade Design
Pattern from the Gang Of Four book. On Wikipedia it is explained as follows:
“Developers often use the facade design pattern when a system is very complex or difficult to
understand because the system has a large number of interdependent classes or because its source
code is unavailable. This pattern hides the complexities of the larger system and provides a simpler
interface to the client. It typically involves a single wrapper class that contains a set of members
required by the client. These members access the system on behalf of the facade client and hide the
implementation details.”
The Anticorruption Layer is, in any case, a recommended pattern, as it significantly reduces the
coupling between two systems. Of course, there is still a dependency on the upstream model in the
downstream. However, this dependency does not run through the downstream system as a whole
but is isolated within the Anticorruption Layer. This approach makes model adjustments easier to
implement, as only the Anticorruption Layer has to be adjusted. Also, these changes entail less risk
as the external upstream model is treated in isolation within the Anticorruption Layer. Finally, one
can also test an Anticorruption Layer with the help of dedicated unit tests and check for correct
functioning. Integration tests can, therefore, concentrate on the actual challenges of integration.
When mapping system landscapes, the Anticorruption Layer shows interruptions in the model
flow, which indicate a lower coupling between two systems. You can find this pattern in the
code. It is eventually a very technical pattern. When using Context Maps for an upfront design,
I always recommend an Anticorruption Layer if you think the external model is too complicated or
inappropriate and are not forced to be a Conformist.

Customer/Supplier Development

The Customer/Supplier Development Pattern is a tricky one with regards to the existing literature.
The introduction of the chapter in the DDD Reference describes possible starting situations that are
bad:
“A downstream team can be helpless, at the mercy of upstream priorities. Meanwhile, the upstream
team may be inhibited, worried about breaking downstream systems. The problems of the down-
stream team are not improved by cumbersome change request procedures with complex approval
Visual Collaboration Tools 32

processes. And the freewheeling development of the upstream team will stop if the downstream team
has veto power over changes.”
The actual pattern, on the other hand, speaks of a somewhat intact world in which the upstream
team still has the upper hand, but the downstream side has some influence. The DDD Reference
speaks of the fact that priorities of the downstream team are taken into account in the planning of
the upstream team. The whole approach goes so far that requirements made by the downstream side
are budgeted and taken into account in the planning of the upstream team. The pattern explicitly
mentions everyone understanding the commitment and schedule.
If you work in an agile environment, you can put the downstream team in a customer role towards
the upstream side. Customers make demands to the supplier, and these demands are discussed
together in planning sessions and scheduled on a timeline.

Shared Kernel

The Shared Kernel is about two teams sharing a part of the model. Such a Shared Kernel can be a
JAR dependency, a database schema or a DLL. In contrast to a general interface description such as a
WSDL or a Swagger definition, the Shared Kernel is a “tangible artifact”. At this point I would like to
explicitly point out that a shared database is a Shared Kernel. This manifestation can be found very
regularly in grown, monolithic applications and often represents a substantial problem in these.
With the help of a Shared Kernel, the affected teams naturally save a lot of integration and translation
work, but it comes with a very tight coupling. This coupling is stronger than that of a Conformist,
since the Shared Kernel, for example in the case of a JAR library containing a model, amounts to
binary compatibility.
Is a Shared Kernel a good or a bad pattern? The answer to that is, as so often, “it depends.” In a new,
modern system-of-systems that follows the microservices idea, a Shared Kernel would be a bad idea.
We would like to explicitly focus on the highest possible decoupling in such a system architecture
between the individual teams and their systems. In the case of a grown system, it all depends on how
the different teams deal with the Shared Kernel. Some of them make sure that the shared artifact
is as small and long-term as possible. In this case, the Shared Kernel is not a significant problem in
daily project work. However, I have also experienced several unpleasant conflicts between teams
around such shared artifacts. This is particularly the case if the two groups are strongly separated
organizationally (e.g., between teams of two competing external vendors). In such cases, the Shared
Kernel becomes toxic and must be dissolved urgently. I would also like to mark such Shared Kernels
extra when analyzing existing landscapes. I use an additional label here.

Published Language

A Published Language is a data exchange format used between different Bounded Contexts. This
format must be well documented and designed so that individual Bounded Contexts can easily
translate from their own (internal) Ubiquitous Language to the (external) Published Language. A
translation should also be possible in the reverse direction. Eric Evans emphasizes in his DDD
Visual Collaboration Tools 33

Reference that a Published Language is used as a data exchange format (mostly designed by
committees) in numerous industries. Most readers of this article will undoubtedly have come into
contact with two prevalent Published Languages on their smartphone or tablet. The VCard, a file
format standard for electronic business cards, or the iCalendar, a “MIME type which allows users to
store and exchange calendaring and scheduling information such as events, to-dos, journal entries,
and free/busy information.”
Both, the VCard or the iCalendar are perfect examples since they are widely used, they are well
documented, they have their own language, and there is a committee for their further development.
The Published Language is an exquisite way to decouple Bounded Contexts from each other. Each
Bounded Context can implement it in its way. As long as the translation between the internal model
and the model of the Published Language model works, the teams of the Bounded Contexts have all
the freedom to find their own solutions.

Separate Ways

The basic statement of the Separate Ways pattern is that one Bounded Context has no points of
contact with another. The motivation for this can be, for example, that the costs for integration are
in no relation to the benefit. That’s a very conscious decision then. Another application for Separate
Ways is uncertainty in my eyes. If you don’t know how the number of users of a system will increase
in the beginning, you can initially choose a minimum viable product without specific integration
efforts and establish an organizational solution. Integration can then take place later at any time
when the organizational solution reaches its limits in terms of scalability. Usually, you will then
know better about the exact integration requirements and can develop a tailor-made solution.
The two scenarios described above are particularly interesting if you are implementing a new system.
However, it is also good to know where such organizational solutions are present when analyzing
existing application landscapes. Especially when cartographing software applications used in call
centers, I regularly observe that the agents working there do not have a perfectly integrated and
media-break-free application. In contrast: here, Copy & Paste is often used to manually “integrate”
between different applications. Especially when planning IT transformations, the knowledge of
where work is done manually between applications is precious.

Big Ball Of Mud

Big Ball Of Mud is only geared towards context mapping of already existing systems. When
designing new systems or system landscapes, it would be very awkward to create a Big Ball Of
Mud consciously.
The Big Ball Of Mud is primarily a feature that marks a part of a model or even an entire system.
Such a section is characterized by the fact that its models are difficult to understand, unclear and
branched arbitrarily. It is impossible to draw clear dividing lines somewhere in such a spaghetti
model. Definitions and rules are contradictory and ambiguous in such an environment. Usually,
these are parts of a system or a system group that nobody wants to touch anymore because the
implications of changes are not foreseeable.
Visual Collaboration Tools 34

For this reason, it is recommended to draw a border around this area to mark it as a Big Ball Of
Mud. It would be best if you took rigorous care that models or individual elements of them do not
propagate themselves further. For example, a Conformist on the model from the Big Ball Of Mud
would undoubtedly be a critical finding when analyzing a Context Map. The same applies to Shared
Kernels, which are shared with Big Balls Of Mud. In contrast, the Anticorruption Layer would be a
suitable means to delimit the model of one’s Bounded Context against that of a Big Ball Of Mud.

Partnership

Also, the Partnership pattern is not included in the blue Domain-driven Design book by Eric Evans.
Vaughn Vernon introduced it in his (red) book Implementing Domain-driven Design. Just like the
Big Ball Of Mud, the partnership pattern is primarily a trait. However, this is not a characteristic of
a system or a part of a system, but it is instead a description of how two teams deal with each other.
The partnership describes close cooperation between two teams. This cooperation includes coor-
dination of development planning and close coordination of mutual integration. The coordination
of design and integration of interfaces is of central importance. This joint alignment may end in
a joint coordinated release if necessary which results in a very close coupling between the teams
involved. However, you should pay attention to the fact that this coupling does not end in overly
generic models. Developers would accumulate much detailed knowledge about the business model
of the other team, which in turn considerably increases the reciprocal coupling. Mutual willingness
to compromise and empathy are necessary for solving problems to find quick and targeted design
solutions.
The establishment of a partnership makes sense when the success of both teams depends on each
other. A cooperative relationship is therefore desirable when teams in two contexts will either
succeed together or fail together.

Drawing Context Maps

There is no formal definition for the graphical representation of Context Maps. Also, the existing,
notable literature only rudimentarily indicates some possible graphic notation possibilities. This
chapter is primarily based on the representation used by Alberto Brandolini and Vaughn Vernon,
and I would like to try to present it as comprehensively as possible. However, I will take the liberty
of adding a few details.
In this notation, I usually use circles or ellipses to represent Bounded Contexts. Within this form is the
name of the context. I mark upstream and downstream as labeled squares next to the contexts. I know
of arrows used for this, but this is often misinterpreted as call flow and leads to misunderstandings.
Visual Collaboration Tools 35

Two Bounded Contexts in an Upstream Downstream relationship

The individual patterns are labeled as squares and attached to (rather than next to) the Bounded
Context. Here, for example, we see one that is upstream and implements an Open-host Service.

An upstream Bounded Context providing an Open-host Service

In the meantime, the following abbreviations have been established for the labels in the practical
work I have observed:

• Open-host Service: OHS

• Conformist: CF
• Anticorruption Layer: ACL
• Customer / Supplier Development: CUS and SUP (depending on up- and downstream)
• Shared Kernel: SK
• Separate Ways: SW
• Published Language: PL
• Big Ball Of Mud: BBOM
• Partnership: there is no clear trend, I usually use the full term in my work

The advantage of this form of notation is that the individual elements can easily be combined to
represent relationships in a holistic way. Here are a few examples:
Visual Collaboration Tools 36

An upstream Bounded Context providing an Open-host Service with an Anticorruption Layer on the downstream

An upstream Bounded Context providing an Open-host Service which transports a Published Language with a
Conformist (on the Published Language) on the downstream

Two Bounded Contexts with a Shared Kernel

Why?
Context Maps help us in getting a better understanding about the dependencies between teams and
Bounded Contexts. Thereby they address a variety of aspects:

• The flow of domain models between Bounded Contexts (Conformist for instance)
• The power dynamics between teams (Customer Supplier for instance)
• How functionality gets provided within a problem domain (see Open-Host Service)

By doing so Context Maps are a powerful tool for:

Visual Collaboration Tools 37

• Planning modernizations of grown application landscapes

• Establishing a decentralized governance model without boards, which become bottelnecks
• Detecting risks by knowing how models propagate

Authors, attribution and citations

Evans, Eric (2003): Domain-driven Design, Addison Wesley
Vaughn, Vernon (2013): Implementing Domain-driven Design, Addison Wesley
Evans, Eric (2015): DDD Reference https://domainlanguage.com/ddd/reference/²²
Alberto Brandolini - Strategic Domain Driven Design with Context Mapping https://www.infoq.com/articles/ddd-
contextmapping²³
Wikipedia: Conway’s Law https://en.wikipedia.org/wiki/Conway%27s_law²⁴
Michael Plöd(@bitboss²⁵) - contributed this article.

²²https://domainlanguage.com/ddd/reference/
²³https://www.infoq.com/articles/ddd-contextmapping
²⁴https://en.wikipedia.org/wiki/Conway%27s_law
²⁵https://twitter.com/bitboss
Visual Collaboration Tools 38

Decision Log

What is made possible

As a facilitator of visual meetings, I usually find myself helping teams across different sessions. I
observed that it could cause friction when teams need to revisit past decisions, leading to arguments
about those decisions. Inspired on the pattern out of Living Documentation²⁶ book, I created a
visualisation call Decision Log.

How to use it
For this simple visualisation, you need a flipchart and a few stickies. For every decision made by
the team during a visual meeting, record it. Use the date as an anchor, and it helps the teams
remembering the context.
²⁶https://www.amazon.com/Living-Documentation-Cyrille-Martraire/dp/0134689321
Visual Collaboration Tools 39

Example of a Decision Log. All rights reserved

I also advise the teams to record the decisions in a durable format. For that, they can use the
Visual Collaboration Tools 40

Architectural Decision Records²⁷ and treat the decisions as code.

Why?
The main driver for the Decision Log is to have a positive discussion rather than a rehash of it. The
path to a decision is essential, and this visualisation gives more details on why some decisions are
made.
Especially during the discovery of software (you can think about new teams, as for example), the
teams can make conscious decisions about what is in, and what is out, speeding up the process.

Authors, attribution and citations

This article was written by João Rosa²⁸. He is a Strategic Software Delivery Consultant at Xebia,
specialised into helping companies to leverage the power of technology to drive their business.

²⁷https://adr.github.io/
²⁸https://twitter.com/joaoasrosa
Visual Collaboration Tools 41

Domain Quiz

What is made possible

Domain Quiz is a relative short assessment of teams’ current domain knowledge followed by a
common evaluation session. It is also another fun way of learning about the domain.

How to use it

The audience

Your audience really depends on the purpose. You can do a quiz with your team, with individuals
who are for instance stakeholders in a project and working towards the same goal, you can do it
with the management even. Or do cross bounded context quiz with multiple teams and you can
make it a competition at your company.
You can decide whether or not you do anonym quiz. I would recommend the anonym one, as
according to my experiences people are more relaxed if they know that their names won’t be there
attached to their results.

The timing

You can do the quiz anytime! I don’t think it is something that needs to be done around milestones
or in specific sprints or quarters. Anytime, when it makes sense and what is maybe more important:
do it regularly.
In terms of the lengths I would aim not longer quiz than 20 mins (which probably means 10–15
multiple-choice questions max).

Content

I think this is the hardest part because this is really dependent on the context. What I can do here is
to provide you some guidelines for putting the questions together:

• Definitely ask about the end users of your system. But don’t ask like “Who is our end user?”
but ask like “Who is the persona we provide the most value for?”
• Ask about the value, ask why users are using your product or why they are part of the certain
domain flow.
• If there are specific feature sets or functionality groups you want to find out your team’s domain
awareness about, go ahead and ask about those specifically. If there are reports or analytics or
some special calculations in the domain eco-system it might be good to include that too.
Visual Collaboration Tools 42

Evaluation and findings

You should analyze group results and look at the weakest areas where the team really needs
improvement. You should do common session/s with the team after you analyzed the results to
address these areas together.
It doesn’t matter whether you do the quiz online or on paper, the evaluation together with the team
needs to happen. That’s the main point in it, that’s where everyone can learn the most.

More hints and tips

• Emphasize the goal! Always emphasize that this is not about individual results and punish-
ment. When people hear words like “quiz” many of them think it is some assessment to judge
them and there will be consequences if they don’t do 100%.
• Spend time on preparation! Send out the domain areas in advance so giving the opportunity
for people to learn. If you will have a prize, make sure you mention this beforehand, they
will be more eager to learn and prepare. Even with this the team’s domain knowledge can be
improved already.
• Do follow-up! And what you shouldn’t forget is that you need to quite regularly do a domain
quiz to see the awareness with the updates and changes in the domain. This means more work
for you because it is not about having the same domain quiz all the time but you always need to
come up with new questions. But obviously 2–3–4 questions are totally enough as a follow-up
if you’ve already made sure earlier that the basic domain knowledge is there and now you just
want to assess the awareness with the newer things.
• Make it fun, add prize! Prize can be anything, a small thing like a piece of chocolate or even
some bigger things like half a day off or anything like that, it depends how much you want to
motivate people and how important it is for you to learn about the domain awareness.

Tools

I’m sure there are plenty of tools you can put a quiz together with. I usually use Google Forms
as I’m very satisfied with its behaviour. It is very easy and quick to put the quiz together (after
you’ve already done the hardest part: figuring out the questions), I really like that I can do feedback
(whenever someone submits the quiz they immediately see the feedback about correct and incorrect
answers and the reasoning behind that I provide).
No matter what tool you use, always make sure…
that you provide feedback at the time of the submission
you provide reasoning both for correct and incorrect answers
the answers are not predictable
you test it thoroughly in advance — send yourself the link and fill in the quiz and check the feedback
etc. before you send out to your people. Step in the team’s shoes and try to think how will they feel
when they see that particular feedback or question.
Visual Collaboration Tools 43

Example

You can find a very basic example here²⁹ just to show that it is nothing more difficult than a basic
questionnaire. The content makes it unique that supposed to be obviously your domain.

Why?
The goal is that you want to learn about your team’s (or colleagues, etc.) current domain awareness
in order for you to know where to improve it.
In order to design great architecture dev teams need to know the domain. And domain experts need
to realise if team doesn’t have the knowledge, identify the areas where improvement needed and
create an action plan for it.
The reason why you might want to learn more about the level of people’s domain knowledge may
vary. Some of the clues can be like:

• you simply get too many questions from the team on how things work
• many times the features don’t even pass the dev test phase
• you realize that QA spends too much time with testing even if there is some simple improve-
ment made in the system
• when you are not available people ask the team about the system behavior and they have no
idea about that
• there is a specific feature you need to design and implement with the team, but first you want
to have an understanding on the team’s awareness about that area in the system
• etc.

Authors, attribution and citations

Zsofia Herendi (@ZHerendi³⁰) - Author of this article

²⁹https://docs.google.com/forms/d/e/1FAIpQLSeXK2_TTCkPYwobNgDVn0DvZhShm_jO_8gg2Dtqk3HHxx6Wuw/viewform
³⁰https://twitter.com/ZHerendi
Visual Collaboration Tools 44

Domain Storytelling

What is made possible

Domain Storytelling is a means to transfer expertise from the minds of domain experts to the minds
of developers, testers, product owners, product managers, business analysts -– to anyone involved
in software development.
Domain Storytelling is useful to understand business processes, to establish common understanding,
and to talk about business needs. And it is particularly useful in DDD. It can help you to find sub-
domains and bounded contexts, establish ubiquitous language, and model a domain in code.
Domain Storytelling is built around a proven way to pass on knowledge and experience: Tell
stories! This fundamental form of human communication is deeply rooted in all of us. In software
development, we do not share our stories around a campfire. We gather in front of whiteboards. The
business experts are our storytellers. We want them to tell us true stories about their daily work. No
abstract generalizations, no hypotheticals. Rather, we want concrete examples of what is actually
happening in a domain so that we can have conversations about it. Here is an example:
At an airport, you have probably waited for a bus to take you from the gate to the plane. Have you
ever wondered how the bus transfer is organized and why it can take so long? There are still airports
where a bus transfer requires many manual steps:
Let’s start from the simplest case – only one bus is needed for the transfer. At the departure gate,
the gate agent (the person who handles the boarding) calls a bus dispatcher. The gate agent orders
a transport and specifies the number of passengers (called PAX), the departure gate, the flight, and
the position where the airplane is parked. The bus dispatcher creates an order in her bus scheduling
system. She gives this order by telephone to a bus driver. The bus driver then knows how many
passengers he has to bring from A to B and when. But the job is not yet done. After the transport, the
bus driver logs the details of the journey (including how many passengers were actually transported
and whether there were any irregularities on the way). The bus driver notes all this by hand. Only
now can he accept the next order. At the end of the shift, the bus driver submits the collected logs
to the bus dispatcher, who then enters the details of each transport into the corresponding order in
the bus scheduling system.
Imagine that instead of reading the above text, a gate agent, a bus dispatcher and a bus driver tell
you this story. And imagine that at the same time someone draws the picture (see below) on a
whiteboard. That is your first domain story!
Visual Collaboration Tools 45

Driving passengers from gate to runway.

How to use it
Domain Storytelling means that we let domain experts tell us stories about their tasks. While
listening, we record the stories using a pictographic language. The domain experts can see
immediately whether we understand their story correctly. After very few stories, we are able to
talk about the people, tasks, tools, work items, and events in that domain.

The Pictographic Language

To visually capture domain stories, we need symbols and rules to combine the symbols. The symbols
of the pictographic language consist of icons, arrows and text. Icons and arrows are annotated by
short texts to create a “visual” sentence. We use terms from the domain language for the labeling.
There are two kinds of icons and one kind of arrow:
Visual Collaboration Tools 46

• Actor

Actors are the acting persons and IT systems of a story. Typically they are named with a role
identifier (e.g. “bus dispatcher”).
Visual Collaboration Tools 47

• Work object

The work objects with which the actors accomplish their tasks. Often something you can touch
and see, like the “bus”. Sometimes also an objectified concept, like the “order”.
Visual Collaboration Tools 48

• Activity (with number)

Activities describe what the actors do. They are expressed by arrows. The numbering of the
arrows indicates the order of the activities. The activities are the verbs in our stories.

Together the elements are used to visualize the story:

“The customer signs the contract”

Preparing the Workshop

Among the participants of the workshop are:

• business experts (often from several departments),

Visual Collaboration Tools 49

• development team members, and

• a moderator.

It is important and challenging that the “right” people participate. Rarely, a single person can tell
an entire domain story. Non-trivial business processes are usually cooperative and therefore there
are different views on a given process. This implies that several workshop participants contribute
to the story and agree on what belongs in a picture. Each Domain Story represents the common
understanding of its narrators. Make sure you invite real experts – not “proxies” who only know the
daily business from hearsay.

The Workshop

Domain Stories are told from the perspective of actors. For example, an actor can be a person, a
group of people or a software system. What all actors have in common is that they play an active
role in the Domain Story.
Every Domain Story is about a concrete, meaningful example of a business process. Usually very
few domain stories are enough to grasp a business process. We recommend that you start modeling
the standard case – the 80% case – and the happy path first. This will give you an overview of the
purpose of the process. Then you model Domain Stories for significant variations or error cases.
Smaller variations such as optional activities are not worth a domain story and can be recorded as
textual annotations.
The stories can be captured with different tools; these can be digital or analog.
For analog modeling, a combination of a whiteboard and sticky notes works well. The icons will be
drawn on the stickies, the arrows directly on the whiteboard. This way refactoring can easily done
by moving around the stickies and redrawing the arrows.
For digital modeling, a good tool is the Domain Story Modeler³¹. You can try it online³². In the
workshop setting a projector with connected computer or tablet is needed.

Why?
Domain Storytelling is very versatile. Depending on what you use Domain Storytelling for, you will
need to adapt it.

• Learn domain language: When you are new to a domain, e.g. because you are a contractor.
Also useful to bring together domain experts from different departments, cross department
boundaries and challenge assumptions. Particularly useful if you are into DDD and want to
work on the ubiquitous language of a bounded context.
³¹https://github.com/WPS/domain-story-modeler
³²https://www.wps.de/modeler/
Visual Collaboration Tools 50

• Finding boundaries: When you need to break down a domain into manageable units. Typical
examples are: Splitting a monolith into modules, designing microservices or self-contained
systems, and finding context boundaries in DDD.
• Modeling in code: Domain Stories can help you to determine which classes and methods you
need to express your domain knowledge in code. (Assuming that you work with an object-
oriented programming language. If you prefer a functional programming that is also possible.)
You can use terms from the domain directly in your code.
• Requirements elicitation: When you need to bridge the gap between domain knowledge and
requirements for software development. You can derive written requirements from Domain
Stories – not specifications, but something like User Stories.
• Support organizational change: When you develop a new software system, this system usually
changes the way people work. But often, all that the people involved in a development project
talk about are requirements. A pile of requirements does not turn into a seamless business
workflow. With Domain Stories, you will not loose sight of what all those requirements are
good for.

Tips and Traps

* The icon set should be adapted to the domain. The icons should convey meaning and make the
Domain Story more “tangible”. Using many different icons will water down your pictographic
language.
* The moderator should explain an icon when it first appears in the story: “I will use this phone icon
to show that the gate agent calls the bus dispatcher to order a transport.”.
* When there are unconnected parts of a domain story (i.e. a “plot hole” between them) it is usually
of interest to ask why.

• When the domain story is finished, the moderator re-tells the story from beginning to end.
This helps to check whether all participants agree on the domain story.
• Discuss the notes for possible alternative stories. Let the participants decide which are just
small variations that should be included in the picture as comments and which alternatives
deserve their own domain story.
• As a moderator, you can stimulate this discussion with questions like:
– Are we talking about the same task, which is sometimes solved differently? Or are we
talking about another task?
– What would be different if …?
– Am I right that the only difference is that…

Authors, attribution and citations

You can find more resources on www.domainstorytelling.org. Domain Storytelling is described in
detail in Stefan Hofer’s and Henning Schwentner’s book³³. The book also covers the roots of Domain
³³https://leanpub.com/domainstorytelling
Visual Collaboration Tools 51

Storytelling. Its origins go back to the University of Hamburg where a predecessor of was developed
in the 1990s and 2000s.
Visual Collaboration Tools 52

EventStorming

What is made possible

It is not the domain experts knowledge that goes to production, but the assumptions of
the developers.
-Alberto Brandolini

You can help groups visualise their story and start aligning their mindset to gain new insights
quickly. Due to the adaptive nature of EventStorming (https://EventStorming.com)³⁴ it allows
sophisticated cross-discipline conversation between stakeholders with different backgrounds, de-
livering a new type of collaboration beyond silo and specialisation boundaries. The power of
EventStorming resides in that it has just enough structure to co-create knowledge and solutions.
Almost everyone can jump in and learn EventStorming during a workshop, without any prerequisite
knowledge.
While it originally was invented for a workshop to model Domain-driven design aggregates, it now
has a broader spectrum.

How to use it
EventStorming is a perfect fit when you want to visualise and explore a storyline in order to share
knowledge or solve complex problems. Because of the adaptive nature it can be used for different
scenario’s which are fully described in the next chapters. They are:
Official book types:

• Big Picture EventStorming

• Business process modelling (Work in progress)
• Software design (Work in progress)

From the community there are several other examples risen to use EventStorming like:

• EventStorming for planning by Alberto Brandolini (Work in progress)

• Team Flow by Paul Rayner
• Strategic Software delivery by Kenny Baas-Schwegler
• Retrospective EventStorming by Alberto Brandolini
³⁴https://eventstorming.com/
Visual Collaboration Tools 53

Why?

Purpose

• Engage the whole group to co-create and share knowledge continuously with a group of cross-
diciplines.
• Visualise a storyline in order to see patterns and gaps.
• Break silo’s and empower sharing.
• Visualise hotspots of a storyline.

Big Picture EventStorming

What is made possible

Any organization that designs a system (defined more broadly here than just information
systems),
will inevitably produce a design whose structure is a copy of the organization’s commu-
nication structure.
— Mel Conway

In a larger business domain, people often face individual and collective difficulties understanding
and dealing with complexity. People lose the ability to see the big picture, losing sense of
multiple viewpoints and a shared understanding and vision among the team. During a Big Picture
EventStorming, we put all the relevant people in a room sharing knowledge about what the domain
does. The group continuously crunch knowledge on the domain as a whole, mark hotspots and figure
out together what the next steps will be. We end up with a shared vision of the domain and enough
information to design emergent bounded contexts.
Visual Collaboration Tools 54

How to use it

Preparing the workshop

Room setup Credits: EventStorming by Alberto Brandolini

Find a room with a wall of minimal 10 meters width to stick a paper roll on. Use a flipchart as a
legend to update during the workshop. Have enough stickies and markers for the whole team to use,
you need the following (Colours can change if needed):

Big Picture tools

The workshop

Steps:

1. Explain the participants what EventStorming is, and what a Domain Event is.
2. Chaotic exploration - Let the participant to write down all the Domain Events they can think
of. Ask them to stick them on the paper roll the way they think it should.
3. Enforcing the timeline - Now the participants need to enforce the timeline, making sure events
are in the correct order. Possible duplicate events need to be discussed and if double removed.
Visual Collaboration Tools 55

Now structure can start to emerge through Key/pivotal events. Between these events smiwlanes
can start to form. Use post-it labels to make these boundaries visible. Capture any problems,
questions, hotspots or conversation points on a pink colored stickies.
4. Explicit walktrough - Once enough structure is emerged, do an explicit walktrough with the
all the participants. Start from the left and let a participant tell the story.
5. Actors and sytems - The entire business flow is now visualised and structured. We can now
add Small long yellow post-it as actors and long pink post-it as systems to the relevant domain
events.
6. Opportunities - We don’t only want to show problems, questions, hotspots or conversation
point. We also want to show opportunities. Use the green post-it to add these.
7. Next steps - Give each participant two small long blue post it so they can draw an arrow on.
They can now vote on a different hotspots or opportunity they think is the most important one
to focus on.

Why?

Purposes

• To assess the health of an existing line of business and to discover the most effective areas for
improvements;
• To explore the viability of a new startup business model;
• Creating a shared state of mind of the vision of the domain;
• Input for doing Conway’s law alignment, aligning business models/products to engineering
teams;

Tips and Traps

Authors, attribution and citations

• Alberto Brandolini, credits from his book³⁵ and his website: (https://EventStorming.com)³⁶
• Kenny Baas-Schwegler(@kenny_baas³⁷) - Contributed to the article

Team flow EventStorming

What is made possible

The enemy of flow is the invisible and unmeasured queues that undermine all aspects of
product development performance.

• Don Reinertsen
³⁵https://leanpub.com/introducing_eventstorming
³⁶https://eventstorming.com/
³⁷https://twitter.com/kenny_baas
Visual Collaboration Tools 56

<i>The Principles of Product Development Flow</i>

Most development teams remain blissfully unaware of the negative impact of these invisible queues
on productivity, or how to deal with them effectively. After all, how can we fight an invisible enemy?
Isn’t it better to focus on the problems we can see? So the typical team approach to improving
productivity is to focus on the work being done. For example, trying to make the coding more
efficient, or by starting new work when something gets blocked.

How to use it

Preparing the workshop

Room setup Credits: EventStorming by Alberto Brandolini

Find a room with a wall of 6-8 meters width to stick a paper roll on. Use a flipchart as a legend to
update during the workshop. Have enough stickies and markers for the whole team to use, you need
the following (Colours can change if needed):
Visual Collaboration Tools 57

Team flow tools

Invite everyone from the team and if the teams feels comfortable invite the manager or person who
can help solve hotspots outside of the team.

The workshop

1. Explain to the group the concept of EventStorming and what an Event is in the context of this
workshop. Put the event on the flipchart in order to keep the legend updated
2. Start with chaotic exploration of team events. Each person for themself writes down steps in
the flow of software delivery for the teams.
3. Enforce the timeline. The group will now try to make a consistent timeline of the flow.
Removing duplicate events.
4. Capture any problems, questions, hotspots or conversation points on pink colored stickies.
5. Add in the small long yellow for marking who does what event.
6. For every queue, talk it through as a team in terms of how much of a friction point it is for the
overall flow. Are there simple ways to reduce the time that work spends in that queue?

Example Team Flow

Visual Collaboration Tools 58

Why?

Purposes

* To improve software delivery flow and continuously improve software delivery of a team.
* Know what Continous Delivery capability to try next to improve lead time.

Tips and Traps

• Be carefull with an outsider in the room, the team can feel unsafe.
• Events that look duplicate might not actually be ducplicate. Language can be ambiguise. Be
sure people have a conversation of what do you mean?
• Let a manager observe when the team agrees, but let that person be quiet and only ask questions
that clarifies.
• The goal is to NOT to eliminate all queues but to manage and constrain them.
• Some possible tactics for managing an emergent queue to improve overall flow:
– Set a WIP limit for this queue.
– See if the queue can be eliminated, perhaps through automation (e.g. CI/CD) or better
collaboration (BDD, devops)
– Use the EventStorming map to build out a kanban board so you can limit WIP at the team
and work state levels.

Authors, attribution and citations

• Paul Rayner, credits blog post: EventStorming Team Flow³⁸

• Kenny Baas-Schwegler(@kenny_baas³⁹) - Contributed to the article

Strategic software delivery EventStorming

Kenny is writing

What is made possible

If we have a system of improvement that is directed at improving the parts taken

separately.
You can be absolutely sure that the improvement of the whole will not be improved.
-Russel L. Ackhoff

Teams should be able to do continuous delivery on their own. Often time we find teams still
depended on other teams when delivering software. That is why we need to put all these
dependencies in one room and to visualise the entire delivery flow. Then we can find constraints
created from queues, preparation, process or assembly. We are ending up with deciding what the
theory of constraint is to exploit that one and decrease the lead time the most effective.
³⁸http://thepaulrayner.com/eventstorming-team-flow
³⁹https://twitter.com/kenny_baas
Visual Collaboration Tools 59

How to use it

Preparing the workshop

Room setup Credits: EventStorming by Alberto Brandolini

Find a room with a wall of minimal 10 meters width to stick a paper roll on. Use a flipchart as a
legend to update during the workshop. Have enough stickies and markers for the whole team to use,
you need the following (Colours can change if needed):

Strategic software delivery tools

The workshop

1. Explain to the group the concept of EventStorming and what an Event is in the context of this
workshop. Put the event on the flipchart in order to keep the legend updated
2. Start with chaotic exploration of delivery events. Each person for themself writes down steps in
the flow of software delivery for the teams.
Visual Collaboration Tools 60

3. Enforce the timeline. The group will now try to make a consistent timeline of the flow. Removing
duplicate events.
5. Capture any problems, questions, hotspots or conversation points on pink colored stickies.
4. Let the group use the post-it label to draw boundaries when needed between bigger part of the
process.

6. Add in the small long yellow for marking who does what event.
7. Use the small red coloured stickies to add in queue, preparation, process or assembly time for
events.
8. Let everyone in the team have a two minute elevator pitch about what constraint they think
the focus point should be on.
9. Either do an arrow vote by giving everyone two arrows to point to what they think is the
biggest constraint that need solving. Or use deep democracy to come to a collective authocracy
solution and go even deeper on issues when time is enough.

Why?

Purposes

* To find the theory of constraint of your organisation software delivery.

* Create a collective authocratic decision that has buy-in from the entire group in order to solve the
next constraint.

Tips and Traps

• Events that look duplicate might not actually be ducplicate. Language can be ambiguise. Be
sure people have a conversation of what do you mean?
• Let people structure the EventStorming themself and observe what happens to the group
• Let one person observe only (prefarably and anthropologist) in order to also get insight on the
culture of the company.

Authors, attribution and citations

Based on:

• Paul Rayner, credits blog post: EventStorming Team Flow⁴⁰

• Alberto Brandolini Big Picture EventStorming from his book⁴¹ and his website: (https://EventStorming.com)⁴²

Kenny Baas-Schwegler(@kenny_baas⁴³) - Contributed to the article

Pim Smeets(@p_smeets⁴⁴) - Contributed to the article
⁴⁰http://thepaulrayner.com/eventstorming-team-flow
⁴¹https://leanpub.com/introducing_eventstorming
⁴²https://eventstorming.com/
⁴³https://twitter.com/kenny_baas
⁴⁴https://twitter.com/p_smeets
Visual Collaboration Tools 61

Feedback / Retrospective

What is made possible

It is not enough to do your best; you must know what to do, and then do your best.
-W. Edwards Deming

One of the most significant characteristics of a highly-efficient team is the ability to improve
continuously.
In order to set up a virtuous continuous improvement cycle, it is necessary to regularly gather quality
feedback, identify possible improvement ideas, and act on the most important ones.
Due to its highly versatile nature, EventStorming makes a great tool to gather quality feedback in a
very efficient way.

How to use it

Because the core idea of EventStorming is to organize events on a timeline, it makes it a powerful
tool to gather feedback. You start by building the timeline collaboratively and then enrich it with
the different aspects that you want to explore.

Preparing the workshop

Like any EventStorming workshop, it all starts with a large modeling surface, a bunch of colored
stickies, fine-point markers, and of course a visible legend.
The size of the wall you are going to use will depend on the length of the period you will retrospect
on, and the quality of the feedback you wish to obtain. The larger the surface, the better quality
you’ll get.
The following colors of post-it notes can be used.

Retrospective tools
Visual Collaboration Tools 62

The workshop

Once your room is ready, gather people around your modeling space. Make sure everyone grabs a
marker, but do not distribute the post-it notes just yet.

1. Tell the group that the objective is to gather feedback and identify potential improvement ideas.
2. Explain the notion of timeline and what an event is. Then add an orange post-it note on the
visible legend, write Event on it and next to it Something that happened during a period of
time.
3. Clarify the period of time that people should be considering - i.e. last iteration, last week, last
couple of days.
4. In order to jump start people’s ideas, write down yourself a first event on an orange post-it note
- something meaningful that happened during the period - and stick it on the wall according
to the timeline.
5. Invite people to start writing other events. Do not provide any other color of post-it note yet.
6. Give people enough time to build a proper timeline. Explain that it is not an issue to have
duplicates. The time you allow to building the timeline depends on the timebox you have for
the overall exercise, the length of the period you explore and the ability of the group to build
if fast.
7. When you see that people are not writing down new events anymore and when you feel that
the timeline is good enough, it’s about time to introduce a new concept.
8. Take a pink post-it note, stick it on the visible legend, write down WTF on it and next to it A
question I asked myself, A moment of doubt, What the hell just happened?. Explain the new
concept to the group and distribute the new color of post-it notes.
9. When you see that people are not writing anymore, introduce yet another concept. Take a green
post-it note, stick it on the visible legend, write down Take Away on it and next to it Something
I learned, Something I will use again. Explain the new concept to the group and distribute the
new color of post-it notes.
10. When you see that people are not writing anymore, introduce yet another concept. Take a
yellow post-it note, stick it on the visible legend, write down Improvement on it and next to it
Something we can do better. Explain the new concept to the group and distribute the new color
of post-it notes.
Visual Collaboration Tools 63

Example of visible legend

Depending on the size of the group and the period of time you want feedback on, the exercise may
take between 15 and 60 minutes.
Visual Collaboration Tools 64

Once you are done with gathering feedback, you can decide to live it like that and just read through
the content. Or you can ask a volunteer to walk the group through the board and do a bit of story
telling. Alternatively, you can ask people to dot-vote⁴⁵ on the most important improvement ideas to
prioritize them. If so, then write down the top 5 ideas and ask for volunteers to take ownership and
assign a due date for each idea.

Why?

By focusing on events first, you make things very factual and avoid too much judgment. Building
the timeline collaboratively helps people reflect on what actually happened during the period. Then,
by adding on to the notation iteratively, starting with the WTF concept, you help people focus on
their feelings. You then put an emphasis on the learning experience by introducing the notion of take
away. Finally, based on the three previous notions, you focus on concrete ideas that can possibly be
implemented to improve the whole process or experience.
Thanks to the collaborative nature of EventStorming and to the incremental notation, you build
a non-judgmental flow of Facts (a.k.a. Events) -> Feelings (a.k.a. WTFs) -> Learnings (a.k.a. Take-
Aways) -> Improvements. From experience, the quality of the feedback and ideas that you get out of
this exercise is much better than with many other traditional retrospective activities.

Purposes

Here are the main goals of using EventStorming to gather feedback:

• Build a shared vision of what actually happened.

• Identify moments of doubt or uncertainty
• Identify main learning points.
• Identify improvement ideas.
• Prioritize improvement ideas.
• Decide what to do.

Tips and Traps

• Don’t get stuck on the terminology that we used here to describe the different elements of the
notation, like WTFs or Take-aways. You can - and should - use your own vocabulary if it better
fits your own context.
• If you don’t have a large wall, do it on a long table, or even on the floor. Never be limited by
the physical space. It will limit the capacity of your team to reflect and innovate.
• You can explore and get feedback on different aspects by adding more concepts using other
colors, depending on what your objective is (a.k.a. Model Storming). Be cautious though, not
to add too many concepts. It will get confusing. Four or five should be more than enough.
⁴⁵https://en.wikipedia.org/wiki/Dot-voting
Visual Collaboration Tools 65

• Observe the group dynamics and add only new concepts when you feel it’s the right time. This
requires a bit of experience in workshop facilitation.
• It is usually better to put the emphasis on collaboration rather than completeness. You don’t
really care if an event was forgotten, unless it was a really important one. What you should
care about it that people share what they experienced and maybe relate to each other.
• When it’s over, it’s over. Don’t try to force anything out of people, unless you are prepared
to dig deeper using some coaching skills. As a facilitator, beware not to project your own
assumptions of what happened on the group and push some of the solutions you like. It’s not
your job. Your job is to help the group come up with improvement ideas to experiment on.
• You can use story telling, walking through the board and telling the story of what happened,
to trigger new trends of thoughts and even proceed with a second round afterwards.
• This activity spans both the 2nd stage and 3rd stage of a standard 5 stages retrospective⁴⁶,
respectively Gather data and Generate insights.
• The four elements from the incremental notation described above - Facts -> Feelings -
> Learnings -> Improvements - are quite close to the four components of Non Violent
Communication⁴⁷ - Observation -> Feelings -> Needs -> Request. You could actually use these
instead.

Authors, attribution and citations

• Alberto Brandolini, for inventing EventStorming and for his book⁴⁸
• All the people who attended the first EventStorming Summit in Bologna in 2018 and who
participated to the retrospective that was run at the end, using EventStorming of course.
• All the participants of #play14⁴⁹ and especially Luxembourg 2019⁵⁰, Madrid 2019⁵¹ and Kuala
Lumpur 2019⁵² where the retrospective of the event was run using EventStorming.
• Cédric Pontet(@cpontet⁵³) - Author of this article.

⁴⁶https://pragprog.com/book/dlret/agile-retrospectives
⁴⁷https://en.wikipedia.org/wiki/Nonviolent_Communication
⁴⁸https://leanpub.com/introducing_eventstorming
⁴⁹https://play14.org
⁵⁰https://play14.org/events/luxembourg/2019-03
⁵¹https://play14.org/events/madrid/2019-05
⁵²https://play14.org/events/kuala-lumpur/2019-10
⁵³https://twitter.com/cpontet
Visual Collaboration Tools 66

Example Mapping

What is made possible

Before you pull a user story into development, it’s crucial to have a conversation to clarify and
confirm the acceptance criteria.
Example Mapping is a simple but powerful tool. It can frame the conversations that help your team
to build a shared understanding about what you are trying to build.

How to use it
Concrete examples are a tremendous way to help us explore the problem domain, and they make a
great basis for our acceptance tests. But as we discuss these examples, there are other things coming
out in the conversation that deserve to be captured too:

• Rules that summarise a bunch of examples, or express other agreed constraints about the scope
of the story.
• Questions about scenarios where nobody in the conversations knows what the right outcome
is. Or assumptions we’re making in order to progress.
• New user stories we discovered or sliced and deferred out of scope.

Example Mapping uses a pack of 4-coloured index cards and some pens to capture these different
types of information as the conversation unfolds. As we talk, we capture them on index cards, and
arrange them in a map on a table.
Visual Collaboration Tools 67

Pack of 4-coloured index cards

Visual Collaboration Tools 68

The structure of an Example Map.

The workshop

1. Pick a story. It doesn’t really matter what it is, except if you have “technical stories” they might
not work as well. But pick one. Don’t try to do too much.
2. Give yourselves a time limit, and at the end have the team thumb vote on whether you think
the story is ready. Twenty-five minutes is a good amount of time. If you get “no” at the end try
to schedule another session once the questions and concerns have been answered
3. Don’t invite everyone. It might give you too much conversation. The sweet spot for me is 3 to
5 people covering at least the development, test and product perspectives. You can always run
a second session on another story so other people can give Example Mapping a try.
4. Have someone take on a facilitation role. Their job is to look out for conversations that are
sweating the details too much. If no one in the room can answer a question— add a pink
question card. If the conversation is drifting out of scope — take note of a new story on a yellow
card. Eventually the team will do this naturally, but having someone specifically watching for
it can really help at first.
5. Don’t use Gherkin for the examples. Try drawing simple pictures or a simple notation that
works well for your stories. We want the session to focus on discovery, moving to a formal
language too early can stifle the flow of ideas.
Visual Collaboration Tools 69

6. Have the person who came to the meeting with the least understanding of the story write up
the “minutes” of the meeting as Gherkin scenarios and share back to check understanding.
Even better do it as a pair.
7. Do a mini retro at the end and talk about what went well, what didn’t and adjust for next time.

Why?
Example Mapping helps you zoom in and focus on the smallest pieces of behaviour inside your story.
By mapping it out you can tease apart the rules, find the core of the behaviour you want, and defer
the rest until later. With this level of scrutiny, example mapping acts like a filter, preventing big
fat stories from getting into your sprint and exploding with last-minute surprises three days before
demo-day.

Tips and Traps

• A small group of amigos should be able to map out a well-understood, well-sized story in about
25 minutes.
• The bare minimum is your three amigos: a developer, a tester and a product person. That’s just
a minimum though. By all means invite your operations, user experience people or whoever
else is relevant to the story being discussed.
• Instead of going for full-blown formal Gherkin scenarios, just try to capture a list of rough
examples, using the friends episode naming convention.
• Instead of letting everyone share their opinion about what they think the outcome should be,
simply capture the question and move on.

The one where….

Visual Collaboration Tools 70

Authors, attribution and citations

By Matt Wynne & Steve Tooke, credits blog post:

• Example Mapping Introduction⁵⁴

• Your fist Example Mapping session⁵⁵

Kenny Baas-Schwegler (@kenny_baas⁵⁶) - contributed this article.

⁵⁴https://cucumber.io/blog/bdd/example-mapping-introduction/
⁵⁵https://cucumber.io/blog/bdd/your-first-example-mapping-session/
⁵⁶https://twitter.com/kenny_baas
Visual Collaboration Tools 71

Impact Mapping
An impact map is a visualisation of how deliverable scope relates to business goals for a milestone
of a project or a product delivery. Usually, it is presented as a mind map, or some similar visual
hierarchy. Senior technical and business stakeholders typically create an impact map together at the
start of a product milestone, to visualise assumptions, set priorities and discuss delivery options.
An impact map structure contains the following four levels:

Goal
The first level (centre) of an impact map answers the most important question: Why are we
doing this? This is the goal we are trying to achieve.
Actors
The second level of an impact map provides answers to the following questions: Who can
produce the desired effect? Who can obstruct it? Who are the consumers or users of our
product? Who will be impacted by it? These are the actors who can influence the outcome.
Impacts
The third level of an impact map sets the actors in the perspective of our business goal. It
answers the following questions: How should our actors’ behaviour change? How can they
help us to achieve the goal? How can they obstruct or prevent us from succeeding? These are
the impacts that we’re trying to create.
Deliverables
The fourth branch level of an impact map answers the following question: What can we do, as
an organisation or a delivery team, to support the required impacts? These are the deliverables,
software features and organisational activities.
Visual Collaboration Tools 72

An example impact map

What is made possible

Organising a group of stories as an impact map facilitates several levels of decision-making and
prioritisation discussions. A map has a single central idea, so the stakeholder group first has to
pick one big business goal for a delivery. This significantly helps with prioritisation and eliminating
unnecessary scope, which speeds up delivery.
Impact maps also facilitate many good product management techniques. For example, because
deliverables are grouped under related impacts, impact maps provide a way for stakeholders to
pick and prioritise on a higher level, deciding on user impacts before prioritising individual work
tasks. This keeps the focus on objectives, and promotes the idea that deliverables are options which
may (or may not) help to achieve the intermediate impacts.
An impact map puts all the deliverables in the context of the impacts that they are supposed to
support. This allows stakeholders to compare deliverables and avoid over-investing in less important
areas of a system. It also helps to throw out deliverables that do not really contribute to any impact
that is critical for a particular goal. Finally, by connecting deliverables to impacts and goals, an
impact map shows the chain of reasoning that led to a feature suggestion. This allows product
Visual Collaboration Tools 73

managers to scrutinise those decisions better and re-evaluate them as new information becomes
available through delivery.
By clearly communicating assumptions, an impact map helps teams align their activities with
overall business objectives and make better roadmap decisions. When a deliverable is on the map,
a stakeholder has an assumption that it may achieve the desired impact on customers. When an
impact is on the map, a stakeholder has an assumption that the change in customer behaviour
will lead to the overall business objective. This allows teams to design tests to validate or disprove
assumptions, supporting better product management. In addition, higher levels of an impact map
effectively become acceptance criteria for lower-level elements, helping to reduce unnecessary work.
For example, once an impact is achieved, the remaining deliverables in that part of the hierarchy
can be discarded from the plan, and the team can move on to delivering the next most important
impact.

How to use it
When you are describing the goal of a milestone – the first level of the map – focus on the problem
to be solved, not the solution. Avoid design constraints as much as possible. “Creating an iPhone
app” is not a good goal, “improving mobile advertising revenue” is.
When you are describing the actors – the second level – think about who can impact the outcome,
positively or negatively. There are often three types of actors to consider:

• Primary actors whose needs are fulfilled (for example players with mobile devices)
• Secondary actors who provide services facilitating the fulfilment of the needs of primary actors
(such as the fraud prevention team)
• Off-stage actors who have an interest but don’t directly benefit or provide the service (for
example regulators or senior decision-makers)

To describe the impacts – the third level of the map – think about behaviour changes you are trying to
influence. Impacts are not product features. For example, “better mobile search” isn’t an impact, but
a deliverable. “Finding information faster” is a good behaviour change to describe instead. Thinking
about impacts in this way opens up many options for delivery.
When you get to the fourth level of the map, capture user stories, epics, tasks, product ideas – all
the deliverables that could potentially cause a positive impact or prevent a negative one. Then treat
them as options, not as commitments.

Why?
Impact maps have three primary advantages over alternative techniques – they are visual, col-
laborative, and simple. The simple four-level structure is easy to explain and remember, so the
group creating an impact map can focus on sharing knowledge rather than the syntax of boxes
Visual Collaboration Tools 74

or arrows needed to capture information using some other techniques. Visualising the connection
between goals and deliverables helps stakeholders to align plans and priorities speedily. The simple
format and visual nature of impact maps invites collaboration and alignment, facilitating the work
of decision-makers to discover and set common goals for delivery.

Authors, attribution and citations

Impact Mapping was invented by Ingrid Domingues (Ottersten) from inUse, an interaction design
agency based in Sweden.
For more information, check out the books Impact Mapping⁵⁷ by Gojko Adzic and Effect Managing
IT⁵⁸ by Mijo Balic and Ingrid Domingues (Ottersten). Also, you can find lots of introductory
community resources and ideas for applying impact mapping and combining with other techniques
at impactmapping.org⁵⁹.

⁵⁷https://gojko.net/books/impact-mapping/
⁵⁸http://www.amazon.com/gp/product/8763001764/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=8763001764&
linkCode=as2&tag=swingwiki-20
⁵⁹https://impactmapping.org
Visual Collaboration Tools 75

Interactions Mapping

What is made possible

Individuals and interactions over processes and tools
-First value of the Manifesto for Agile Software Development⁶⁰

Ever started working with a team and realized that interactions between people within the team, or
between the team and other teams were unclear? Ever asked yourself Who is talking to whom? and
Why aren’t these people talking to each other?. Ever had a case where people where not involved
in conversations where they should have been, or maybe the wrong people were interacting? To
alleviate some of these issues, you should always start by visualizing things in order to build a
shared understanding of the interactions that are going on.
An Interactions Map is a very powerful tool that helps you figure out interactions between people
and teams. It helps visualize the exiting interactions, the ones that are missing, and sometimes the
ones that should be limited or even stopped.
Because an Interactions Map is a visual collaboration tool, it also helps everyone build and share
a common understanding of the interaction and communication structure around them, in a given
context.

How to use it

Preparing the workshop

For this workshop, you will need

• An empty wall where you can stick post-it notes

• Different colors and sizes of post-it notes
• Different colors of string
• Blu tack
• Post-it label roll

Because it is an alignment workshop as much as a discovery workshop, you should invite all the
team members to participate. If the interactions you want to map span more than one team, it is
safe to assume that inviting one or two key persons from each team is the best approach. In any
case, you need to invite the people who actually have a clue of what is really going on. This does
not necessarily mean a manager. Most of the time, we see that the people who are doing the job are
the best people to explain how they do it. Surprising, right!
⁶⁰http://agilemanifesto.org/
Visual Collaboration Tools 76

The workshop

What we want to achieve here is to map the interactions between people and teams. We want to
visualize who is interacting with whom, and through what means of interaction.

1. Start by figuring a color scheme. For example, all blue post-it notes are internal people. All
orange post-it notes are external people like consultants and partners.
2. Ask the participants to write down post-it notes with all the people involved first. You can even
ask them to draw people/stick-man/stick-woman on the post-it note. To avoid duplicates, each
time someone writes a name down, they should tell the rest of the group and stick the post-it
note on the wall. This should foster collaboration.
3. Once you have listed all the people involved, ask participants to move them on the map
according to the people they interact with. After a while, you should see clusters of people
appearing.
4. Name the cluster with post-it label. The cluster could be a team, a department, a service. It’s
up to you to define what level of granularity you are mapping.
5. Use smaller yellow post-it notes to symbolize important roles. Stick the post-it note on the
person who is assuming this role.
6. Use one color of string and blu tack to materialize existing interactions. A string could go from
one post-it note to another to materialize interactions between two people, or from one post-
it note to a label to materialize interactions between a person and a team, or between two
labels for interactions between teams. Try to focus on interactions that matter to your context,
otherwise you risk to end up with too many strings for anything to make sense anymore.
7. Optionally, use a different color of string to materialize interactions that should be reinforced,
started or stopped.
8. You can also give more information about the interaction by adding a post-it note on the string
itself, specifying the type of interaction and the processes and the tools that are used.

The following picture shows a possible outcome.

Interactions Map
Visual Collaboration Tools 77

In that picture, a:

• Blue post-it note implies an internal person

• Orange post-it note implies an external person
• Smaller yellow post-it note implies a role
• Yellow label implies a team or group of people
• Green post-it note implies an interaction means, a process or a tool

It does not show very well on the picture, but some of the string have different colors and represent
interactions that should be kept or some that should be either started or reinforced.

Why?

Purposes

Visualizing interactions between people and/or teams, as well as the means of interactions that are
being used, help us make sense of complexity and build a common understanding of what is going
on.
Mapping interactions may help you spot some dysfunctional interactions, interactions that are not
at the right level for example, between individuals instead of at the team level, or only between
team managers instead of involving the whole team. There is no right model of interaction and the
best way for people and teams to interact is highly dependant on the context. However, visualizing
things helps us to analyze and reflect.
It also allows identifying possible improvements or opportunities for coaching, to help make
interactions more efficient.
Here are the main benefits of an Interactions Map:

• Obtain a shared understanding of what is really going on

• Visualize interactions between people and/or teams
• Specify interactions means that are being used
• Identify interactions that should be kept, reinforced, started or stopped
• Identify dysfunctional interactions
• Identify opportunities for coaching

Tips and Traps

• Proximity or distance are meaningful. Don’t hesitate to move things around when need be.
One of the many advantages of using post-it notes is that they can be moved around and that
they can be easily thrown away and rewritten.
Visual Collaboration Tools 78

• Always know whether you are mapping the situation as is, or to be. Make sure everyone is on
the same page. Sometimes, do both. Start by mapping the situation as is, and then do a second
iteration to map the situation to be. This exercise may end up providing a lot of insights. Just
don’t forget to take a picture in between.
• As mentioned above, you can use different colors of string to qualify the interactions. For
example, interactions that should be kept, reinforced, started or stopped. But colors could
represent some other characteristic like the level of interactions - strategic tactical and
operational - or the type of interactions - leadership, execution, reporting - or the means of
interactions - informal, face-to-face, meeting, backlog management tool, IM, email, phone, …
• In the example above, we used smaller yellow post-it notes to represent roles. Based on the
Interactions Map, we could go further and run a Roles and Responsibilities workshop, where
we collaboratively list all the responsibilities that need to be addressed, group them into roles,
and then let people assign themselves to the roles that have been co-constructed. It is a very
powerful workshop to run when you realize that responsibilities are not precisely identified,
that too many people share the same responsibility or that some responsibility simply does not
belong to anyone. A nice side effect of co-constructing a vision with all the people involved is
that on the one hand we obtain better alignment and shared understanding, and on the orther
hand we get better adhesion to the shared model.
• Different colors of post-it notes can be used to differentiate people. In the picture above, internal
and external people are respectively represented by blue and orange post-it notes. Depending
on what you want to explore, you can use any kind of color-coding. Whatever makes sense
in your context, you could have colors that represent things like services/departments in the
organization, hierarchical levels, or even roles.
• You can give more information about the interactions by using a specific color or shape of
post-it notes that you stick directly on the strings. In the example above, we used green to
specify the type of interactions, the processes in place and the tools being used. But it could be
anything that makes sense in your context.
• Don’t be too formal on the notation. Be creative. But make sure that the semantic of a symbol
on the map - post-it note, label, string, color - is clear for everyone and consistently used.
Therefore, it is recommended to use a visual legend next to the map, where you keep track of
all the notation.
• A possible extension of this workshop would be to use Team Topologies⁶¹ to clarify the types of
teams (stream-aligned, enabling, complicated sub-system, platform) and their interaction mode
(collaboration, X-as-a-service, facilitating). This has not been tested yet, but there is certainly
an untapped potential here.

Authors, attribution and citations

• All the members of the coaching team at Agile Partner⁶² with whom we have collaboratively
perfected our approach over the years and refined our workshops, by running them over and
⁶¹https://teamtopologies.com/
⁶²https://www.agilepartner.net/en/home/
Visual Collaboration Tools 79

over with different teams and customers. Interactions Map is one of the workshop formats that
we came up with.
• Cédric Pontet(@cpontet⁶³) - Author of this article.

⁶³https://twitter.com/cpontet
Visual Collaboration Tools 80

Mikado Method

What is made possible

The Mikado Method is a structured way to make significant changes to complex code source⁶⁴.
For small refactorings, a software engineer can keep the graph of changes in his mind, but often in
complicated and complex systems, it is a hard thing to do. On top of that, the Mikado Method allows
team members to collaborate to create a solution that fits the team.
The Mikado Method produces a graph, with the goal as the centre of the graph. The nodes are the
changes that are needed to be done to achieve the goal.
⁶⁴http://www.methodsandtools.com/archive/mikado.php
Visual Collaboration Tools 81

Example of a Mikado Method graph. Credits to Ola Ellnestam and Daniel Brolund

How to use it
To start with the method, write the goal in a paper, circle it twice. Then try it in code. It is expected
that the code will break, where it will not compile or transpile; some reference will be broken or a
test will fail. Based on the number of failures discovered, create new nodes from the initial one.
Revert the changes that you applied. It is an important step! Don’t be afraid of using your Version
Source Control system. It is quicker to apply the changes in a naïve fashion, without overthinking
it.
Visual Collaboration Tools 82

After you revert the changes, move to a node with leaves. Apply the same concept: do a change and
examine what breaks. As described before, note the code failures as new nodes and revert. Do these
steps until you do have failures in code.
From that point on, start from the outermost leaves, applying the changes. In this way, you don’t
have surprises!

Why?
Using this method allows the teams to discover paths where a change can break code; it is useful
as a method to do as a team, given that the team find at the same time the knowledge. Also, for
changes that can span days (raise the hand who said that is a 5-minute change, and past two days
they still were doing it), it is a great way to persist and share the knowledge.
Given the technology changes in the software domain, refactoring is a fact of any software
engineering team. This method helps the team to decreases the time to apply changes, given that
it is possible to visualise the impact of a single goal. Also, the team doesn’t need to implement all
changes in one go, allowing them to do it in small batches.

Tips and Traps

• The Mikado Method is a great way to share knowledge among team members. It can be done
in a pair or mob setting
• Teams that are refactoring applications have a method that helps to persist the refactoring
paths, visualising the complexity involved. It gives insights on the effort involved
• Timebox the activity. It allows teams to get focus on the tasks
• Don’t be dogmatic on the way that the Mikado graph is persisted
• Avoid reverting changes, with the fear of losing work
• Don’t record all the nodes in the graph. If someone interrupts the activity, the mental map is
lost

Authors, attribution and citations

The method was created by Ola Ellnestam⁶⁵ and Daniel Brolund⁶⁶ and published in the book⁶⁷ with
the same title.
This article was written by João Rosa⁶⁸. He is a Strategic Software Delivery Consultant at Xebia,
specialised into helping companies to leverage the power of technology to drive their business.

⁶⁵https://twitter.com/ellnestam
⁶⁶https://twitter.com/danielbrolund
⁶⁷https://www.manning.com/books/the-mikado-method
⁶⁸https://twitter.com/joaoasrosa
Visual Collaboration Tools 83

Quality Storming

What is made possible

In various communities, several methods for the collaborative modeling of business requirements
have been established in recent years. Well-known examples are EventStorming or Domain
Storytelling. These approaches are based on achieving a better shared understanding of the business
requirements in an interdisciplinary way. But what about the requirements for the quality of the
software being developed? Especially here, a collaborative approach is immensely important in order
to avoid chasing after imperfect ideals that cause the costs and complexity of products to explode.
This is where the workshop format Quality Storming comes in, which I would like to introduce in
the course of this article.

It depends! On what?

In our daily work we repeatedly experience situations in which teams passionately discuss the
advantages and disadvantages of specific solution options. Popular in these discussions are technical
topics, such as HTTP Feeds vs. Apache Kafka. However, such arguments are also becoming more and
more common when it comes to slice the software functionally. A popular answer to the question
“which solution is the best” is then often “it depends”. This answer indicates that we are dealing
with a decision that implies a trade-off. The second question, “on what?” is therefore automatically
asked. Possible factors may involve:

• Functional requirements
• Regulatory requirements
• The environment of a product or project
• Requirements on the quality of a software product

The first three drivers for such decisions are taken more or less seriously in most organizations.
With the last point, however, I regularly find that most teams lack resilient requirements. Most
of the time, these are so vaguely defined that they cannot be used as a basis for decision-making.
Typical examples are “the system must be scalable”, “all common browsers must be supported” or
“all input must be immediately visible everywhere at all times”. It goes without saying that over
the course of time, best practices have established themselves that make suggestions as to how the
requirements for the quality of a software product should ideally be documented. An example of
this is the formulation in the form of quality scenarios, which are also used in the ATAM process
(Architecture Tradeoff Analysis Method) [^ATAM] for the evaluation of software architectures.
There are two steps in the ATAM process that address the definition of quality requirements for a
software architecture: “5. Generate quality attribute utility tree” and “7. Brainstorm and prioritize
scenarios”. This raises the question of how we, as a team, can get to these requirements. At this
point, there are always similar challenges in many organizations:
Visual Collaboration Tools 84

• There are too rigid silos between individual stakeholders (development, operations, depart-
ments, testing, …), which make collaboration difficult or even impossible.
• Especially domain experts often find it difficult to define quality requirements in a way that
development can work with them.
• There is little insight into the work and challenges of the respective other groups of people.
• Rigid silos mean that there are very stringent documentation requirements for the handoff
between the individual departments.

As a result, the quality requirements are too superficial and are primarily used to fulfill internal
governance checklists. Software architects and developers can rarely make real design decisions on
this basis.
Therefore, the following quote from Alberto Brandolini is also fully correct with regard to quality
requirements:

it is not the domain expert’s knowledge that goes into production, it is the developer’s
assumption of that knowledge that goes into production

• Alberto Brandolini

The quote just mentioned was not chosen at random. Alberto Brandolini is the inventor of a
collaborative modeling method called EventStorming, which has caused quite a stir in the Domain-
driven Design community and is now known far beyond that community. EventStorming, like most
methods in the field of Collaborative Modeling, is based on the following principles:

• Complete abandonment of digital modeling tools on computers

• Avoiding any entry barriers for all participants
• A high degree of interactivity
• The focus is on the mutual exchange and less on the production of formal artifacts.

This is where Quality Storming comes in, trying to bring together a heterogeneous set of stakeholders
of a product or project to collect quality requirements. The goal is to gain a shared understanding
of the real needs for the quality characteristics of a product. To achieve this goal, Quality Storming
uses some techniques from the highly acclaimed book “Game Storming” by Dave Gray, which also
had a significant impact on EventStorming.
It is not the claim to produce perfectly formulated quality scenarios with the help of Quality
Storming. Instead, the method aims to create a well-founded, prioritized basis for later formalization,
which is understood across different stakeholder groups. The more often teams work with the
technique, the better the quality of this basis becomes over time. Advanced teams are quite capable
of creating very well-formulated scenarios within the framework of such a workshop.
Visual Collaboration Tools 85

How to use it
As with many other methods in the field of Collaborative Modeling, a solid preparation is an
important success factor for the actual workshop. Make sure to take the following aspects into
account:

• Selection of the participants

• Invitation and management of expectations
• Selection of a quality model
• Room equipment, moderation material and short documentation of the selected quality model
• Room selection
• Preparation of the room before the workshop

The most important thing is undoubtedly the selection of the participants. We must select a
heterogeneous and diverse group of people. All relevant stakeholders of a product or project should
be present in order to get a holistic opinion and, above all, to achieve commitment for the results.
Nothing would be more unfortunate than an influential group not participating and calling the
overall result into question after one week. When selecting the circle of participants, think for
example of the following groups of people:

• Domain experts
• User Experience (UX) specialists
• Software developers and architects
• Project sponsors and management
• Testers
• Requirements engineers
• Folks from the ops departments
• Specialists for accessibility
• End users

Experience has shown that 16 or 24 people are ideal, especially when working with the widely used
ISO/IEC 25010 quality model. I will leave a few comments on quality models further below.
When inviting the participants, it is vital to make sure that no false expectations are stirred up. It is
important to emphasize that at the end of the workshop, there is a binding commitment to the quality
requirements. The recipients of the invitation should understand that based on the results of the
workshop, design decisions will be made in the areas of software development and architecture, user
experience, and operations. However, the impression should not be given that a perfectly formulated
document or a formally perfect quality tree is the result of a Quality Storming. The creation of such
artifacts is done afterward, as needed. Make sure that the participants in the workshop are present for
about 4 to 6 hours. The invited persons should plan the time exclusively for attendance. A telephone
conference or a meeting in between is counterproductive and disturbs the process unnecessarily.
Visual Collaboration Tools 86

Already during the preparation, the organizer of a Quality Storming should think about the selection
of a quality model. A quality model can be described as a rough outline for a quality tree. The latter
can quickly be recorded in the form of a mind map.
In some companies, such a model for the description of software quality requirements already exists.
In this case, it is an excellent starting point, and it is recommended to start with it. Fortunately, if
no quality model exists yet, there is no need to come up with one of your own, because there is a
standardized proposal for a quality model in the ISO/IEC 25010 standard.

ISO/IEC 25010 as a quality model

ISO/IEC 25010 provides a total of eight main categories. As shown in Figure 2, these categories, in
turn, have subcategories.
The choice of the quality model is essential because it will have an impact on the number of
participants. I always prefer the following formula for determining the perfect amount of people:
quantity of the quality model’s top categories x 2 or 3. In the case of ISO/IEC 25010, we would be at
16 or 24 people, both figures I mentioned earlier regarding this paragraph.
For the room selection, I strongly recommend to prefer rooms that have either no tables or movable
tables. Traditional meeting rooms with wired tables are counterproductive. The room has to be large
enough for the number of participants plus 1-2 facilitators as determined earlier, and should still
offer enough freedom of movement for the participants when placing two flipcharts and up to eight
movable pinboards. If there are not enough movable pinboards available, the room should have two
free long walls on which plotter paper can be attached.
The last preliminary measure is the organization of the room equipment, the moderation material,
and the rough documentation of the quality model. Ideally, the room should be equipped as
follows:
Visual Collaboration Tools 87

• One movable pinboard per top category of the quality model, covered with paper on both sides.
In the case of ISO/IEC 25010, this would be eight pinboards.
• If not enough pinboards are available, which is not uncommon, strips of plotter paper should
be attached to the walls of the room for each major category of the quality model.
• Two flipcharts.
• A pair of stand-up tables.

The following list moderation material is useful for a good Quality Storming workshop:

• Numerous, square and above all high-quality sticky notes in a uniform color.
• For each person in the room an identical black pen (e.g. Edding 1300 or Sharpies) and a few
spare pens.
• Per participant about 20-30 small sticky dots.

Finally, I recommend the preparation of signs for the main and subcategories of the underlying
quality model. I like to use DIN A4 for the top categories and DIN A5 for the subcategories. Each
sign contains the name of the category in large, easily readable letters and a short description of
the respective category. When describing the categories, please make sure that you use words that
really every person in the room can understand. I also recommend the wording of a few simple
examples for the respective categories. A comprehensive collection of such samples can be found in
a subproject of arc42 on GitHub⁶⁹.
Shortly before the actual workshop, you need to setup the room. Each of the top categories of the
quality model gets its own pinboard. Prepare this as follows:
⁶⁹https://github.com/arc42/quality-requirements
Visual Collaboration Tools 88

Preparation of a pinboard for a main category of the quality model

Visual Collaboration Tools 89

Place the sign for the main category of the quality model at the top of the pinboard and line up
the signs for subcategories vertically downwards on the left side. Especially with the subcategories
it is advisable to pay attention to good descriptions. Furthermore, I recommend placing one or
two examples of quality requirements or scenarios for each subcategory, especially during the first
sessions of a Quality Storming workshop. The colors used in figure 3 are not to be understood as
binding color codes.
Afterward, the mobile pinboards are placed evenly in the room. Please make sure that up to six
people can stand and discuss on the pinboards. In addition, place two flipcharts and ideally stand-
up tables with moderation material in the middle of the room. The room setup should look something
like the following picture:
Visual Collaboration Tools 90
Visual Collaboration Tools 91

Running the actual workshop

Once the room is prepared, the workshop can begin. A Quality Storming consists of the following
phases:

1. Introduction
2. Broad Collection
3. Consolidation
4. Prioritization
5. Outlook

Phase 1: Introduction

This phase can usually be very short and should not take longer than 10 - 15 minutes. It is essential
that the workshop facilitator briefly outlines the motivation and the approximate procedure. As a
rule, I also briefly present the underlying quality model and provide a few practical examples of
possible quality requirements. Especially teams that are conducting a Quality Storming for the first
time will benefit immensely from the above-mentioned presentation and examples. As a facilitator,
make sure that the participants have a rough idea of how to formulate quality requirements and
which aspects have to be considered. You should also briefly present a code of conduct. In this
context, I refer, for example, to desired and undesirable behavior.
As a facilitator, make sure that you have addressed the following points:

• Rough procedure including breaks

• Presentation of the quality model including examples
• Code of conduct

Phase 2: Broad collection

After the introduction, the first team building for the initial collection of quality requirements takes
place. Depending on the number of participants and the number of main categories of the quality
model, groups of 2 or 3 should be formed. Please make sure that the persons in the individual
teams belong to different stakeholder groups. Avoid, for example, that two software developers
join together to form a team. The teams will eventually be divided up in such a way that there is a
heterogeneous group of two or three people on each pinboard.
After the team building, we start the collection of quality requirements. Each team stands at a
pinboard that represents a top category of the quality model. The first step is to collect requirements
for this category. The teams collect ideas, write them on the sticky notes provided and stick them
on the pinboard to the respective subcategories.
Visual Collaboration Tools 92

Collection of requirements in phase 2

Visual Collaboration Tools 93

After ten minutes, it is time for the groups of two or three to change the main category of the
quality model and thus also the pinboard. After the change, the requirements are collected again for
ten minutes, written on sticky notes and stuck to the pinboard. We repeat this process until it was the
turn of each group. This ensures that every person present had the opportunity to make requests for
each of the main categories. Furthermore, a large number of possible requirements can be collected
in this way. The facilitators of the workshop should also emphasize several times that it is absolutely
ok to have conflicting requirements for the quality of the software. In this early phase, we want to
explicitly document different views. In order to reach a consensus, it is crucial to understand where
different opinions differ and to what extent.
The following picture shows the rotation model of the second phase:
Visual Collaboration Tools 94
Visual Collaboration Tools 95

At the end of the second phase, all participants deserve an extensive (20 - 30 minutes) break. The
workshop should have lasted about two hours now. During the break, the facilitators prepare the
third phase.

Phase 3: Consolidation

The just mentioned preparation of the third phase consists of the identification of double or
competing quality criteria. Exact duplicates are removed from the pinboards by the facilitators and
put aside or stuck to the frame of the respective pinboard. Group competing quality criteria together.
A competing criterion is understood to mean different requirements for the identical subject matter.
Here is an example:

• Group 1: 300 mortgage lending value calculations per hour

• Group 2: 50 mortgage lending value calculations per hour
• Group 3: 2 mortgage lending value calculations per minute between 09:00 and 18:00

All these requirements relate to the identical facts, the required number of calculations of the
mortgage lending value of a property. However, the quantity differs. All these sticky notes are
grouped as follows:

Transition from phase 2 to phase 3

When the participants come back from the break, new groups are formed, which are larger. Ideally,
the new teams should consist of four to six people. Here, too, as with group formation in phase 2,
care should be taken to create teams that are as heterogeneous as possible in terms of stakeholders.
With eight pinboards for the top categories of the quality model, for example, four groups are ideal.
Visual Collaboration Tools 96

After the group formation, the actual consolidation of the quality requirements identified so far and
grouped by the facilitators takes place. Each group of four or six persons then positions itself at a
pinboard and discusses the grouped, competing requirements with the aim of finding a decision or
a compromise. This can be a requirement that is already stuck to the wall or an agreement between
the existing requirements. In any case, it is recommended to mark the decision made. This can be
done, for example, by a new sticky note in a different colour or by marking with another, smaller
Post-It.
Visual Collaboration Tools 97

Selection of quality requirements in phase 3

Visual Collaboration Tools 98

Experience shows that each group needs about 15 - 20 minutes to consolidate the results. After
this time, each team moves on to the next pinboard and starts consolidating from the beginning.
Usually, it is sufficient if each pinboard has been visited and processed by only one consolidation
group. However, heated discussions can arise during consolidation in individual groups. At this
point, there are several possibilities for conflict resolution:

1. Mark several sticky notes as potential candidates with regard to quality requirements and,
at the end of phase 3, have them voted on in the entire plenum by majority vote. This is
undoubtedly the fastest and most time-saving option, but there is a risk that legitimate concerns
may be overlooked by individuals.
2. The second option is to allow other groups to look at the pinboards with divergent opinions.
This is a variant that takes more views into account but can prolong the workshop.
3. The third option is primarily used when one of the other two options does not produce a
result: mark the relevant area as “we need more information” and date the decision backward.
Experience shows, however, that this option opens the door to political stalling tactics after
some time and should, therefore, be used with caution.
4. As an alternative to the third option, it is far better to go out with a hypothesis from the
workshop and then verify it with appropriate metrics. At this point, I always like to define the
metrics that need to be captured in order to make a better decision later.
Visual Collaboration Tools 99
Visual Collaboration Tools 100

Phase 4: Prioritization

In the preceding phases, numerous requirements for the quality of software were collected. However,
when making architectural decisions, there is often the possibility that these must be weighed up
between different quality requirements. Thus, an architecture decision can have a positive effect
on certain quality requirements, but on the other hand, it can also have a negative effect on other
quality requirements. Prioritization of requirements gives software architects and developers a more
solid basis for their decisions. This prioritization is the last step in the actual quality storming.
Before prioritization is carried out, the quality requirements sorted out in the consolidation can be
put to the side. In this phase, only the requirements marked in phase 3 count.
Dot voting has proven to be a suitable method for carrying out prioritization: Depending on the
number of collected quality requirements, each participant in the Quality Storming workshop
receives a certain amount of small sticky dots. The amount of sticky dots handed out per person
should be about 15 - 25% of the consolidated quality requirements. Afterward, the workshop
participants are asked to mark their most important requirements with the help of the sticky dots.
As a rule, a person should only stick one dot on a sticky note marked in the consolidation. Another
option would be to allow participants to stick up to two dots on requirements that are particularly
important to them.
Visual Collaboration Tools 101

Dot-voting for prioritizing the requirements in phase 4

Visual Collaboration Tools 102

By the end of the fourth phase, we have gathered a significant number of prioritized quality criteria.

Phase 5: Outlook

The last phase, the outlook, is primarily a summary of the results obtained. It is always advisable
to remind the participants that they now have a lot of requirements that have been collected
and discussed across all stakeholders. Most people probably enjoyed the workshop, as well. Now
the facilitators and the technical participants have to give a short outlook on how the results of
the workshop will be used in the future. In addition, they should also briefly point out which
tangible artifacts will be created in the follow-up work based on the workshop results and where
the participants can find them.

Follow-up work

In principle, it is recommended that the results obtained be transferred to architectural documenta-

tion. Possible options are:

• Transfer towards a quality tree in mind map form

• Transfer towards the corresponding chapters of the arc42 [^ARC42] architecture documenta-
tion
• Use as input for the formulation of formal quality scenarios in the style of https://github.com/arc42/quality-
requirements⁷⁰

Why?
Quality Storming enables teams to gather a big amount of quality requirements for the software
they are about to build. The advantage of the method lies in a collaborative modelling and a shared
understanding of these requirements between various stakeholders. Based on the collected and
prioritized quality requirements teams can:

• make better software design decisions

• include this knowledge when deciding for boundaries in their software
• derive proper testing scenarios
• improve their documentation
• more realistically assess the architecture they have built
⁷⁰https://github.com/arc42/quality-requirements
Visual Collaboration Tools 103

Authors, attribution and citations

ATAM: https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method⁷¹
Alberto Brandolini - Event Storming: https://leanpub.com/introducing_eventstorming⁷²
Game Storming: https://gamestorming.com/⁷³
ARC42: https://arc42.org⁷⁴
Examples for quality requirements and scenarios: https://github.com/arc42/quality-requirements⁷⁵

⁷¹https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method
⁷²https://leanpub.com/introducing_eventstorming
⁷³https://gamestorming.com/
⁷⁴https://arc42.org
⁷⁵https://github.com/arc42/quality-requirements
Visual Collaboration Tools 104

User Story Mapping

What is made possible

The best solutions come from collaboration between the people with the problems to solve
and the people who can solve them.
-Jeff Patton, “User Story Mapping: Discover the Whole Story, Build the Right Product.”

Are you in a company that is customer obsessed – or tries to be – and strives to create solutions that
focus on the user needs and desires? Maybe you even try to build those solutions together with the
customer and their users, involving them in the actual design by building incrementally using mock-
ups, pilots, and MVPs? You have probably wondered how on earth you can design and build a viable
systems portfolio in such a setting, avoiding the risk of throwing together unfinished components
with duct tape, strings, and paper clips, or maybe ending up creating overly complicated solutions
to cater for any future need. There is a lot of talk about evolutionary architecture, but how can we
tie that in with the customer needs? In order to build sustainable systems we need to know where
the early prototypes are taking us; we need to be able to see further ahead. In short, what can help
us do domain modelling in this highly agile world?
User story mapping is a practice that grew out of the agile community as a way of structuring the user
stories in a narrative as experienced by the end users of the application you are building, telling the
story from their perspective. The insights gained from this visualisation tool, be it product discovery,
domain knowledge, delivery planning, and team collaboration, will then be directly connected to
this focal point, the user experience.
User stories has become a common way of describing what the user wants in many agile approaches,
be it XP where it originated or in the prevalent Scrum framework. Even though it was never meant
as a new way of writing requirements, many teams still struggle with large, unstructured, and one-
dimensional product backlogs of stories written as a detailed wish-list like requirement documents
used to do. It is hard to get a good handle of this list, especially ordering and breaking it up in a good
way to maximise the outcome in a sustainable and consistent way. Mapping the stories to the user
journey, with all the activities and task performed, opens up a new dimension where it becomes a lot
easier to find what needs to be constructed together to make the application usable, split into viable
product increments. The design can then be done in an evolutionary manner, where each step can
potentially be put in front of users, shortening the essential feedback loop.
Visual Collaboration Tools 105

From backlog to story map.

A subtle and important effect of doing this mapping and working with it the whole way from
inception to software delivery is that the design is explicitly connected with the user interaction.
One can no longer just simply gather a long list of requirements from all relevant stakeholders.
Everything must be mapped to some user activity, forcing the designers to view everything from the
user’s vantage point. The user stories concept start making sense then, as it was originally intended;
it is about how it is used, not how it is written. Common patterns used for writing stories, like “as a
<user> I want to <need> so that <goal>”, do not feel that contrived anymore; it becomes explicit in
the story map structure.

The User Story Template.

Visual Collaboration Tools 106

Story mapping is well-suited as a collaborative tool for all stakeholders in the design process,
all the way from the initial ideation and inception, creating coherent customer journeys, via the
construction phase, to the continuous enrichment and maintenance of the product after the initial
deliveries. It covers all three “-ilities” of a product: usable, valuable, and feasible. It makes sense for
service designers as it cover large parts of the customer journey and experience (CX and UX); it is
great for product discovery, making it easy for product managers to describe the intent and purpose
of the product; and it is a great way for technical designers to do domain modelling, creating feasible
solutions by bridging the gap between the the problem and solution space.

The Triad.

When modelling and designing technical solutions, the complexity of the problem space is all too
often not captured well enough, leading to naive designs based on existing technical solutions or
reuse of previous experiences by the architects and technical experts. The designs should instead be
driven by a deep understanding of the problem space, for which the story map is a good tool. It gives
the designers the necessary outside-in perspective, guided by the user’s mental model of the product
to be built. This, in addition to the evolutionary design championed by story mapping, enforces an
evolutionary approach to the technical design.

How to use it
As the inventor of the technique Jeff Patton says, story mapping is a “dead simple idea”. In essence it
is telling the story of a user’s experience of the application you are building by using short sentences
on a set of sticky notes placed on a timeline and grouped by the interactions the user has with it.

Preparing the workshop

There are often three distinct phases to story mapping, often split in separate sessions as it may
involve different people:
1. Product discovery: Involves the so-called triad, representing the “-ilities” mentioned above, which
often is a technical person (e.g dev, tech lead, architect, SME), an interaction designer (e.g. UX,
Visual Collaboration Tools 107

service designer), and a product manager representing the business. These three will also represent,
and maybe invite, other stakeholders in the company into the workshop.
2. Release strategy: This can be done as part of the product discovery phase, but is often done as a
different session as it may involve different stakeholders more concerned with company strategies
and customer relations.
3. Backlog refinement: This session will involve the whole team responsible for building the
product, including the the triad – the product team.
All these sessions should be run by an experienced facilitator and requires a lot of stickies, markers,
and wall space. As the map is something you would like to keep around for quite some time, it should
either be put somewhere it can be kept safe and in easy reach for the people involved, especially the
product team., or, if this is not possible, put it on a large strip of paper that can be moved easily.

The workshop

The outcome of the sessions is a bit different in each of the three phases described above, but the
mapping technique is the same, while at different levels of maturity and detail.

Product Discovery

The main goal of this session is to establishes the full user journey from start to end, constructing
the so-called “backbone” of the story map.

The Backbone.

Details can also be added here, starting forming some of the “ribs” hanging down from the backbone,
but the focus should be on covering the whole and postponing the detailing to the next phases. Focus
on the story telling, not the writing of user stories, and add stickies to the map with as little text as
possible, only enough to communicate and share the story.
Visual Collaboration Tools 108

The Backbone with Ribs.

For large products several sessions may be needed. The sessions are intense and draining, so split
the work up into smaller sessions rather than having a long one.

Release Strategy

The goal of this session is to split the product into different increments, one building on the other in
an evolutionary design manner, where each increment will provide the feedback needed for product
adjustments and maturing. The first increments could be a Minimum Viable Product (MVP) used to
verify the viability of the product; or it could be an early version that could be tested by a small set
of users; or it could even be as simple as a way for the developer to test some technology, “kicking
the tires”, so to speak.
Visual Collaboration Tools 109

Story Map with Increments.

Create as many increments as make sense, but take care of not locking in the steps too hard. One
can easily do with one increment at the time, having a “doing” and “todo” slice. Consider having an
explicit user goal for each increment, as that will help you making a slice that makes sense to the
user.

Backlog Refinment

This session is held as often as the product team wishes, like at the start of each sprint if Scrum is
used. The whole team participates here, or at least everybody involved in building the product,
like developers, testers, and POs. The goal is detailing the increment to be built, like slicing,
decomposing, and detailing the user stories to a level that suits the team, including identifying the
acceptance criteria used for testing and setting definition of done. The stories should now be ready
for implementation and this is where the user stories moves from describing a user need to becoming
a delivery artefact, e.g. the stories can be taken into the sprint backlog or a Kanban board.
Visual Collaboration Tools 110

Stories in a Kanban board.

Why?
When engineers think of “the customer” in the abstract instead of as a real person, you
rarely get the right outcomes.
-Gene Kim, “The Unicorn Project”

Although user story mapping is mainly a product discovery and development tool, it can also be
beneficial for domain modelling as it describes the problem space in a very clear and holistic way. It
enables us to create solutions that matches the user’s mental model if so inclined. No longer endless
and one-dimensional lists of user stories that makes it hard to see the wood for all the trees.

Purposes

The benefits of this practice can be summarised as follows:

• Makes writing user stories easier as they are discovered while creating the narrative, with the
user goals, activities, and tasks, forming a solid backbone to which the individual user stories
can be attached.
• Getting away from the one-dimensional backlog, mapping every story to the backbone that
forms the user narrative that defines the what, while the individual user stories can define
optional how.
• Splitting the delivery in iterations, based on user outcome.
• Designing the product on explicit user needs, using user roles and personas.
Visual Collaboration Tools 111

• Creating a full user journey, bridging the gap between business, UX, and software.
• Makes modelling the solution on the user’s mental model easier, e.g.:
– Identifying the ubiquitous language.
* Seeing what data needs to be shown together and saved together, help identifying bounded
contexts.
* Identifying data that needs to be transactionally bound and what can be eventually consistent.
* Finding aggregates, with its data and invariants.

Tips and Traps

• Understand what a user story is and what it is used for:

– Not a new way of writing requirements.
– Defines the user need.
– Can be used for delivery, attaching acceptance criteria.
• Make sure all participants are engaged and all voices are being heard:
– No distractions like computers and phones.
– Psychological safety.
– Have frequent breaks and keep the sessions short (2 hours is good).
– Have snacks and drinks.
• The sessions are intense so make sure the environment is optimal:
– Large and light room with good air quality.
– Remove chairs and tables; the maps get large quickly and working on a wall is most
practical.
• In order to avoid the phases above becoming hand-overs in a waterfall-like process, all the
participants should come from the same product team, including the triad in the initial phases.
They should obviously collaborate with all stakeholders, some which may be involved in
creating the map, but the core should be people from the product team.
• If your company is not organised as product teams, try to run the sessions as if you where.
• Limit the number of participants, especially for the discovery phases; 3-5 seems to work best.
• Start by building the overall user journey in a timeline before detailing and structuring it in
goals, activities, tasks, and options.
• Consider using a storming approach initially, where everybody is writing stories on their own
first and you all go through them afterwards and build a narrative you all agree on. This also
help getting everybody engaged and heard.
• The user goal is not part of the original story mapping as described by Jeff Patton, but used
properly it makes it easier to understand the user need and enables having different solutions
to the same user goal.
• When defining the increments, start with a specific goal for each step. This makes it easier to
limit its scope and avoid creating increments that does not give any feedback and outcome, like
testing options on some users (A/B testing) and checking the feasibility of a technical solution.
Visual Collaboration Tools 112

Authors, attribution and citations

• User Story Mapping was developed by Jeff Patton in 2004 and described in detail in his book
from 2014 User Story Mapping: Discover the Whole Story, Build the Right Product⁷⁶
• Jeff Patton and jpattonassociates.com⁷⁷
• Experiences by Trond Hjorteland⁷⁸ (scienta.no⁷⁹) at a diverse set of clients, both public and
commercial.

⁷⁶https://www.jpattonassociates.com/jeff-pattons-book-released-user-story-mapping/
⁷⁷https://www.jpattonassociates.com/user-story-mapping/
⁷⁸https://www.linkedin.com/in/trondhjort/
⁷⁹https://www.scienta.no/
Visual Collaboration Tools 113

The Wall of Technical Debt

Mathias Verraes

Why
“Technical debt” is a metaphor for all software design choices that turn out to be suboptimal, no
longer valid, or just plain wrong. They incur a cost on future development. The shortcuts taken
today will later slow you down, until you “pay back” the debt by fixing the problems. And it’s not
just code: artifacts like architecture, documentation, tests, and domain models, can all suffer from
technical debt.
Technical debt can severely drag down development. And paying back all debt by replacing all
software, isn’t usually very feasible either. But, like financial debt, technical debt is not always a
bad thing. Debt allows us to invest in something before it makes money. Taking shortcuts when
bringing a product to market, allows us to test a business model cheaply, and makes it easier to
throw away the code if it turns out to be a bad idea. And often, the debt exists because the business
has grown and evolved, and the design choices that were valid early on, are not anymore.
The problem isn’t technical debt, it’s unmanaged technical debt. In any company, the CFO knows
exactly how much financial debt there is. There are spreadsheets, quarterly reports, payment plans,
and options to refinance or sell debt. But ask your CTO how much technical debt your organisation
has, and you’ll get an awkward “uh… a lot?” as an answer.
The Wall of Technical Debt is a surface in your office where you visualize these issues on sticky
notes. It’s easy to start and to maintain, and yet has a profound impact on how we choose to add,
reduce, pay back, or ignore debt. It’s by no means intended as a complete solution to scale the
management of debt. It works precisely because it requires no buy-in.

How to do it
Simple: Make debt visible, build a habit, negotiate regularly, and give away control.
Visual Collaboration Tools 114

Make it visible

Example of a Wall of Technical Debt

Visual Collaboration Tools 115

Pick a wall in the space where your team is working. Make sure it’s very publicly visible. Label it
as the “Wall of Technical Debt”. Draw a nice dramatic logo. Make sure there are sticky notes and
markers around.

Build a habit

Whenever you work on the code:

• What made you slow? What made the code difficult to understand? What caused the bug
to be hard to track down? What should have been better documented or tested? Write
down any technical debt you encountered on a sticky note. Keep it short, but make sure you’ll
be able to understand it later.
• Estimate the opportunity cost: the time that you would have spent on something else if this
issue did not exist. Write it on the sticky note. Agree on a notation for time, such as tally marks
or dots per half day. Being visual is more important than being precise.
• Estimate how long it would take to fix it, note that down as well.
• Optionally, write down how the technical debt could be fixed. You’ll probably want to do that
in an issue tracker. Write the issue ID on the sticky note.
• Put the sticky note on the Wall of Technical Debt.
• Whenever someone runs into the same issue, add more marks to represent the time that they
lost.

Remember to also add sticky notes whenever you introduce new technical debt yourself. Be honest.
There’s no shame in this, because you are not your code. Remember that technical debt is an
investment, not a crime — unless you’re hiding debt, then you’re cooking the books!

Negotiate

As the Wall of Technical Debt grows, people in your organisation might get a little nervous. That’s
ok; the debt was always there, you only made it visible. Hopefully some of the habits start changing.
Whenever someone gets up to add another dot to an existing sticky note, discuss it with the team.
Compare the cost of the measured wasted time to the estimated time to fix the debt. Sure, it might
take a day to fix the code, but if you keep losing two hours over it every week, that’ll pay itself back
soon. Or perhaps fixing it isn’t worth it? That’s not a matter of aesthetics or opinion anymore. It’s
a matter of empirically collected metrics. Congratulations, you’re negotiating tradeoffs as a team.
When someone adds a sticky for newly discovered existing debt, consider if it’s something the team
could fix now. But it’s perfectly fine to just put it on the wall, that’s what it’s for. Is there no evidence
that this problem will keep costing you? Just let it collect more dots for now.
However, when we’re introducing new debt, it’s different. Consider if the team could choose not to
take the shortcut, and just fix the code, while it’s still cheap. The question shouldn’t be “Do we have
time now?”, it should be “Is it worth paying interest on this later? How much?” The answer could
Visual Collaboration Tools 116

range anywhere from “It doesn’t matter, just commit it” to “Lots of things will depend on this, let’s
get it right before moving on.”
The point is not to fix all technical debt. The point is to learn to negotiate when to add it, when to
fix it, and when to avoid it. Before, this happened mostly invisibly. Individual team members added
or fixed debt without knowing all the facts. Now, the collective brain power of the team is applied,
using real data.

Give away control

Now we get to the real magic. Because the Wall of Technical Debt is so visible, managers should
start to take notice. (If they still don’t, add some € or $ signs with a fat red marker on the Wall.
Money is the universal language, and lost money stings twice as hard.)
When a team asks for time to spend on technical debt, there’s no direct tangible benefit to the users
or the business. A manager can’t decide whether those fixes are of critical importance, an attempt to
play with shiny new tech, or a desire to have prettier code. Even for a manager with a deep technical
background, if they’re not directly involved with the code, it’s impossible to judge the importance
of a fix.
But with the Wall of Technical Debt, it’s different. Now it’s not about opinions; it’s not a desire
to be a craftsperson who writes elegant code; it’s not about solving challenging puzzles. This time,
it’s about facts, numbers, debt and interest payments, returns on investment. You’re speaking the
manager’s language. Good code as an asset, bad code as a liability. They’re trained for this: look at
the numbers, make decisions. They’ve got the methods for it: CBA, OODA, PCDA, SWOT, …
Give away control. The manager knows more about the company strategy, the budgets, the risks.
Let them decide, with your help, what to fix and when to plan it. The numbers enable that.

Tips and Traps

• Do not start with a complete audit of all your debt. Sure, you could spend a few days identifying
all debt. But then you need to get buy-in, set up dates, and you’re making it a big thing. “We’ll
do it during Summer” or “after the big project is finished” or whatever the local euphemism
for “never” is. A single sticky note on the wall today, brings value today. You can always do
your big audit later, just don’t make it a bottleneck.
• Without tally marks or dots that represent real incurred costs, we’re back at opinions. Some
of the things that bother you, may not actually impact future development. By only adding
problems when you run into them, your Wall of Technical Debt will represent actual time
wasted, not some perceived quality. And you want to build a habit of negotiating debt, not do
a one-off effort and go back to the old ways.
• It goes the other way around as well. If you encounter ugly or strange code, but you didn’t lose
any time over it, don’t mark it. We’re not measuring whether you like it, only whether it costs
time.
Visual Collaboration Tools 117

• Don’t skip the physical wall. Resist the urge to put everything in a digital tool such as a bug
tracker. Logs and metrics only have an impact when people look at them. Digital tools make it
easy to hide things. The wall is visible, confrontational even.

Conclusion
After reading my 2013 blog post, a startup introduced the Wall of Technical Debt. They were a very
small company, and all the wall space was already used by business plans and app mockups. They
put the sticky notes on the office’s one window. The joke became that whenever the room got too
dark, they knew it was time to refactor. More importantly, they had been stuck alternating between
perfectionism and hacking things to get to market faster. The Wall of Technical Debt helped them
break out of that, and they launched soon after. We’ve since heard stories of teams in all sorts of
companies using it successfully, and perhaps so can you.

Authors, attribution and citations

Based on “Managed Technical Debt”, Verraes 2013⁸⁰. Thanks to Indu Alagarsamy and Rebecca Wirfs-
Brock for reviewing the draft.
Mathias Verraes | @mathiasverraes⁸¹ | verraes.net⁸²
Mathias Verraes runs a boutique consultancy that advises organisations on designing and mod-
elling software for complex environments, including architecture, analysis, testing, and refactoring
“unmaintainable” systems. He has worked with clients in Government, Logistics, Mobility, Energy,
E-Commerce, and more. He teaches Domain-Driven Design courses and curates the DDD Europe
conference. When he’s at home in Kortrijk, Belgium, he helps his two sons build crazy Lego
contraptions.

⁸⁰http://verraes.net/2013/07/managed-technical-debt/
⁸¹https://twitter.com/mathiasverraes
⁸²https://verraes.net
Visual Collaboration Tools 118

Wardley Maps
Wardley Maps provide a way to visualise, communicate, review, and implement a Strategy in an
organisation or department.
What underpins Wardley Maps is the Strategy Cycle that’s derived from Sun Tzu’s five factors of
the Art of War⁸³ and John Boyd’s OODA (Observe, Orient, Decide, Act)⁸⁴ loop. Notice the arrows.

The Strategy Cycle

The table below portrays the Strategy Cycle in another format and highlights what’s encompassed
in the terms “context” and “environment” or “situation awareness”.
⁸³https://en.wikipedia.org/wiki/The_Art_of_War
⁸⁴https://en.wikipedia.org/wiki/OODA_loop
Visual Collaboration Tools 119

Strategy Cylce portrayed as a table

Terms and definitions

Sometimes, the term “Wardley Map” is used in two senses:

• The first sense is to use “Wardley Map” to mean the “Landscape” as described in the table above.
Such a Map consists of Components that make up an organisation, their position relative to an
anchor, and how they change (not so much over “time” but how “ubiquitous and certain”
they become).
• Another broader sense is to use the term “Wardley Map” to refer to the whole Strategic Cycle.
Such a Map would also incorporate the other factors (Climate, Doctrine, and Leadership)

For this section of the book, we’ll use the term “Wardley Map” in the first sense.
A wardley map consists of the following:
(1) Components. These are the building blocks of an organisation. There are at least four types of
Components:

• activities (things we do)

• practices (how we do something)
• knowledge (how we understand something)
• data (how we measure)

In the act of doing something, an organisation uses all these four components to produce something
that will fulfill a need of a user. Therefore, the “user need” acts as an anchor to all these
components. Furthermore, each component is not entirely independent; some are prerequisites of
others. And being prerequisites, they may not be visible to the User. As such, all components are
positioned relative to the anchor.
Let’s use an example of a tea shop.

• As a user, my need is to have a cup of tea.

Visual Collaboration Tools 120

User with User Need

• What’s needed in order for the tea shop to provide that? They need a cup, tea, hot water, and
someone to prepare it and serve it.

User with User Need and top-level components that meet that need

• What’s needed in order to provide hot water? water and a kettle. For the kettle to boil the water,
it needs some kind of power.
Visual Collaboration Tools 121

Value chain with less visible components

• The underlying components provide value to the components above them. Each component
depends on the value they get from other components. Hence the name “Value Chain”.

(2) For a component’s position to be relative to the anchor of “user needs” means that as each
component is broken down into much smaller components that the component itself needs, the
underlying components become “invisible” to the User. This is represented on the Y-axis.

• The User doesn’t “see” or “even care” about the kettle or the power being used.
• What the User “sees” or “cares about” is at the top. What the User doesn’t see or “care about”
is at the bottom. What’s at the top is “visible” to the User; what’s at the bottom is “invisible”.
Visual Collaboration Tools 122

• The position of the components is visualised as a Chain on the Y-axis

Value chain with Y-axis

(3) These components are not static but change. This is visualised in Wardley Maps and termed
“Evolution.”
All components change. Each type of component also changes. As they change, they take on different
characteristics. And we deal with them in different ways.
Visual Collaboration Tools 123

This change on a Wardley Map is termed “Evolution” and is based on the evolution graph⁸⁵ whose
Y-axis is “Ubiquity” and X-axis is “Certainty.” It models how a component changes not against
“time” but by how “ubiquitous and common” the component was. That is, how commonplace
the component was (ubiquity) and how well understood, defined, and standardised (certainty) the
component was.

Evolution Graph

It differs from how innovations spread through cultures, which is modeled as percentage adoption
(on the Y-axis) over time (on the X-axis). This was made popular through Moore’s book “Crossing
the Chasm” which builds on Robert Everett’s work “Diffusion of Innovation”. If you’d like to read
more about these differences and their implications, I’d recommend reading from Figure 72 of the
online book⁸⁶.
It’s important to keep this distinction in mind because both have the same S-curve. It reminds us
that Ubiquity for a similar product depends on its market. For an iPhone, it’s in the “Commodity”
stage when 90% of the population own at least one. Whereas a gold bar is in the “Commodity” stage
e when less than 1% of the population own one.
⁸⁵https://blog.gardeviance.org/2012/03/tens-graphs-on-organisational-warfare.html
⁸⁶https://medium.com/wardleymaps/finding-a-new-purpose-8c60c9484d3b
Visual Collaboration Tools 124

As each component evolves, it goes through four stages, Stage 1 to Stage 4. This path of evolution is
referred to as “commoditisation”.

• For an Activity, it starts as an innovation, its “Genesis” (e.g. the first battery, the first
phone, the first television, the first computer) and then how “Custom built” examples are
made, followed by a stage of “Product development” (constantly improving generators,
phones, televisions, computers), the introduction of Rental models for the activity. And finally,
“Commodity” provision (and where appropriate) Utility services for provision.
• For a Practice, it starts as a “Novel”, then its “Emerging”, it becomes “Good”, and finally
“Best”.
• For Knowledge, it starts as a “Concept”, then “Hypothesis”, then a “Theory” and finally it’s
“Accepted”.
• For Data, it starts as being “Unmodeled”, then “Divergent”, then “Convergent”, and finally
it’s “Modeled”.

The table below summarises them.

Types and stages of evolution

Evolution is represented on the X-axis. A Wardley Map of the tea shop would look something like
this:
Visual Collaboration Tools 125

Value Chain with Evolution

One final aspect to note is that a component on a Wardley Map can itself be a whole Wardley Map
in itself. Referring back to the tea shop, “Power” is a single component on that map. But for an
energy producing organisation, this single component is a whole Wardley Map in itself that may
encompass different ways of generating energy. The level of detail depends on your context and
whether it helps you make decisions and act.

What is made possible

Wardley Maps as a common language

Wardley Maps become the language to communicate the Strategy and its implementation. The
strategy is made visual.
Because everyone is using the same language (the map and its symbols), communication is taking
place. The problem of language is visible when different departments are trying to talk to one
another: Finance uses their own terminology, so does HR, Engineering, IT, and so on. Even the
book, “Domain Driven Design” begins by addressing the need of a common language.
As more information is added to the Wardley Map, it enables different departments to communicate
using the map itself as a common language. One such example is from from Dr. Alistair Moore
(@latticecut⁸⁷) below.
⁸⁷https://twitter.com/latticecut
Visual Collaboration Tools 126

More detailed map for all departments

Because they’re visual, they’re easier to understand. Thus affording a way for others to challenge
the underlying assumptions of the Map. Furthermore, discussions on where and what to focus on
or which direction to take are open to all to participate in.
Since the map depicts evolving components, it can be saved and later reviewed to check whether
the strategy and its implementation had the intended effects.

No one-size fits all but use appropriate methods

Since each stage of evolution exhibits different characteristics, the way we deal with components in
each stage also differs.
The way we manage and deliver them differs. We expect those in Stage 1 to be less certain and
therefore, always changing. So agile approaches are suitable, such as Extreme Programming. On
the other hand, those in Stage 4 are more certain, they don’t change as often (and we don’t want
them to) and so methods that reduce deviation, such as Six Sigma, would be more appropriate. In
between the two extremes, the components are becoming more stable - what to produce is known
and so methods such as Lean or Minimum Viable Product (MVP) work well.
The way we hire and retain people for these activities also differs. They may be in IT or Finance or
HR yet, if their activities are in Stage 1, they’ll have the same view: that of experimenting to make
the impossible (referred to as “Pioneers”). Those in Stage 2 and 3 focus on continual improvement
Visual Collaboration Tools 127

to make the best (“Settlers”). And those in Stage 4 want to comoditise components focusing on
operation efficiency (“Town Planners”). Knowing that influences the kind of team structure that
we’ll have.
The way we buy them, consume them, and account for them also differs. So there would be different
methods for Purchasing and Accounting based on the stage of evolution a component is in. For more
information, refer to Figure 249 of Simon Wardley’s article “On playing chess⁸⁸”.

Anticipate and deal with inertia

Another important part is that we can anticipate when and where we don’t want to change, in
other words, our own inertia and address it. So far, there are about forty kinds of inertia that an
organisation and its environment can suffer from.

How to use it
Wardley Maps span a wide area, vary in their level of detail, and are useful at different layers of
the organisation. Each layer of the organisation has different spans of control and work on different
timescales. Yet, each faces these common problems as Simon Wardley⁸⁹ outlines in an article on
Stopping Self harm in Corporate IT⁹⁰:

• duplication. Examples of 100+ projects doing exactly the same thing in an organi-
sation are not uncommon
• bias. Lots of custom building that which is already a commodity
• miscommunication and alignment issues
• constant restructuring to bolt on new capabilities followed by further restructuring
to remove it
• constant missed opportunities where obvious changes are not taken advantage of.

Even at the unit in an organisation, that of a team - say, a Software Development team, we can rid
ourselves of the bias of custom building components, such as our own logging framework and use
an existing library instead.

Timing

As for timing, the workshops can be run as often as is needed. Subsequent workshops should build
on the first one in order to fill in any missing details on the Map or to review what’s changed due
to your actions or those of the market.
⁸⁸https://medium.com/wardleymaps/on-playing-chess-2634b825dbac
⁸⁹https://twitter.com/swardley
⁹⁰https://blog.gardeviance.org/2016/05/stopping-self-harm-in-corporate-it.html
Visual Collaboration Tools 128

Focus

The focus varies depending on the goals of the participants. Ideally, going through the whole Strategy
Cycle would be worthwhile. But if that’s not possible, then the initial focus would be on getting to
know our users, their needs, how we satisfy them. Thereafter, getting to reducing duplication and
bias.
Then we learn some elements of Doctrine and Climatic Patterns to anticipate changes to components
of the resulting map and how to adapt to them.

Preparation for the workshop

• A group of people who know your context: product and organisation.

• Post-It Notes of different colours.
• Different colors of string.
• Pen Markers.
• Print out the following cheatsheets to hand out to participants:
- Evolution Cheatsheet⁹¹
- The Doctrine cheatsheet in this Google Sheet⁹²
- The Climatic Patterns cheatsheet in this Google Sheet⁹³

The Workshop

These steps are taken from Simon Wardley⁹⁴’s article, “Finding a path⁹⁵”.
This usually takes about 30 minutes to an hour or two, if participants are learning and getting to
know the basics of Wardley Maps.

• Purpose (should be time-boxes.) - what’s the purpose of your organisation or team? Why do
others need you or work for you?
• Users and User Needs
– Examine what you provide to others that they value, i.e., a list of transactions with others.
From this, you’ll discover who your users are and what need you’re fulfilling for them.
The focus is on their needs not yours.
– Write down each User Need on a Post-It.
– Place them on a whiteboard (ideally a wall) in fairly random order.
– Work out a user journey to understand what steps your users take to have this transaction
with you. Techniques such as “User Story Mapping”, “User Journeys” are useful to use.
– It’s common for new unmet needs to be described at this point, don’t add them to the wall
but instead take a note as these represent new opportunities.
⁹¹https://aws1.discourse-cdn.com/business4/uploads/wardleymaps1/original/1X/acb8295675fb76d878d823b82492c2ead029efd1.jpeg
⁹²https://docs.google.com/spreadsheets/d/1iUjZTCCv1KsgQ5VNohtU1c3BpW7pwh7N_FDgJimjHF8/edit#gid=0
⁹³https://docs.google.com/spreadsheets/d/1iUjZTCCv1KsgQ5VNohtU1c3BpW7pwh7N_FDgJimjHF8/edit#gid=21887705
⁹⁴https://twitter.com/swardley
⁹⁵https://medium.com/wardleymaps/finding-a-path-cdb1249078c0
Visual Collaboration Tools 129

• Value Chain
– For each need, write on a different colour of post-it notes, the top-level components that
meet the need. Techniques from the “Business Capability Model” are useful.
– From this list any subcomponents that the top-level component will use including any
Data or Practices or Activities should be written down.
– When the group is satisfied that the components for all needs have been written, then take
the User Needs on the wall and discard them.
– Now write on the wall, a single vertical line and mark it ‘value chain’.
– The top-level components should now be added to the wall at the top of the value
chain and the sub-components placed underneath with lines drawn (or threaded) between
components to show how they are linked.
– Once the group is satisfied that they’ve successfully described the value chain then take a
picture of the wall and remove everything.
– Sometimes, through describing the Value Chain, the organisation’s purpose becomes
clearer.

• Evolution
– On the wall, now draw two lines - a vertical line for value chain and a horizontal line for
evolution, marking on lines for genesis, custom built, product and commodity.
– Start to add the value chain that you previously created beginning with the top-level
components.
– For each component, ask in which stage of evolution is it in?
* How ubiquitous and well defined is the component?
* Do all my competitors use such a component?
* Is the component available as a product or a utility service?
* Is this something new?
– Use the Evolution Cheatsheet to workout in which stage of evolution to place a component.
– Where there is disagreement over a component then it can be broken into two or more
subcomponents. Some subcomponents might be more evolved but some might be less
evolved.
– Where disagreement persists between groups on an identical component always treat
it as the more evolved. But keep a note on such components - they might be useful in
determining areas where to make efficiency gains.

• Doctrine
– Use the cheatsheet for Doctrine.
– Pick a couple and apply them to yourself, such as:
* “Are we using a common language?”
* “Are we challenging our assumption?”
* “Do we know who our users are?”
* “Do we know what their needs are?”
Visual Collaboration Tools 130

* “How do we go about removing duplication and bias?”

• Climatic Patterns
– Use the cheatsheet for Climatic Patterns. Pick a couple and apply them to components of
the map.
– One example to start with is “Everything evolves through supply and demand” and
“Components co-evolve.” This leads us to ask
* “which components are about to evolve from one stage of evolution to another?”
* “What effect on Activities/Practices/Data will this component have once it moves to
another stage?”
• Decide and Act: while deliberate on what to do next, use other techniques (Impact Mapping,
SWOT) to help make a decision amidst several options that are now present.
• After we decide, we keep the maps we’ve created to review them or add to them in the following
workshops.

Why?
Speaking of the aim or purpose of Strategy, Frans Osinga quotes John Boyd⁹⁶ telling us that it’s

to improve our ability to shape and adapt to unfolding circumstances, so that we (as
individuals or as groups or as a culture or as a nation-state) can survive on our own
terms.” (Osinga, Frans P.B. “Strategy, Science, and War”, 217-218. Oxon: Routledge 2007.)

That’s what Wardley Maps help us do in the context of business organisations.

• If we know the “Landscape” in which we operate, we have something to observe and

something to visually communicate it to others, especially the things that might change.
• If our actions are guided by “Doctrine”, then we’re likely to be more effectively organised than
others.
• If we know the “Climatic Patterns”, we’ll be able to anticipate change or even shape the
unfolding circumstances.
• If we know what “Gameplays” to make for our context, we’ll be able to make the most of it
on our own terms.

Authors, attribution and citations

Simon Wardley (@swardley⁹⁷) - creator of Wardley Maps and author of the online book on Medium⁹⁸
⁹⁶https://en.wikipedia.org/wiki/John_Boyd_%28military_strategist%29
⁹⁷https://twitter.com/swardley/
⁹⁸https://medium.com/wardleymaps
Visual Collaboration Tools 131

Chris Daniel (@wardleymaps⁹⁹) - creator of the online course for Wardley Maps¹⁰⁰
Ben Mosior (@HiredThought¹⁰¹) - creator of the website that helps people get started - https://hiredthought.com/ward
mapping/
John Grant (@jhngrant¹⁰²) - maintains the awesome list of Wardley Mapping resources¹⁰³
Julius Gamanyi (@juliusgb2k¹⁰⁴) - contributed this article.
⁹⁹https://twitter.com/wardleymaps
¹⁰⁰https://learn.leadingedgeforum.com/courses
¹⁰¹https://twitter.com/HiredThought
¹⁰²https://twitter.com/jhngrant
¹⁰³https://github.com/wardley-maps-community/awesome-wardley-maps
¹⁰⁴https://twitter.com/juliusgb2k
Field Stories for a tool
An Impact Mapping Workshop to Make Out The Right
Decision Between Hundred Possibilities
Being part of a start-up means a lot of pressure, not enough time and a bet on the
future. Impact mapping helps to get everybody to focus on the same goal and gives a
structure how to find and decide about the best approach to achieve it.

Written by Krisztina Hirth (@YellowBrickC)

In 2019 I have worked at a small start-up in the insurance industry. We had our first product already
online and we had a relatively good image how our customers behave. We were aware that our
biggest bottleneck is customer contact. We were able to handle it now, but we were preparing the
launch of a huge insurance product which will raise the number of contacts drastically. The question
was: how we can control or prevent the chaos.
It was the perfect moment for impact mapping¹⁰⁵.
Participants: the whole company. We were about 15 people with very different background and
focus: marketing people, social media managers, HR representative, developers and data scientists,
partly with deep knowledge in the insurance business and some without these insights. It is a
seldom situation which I always appreciate because it tells a lot about the company: what culture
is nurtured? One of open mindedness and curiosity about everyone’s opinions or one of “I am the
boss, I know it better also I don’t need/want any discussions”.
Timeslot: the workshop took about two and a half hours, but we finished only the second step out
of four. The other two steps were planned to follow in smaller teams, working towards one of the
defined goals.

Step 1: Goal
We have followed the steps from the book and we made discoveries at every step! The most important
one was that most people had different goals in mind.

In a discussion with the CEO afterwards he said he was very pleased. The workshop was
really cool and informative and surprising sometimes
¹⁰⁵https://www.impactmapping.org/
Field Stories for a tool 133

and he had no idea that we are not working towards the same goal.
We found out that there are a lot of goals which cannot be acheived at the same time obviously.
Some of the goals wer short time goals, other were good as medium or long time goals. All of them
were written on post-its and We split them up by the targeted time. As the company was composed
of three teams we also selected the three next goals, one for each team.
Having all these insights worked out together and visualized on a wall helped everybody to have
the right focus and concentrate on the same thing.

What is a goal without alignment? It is only a sentence on the paper, it’s not a goal. A
goal is defined by understanding and alignment.

Measurability

The two most important elements of these technique are visualization and measurable goals. Most
companies I know having this kind of shared goals or objectives don’t think about measurability,
so the goals become rather wishes or hopes. Without metrics defined beforehand a company can
invest a lot in actions but for a long time won’t be able to tell if these actions will make the desired
impact. One can invest months in reaching a target, but the result could be an over achievement or
failing the goal completely if it cannot be measured and reiterated based on the results.
Defining a metric means setting these five properties:

• what to measure (the goal)

• how to measure it (i.e. meter or money)
• what is the current situaton (the benchmark)
• what is the minimum acceptabe value (the break-even point for investment, the constraint)
• what is the desired value (the target)

Step 2: Actors
The next step was to find the actors. With all the different people in the room we had all the different
perspectives in one place and thus we came to a very long list, with a few surprises on it. My learning
from this step was that even if you won’t analyze all of them it is very important to create this list
to see how many people, roles can impact your goals. It can be a real eye-opener.
Having this list on the wall it was really easy to categorize them in primary, secondary ad off stage
actors. Now we had the full context to be able to define the impact, the actions we can take to achieve
the current goal.
Field Stories for a tool 134

Next Steps: Impact and Deliverables

The hardest part was done. As next step the three teams will have to go on separate ways and
start to work out the possible impacts to achieve their goal, choose the best possible one and define
the deliverables, the necessary actions. After starting to deliver the results must be measured and
compared with the metrics we defined. After a target is reached or in case of making the situation
worse (the value sinking below the benchmark) the action should be reevaluated and eventually
stopped. As Gojko¹⁰⁶ writes

Rinse and repeat

Final thougths
• read the book: it is short, very visual and self-explaining. Follow the path and take care not to
make the errors listed in the book.
• make sure that everybody is on board. The goal-finding part was the hardest and the longest,
but it was essential. Without this starting point the result will be exactly so valuable like
building a great feature which fulfilles a lot of things, but none of them were needed by the
customers. Deliver business goals nut just features
• say no to goals which are not measurable. Explain the constraints every goal must obay and
explain, why.
• do not even start with impact mapping if the company isn’t prepared to inspect and adapt.

If a product milestone or project succeeds in delivering the expected business goal, it is a

success from a business perspective, even if the delivered scope ends up being different
from what was originally envisaged. On the other hand, if it delivers exactly the requested
scope but misses the business goal, it is a failure (Gojko Adzic)

¹⁰⁶https://twitter.com/gojkoadzic
Field Stories for a tool 135

Improving your Organizational Continuous Delivery

capabilities with EventStorming
Continuous Delivery is not just a Team Effort - Four steps to improve your skills
together

Written by Pim Smeets & Kenny Baas-Schwegler

Many projects we are involved in focus on helping a team shorten their Time To Market (TTM)
by building or developing Continuous Delivery capabilities. While improving specific technological
capabilities on team level is never a bad thing, the most significant bottlenecks are usually not
confined to the skills of this small group of people. Therefore, we need to walk a different path; we
need to improve organizational Continuous Delivery capabilities.
To significantly shorten TTM, we need to take a holistic approach and focus on the entire system
and identify the Theory of Constraint¹. In this article, we share how we help companies
move from discontinuous to Continuous Delivery in a short timeframe.

“If we have a system of improvement, that’s directed at improving the parts taken
separately.
You can be absolutely sure that the performance of a whole will not be improved.”
-Russel L. Ackoff

What is continuous delivery?

Continuous Delivery is a software development discipline or approach that is primarily an orga-
nizational capability; it goes beyond the automation of tests, infrastructure, and deployments. It
makes sure that your software is in a releasable state at any time. In essence, the goal of Continuous
Delivery is to transform an idea or user request into a working solution within a timeframe that is
acceptable for its users, where the solution can be anything from a new version of the software, an
updated customer service process, or a hardware iteration. If an organization is unable to release
product increments sufficiently, reliably, or quickly they are in what Steve Smith calls “a state of
Discontinuous Delivery.”² Once this happens, the risk of losing customers will increase,
because not providing them with what they need or want results in them looking for alternative
solutions.

How do we adopt continuous delivery?

Continuous Delivery is a set of team and organizational capabilities, all aimed at accelerating
the software delivery process. It is not easy to adopt these: e.g., database migration, trunk-based
development, small batch sizes, continuous change reviews. Also, they might not always help in your
Field Stories for a tool 136

specific context. To know what will be useful, we experiment with new capabilities and measure
their effectiveness with the improvement kata.³
To successfully kick-start the adoption of Continuous Delivery, we use a workshop based on
an adapted version of EventStorming. This helps us map the software delivery process, identify
constraints, and provides enough actionable insights to start improving straight away.

Using EventStorming as a baseline for your Continuous Delivery

improvement
The workshop is based on two workshop formats from the EventStorming community, Big Picture
and Team Flow EventStorming. The process itself is quite straightforward and consists of four steps:
I. Use EventStorming to visualize your software delivery process
II. Visualize queues, constraints and improvement points
II. Analyze the results and enrich the data
IV. Decide as a group what actions to take

I Visualizing your software delivery process

Accelerating TTM starts with taking a holistic view of the software delivery value stream we
are trying to speed up. We visualize all domain events (events relevant to your business domain)
that occur in the process of turning an idea into working software, like: ‘user feedback received’,
‘refinement done’, ‘code checked in’ or ‘artefact deployed to production’.

Chaotic exploration

After the campfire chat, it’s time for the messy part! During what we refer to as “chaotic exploration,”
we ask the people in the room to write down all domain events relevant for their software delivery
flow on post-its. Then, we ask them to place the events in the order they think they happen without
being influenced by others. Doing this makes the participants’ mental model of the process visible
(on the paper roll) and brings it into a shared pool of understanding.
Field Stories for a tool 137

Results of Chaotic exploration

Enforcing the timeline

When all events are on the paper, it is time to make sense of the chaos. We refer to this step as
“enforcing the timeline” because we challenge participants to create a single consistent timeline of
their software delivery and remove duplicate stickies. This then leaves us with a clear picture of the
flow structure. You will notice that the room will become noisy during this phase as participants
have to align with each other. After that, we add post-it labelers to identify the different stages of
software delivery and structure the paper roll even more.
Typically the process that is visualised starts with an idea coming from internal stakeholders or
client feedback. This idea is then conceptualized, a business case is created, and the budget is
approved. The next steps include creating a UX design, involving relevant (engineering) teams,
backlog prioritization, refinements, writing code, testing changes, and the regular release process. A
typical ending point would be the deployment of a new feature to production and receiving end-user
feedback.
Two things to keep in mind!

• What this process looks like varies per organization, and having some kind of fast track in place
for unique and urgent requests is not unusual. We advise you to visualize your situation as-is,
to provide space to map multiple alternative flows, and to remember that models are always a
trade-off between abstracting reality and accuracy.
Field Stories for a tool 138

• Visualizing is a collaborative act between all stakeholders. To get the most out of it, be sure to
invite the right people and significantly reduce the number of assumptions made.

Results of Enforcing the timeline

II Add constraints and opportunities

The next step is to add queues, constraints, and improvements to your visualization.

• Constraints come from limited resources, like: time, budget, and materials.

* Queues (waiting times between steps or processes) are intentional or caused by constraints. For
example, product increment planning takes place every month, effectively pausing progress for up
to thirty days.

• Opportunities are a particular type of sticky, indicating there is potential to enhance a step (or
the entire process). When visualizing opportunities, you do not have to come up with a solution
yet. It just serves to indicate there is work to be done and efficiency to be gained. For example,
reducing the number of handovers can lessen queues and misunderstandings.
Field Stories for a tool 139

Results of constraints and opportunities

Summarize and enrich the data

After the EventStorming session, it’s time to crunch and plot the data. During the workshop, you
will have gathered a list of processes, plus the time it takes to get from one process to the next, which
can vary per situation. Don’t worry, just plot a minimum, maximum, and average queue time. The
goal is not to be 100% accurate but to create an overview that helps kick-off an informed discussion.
Now is also the time to enrich the data you gathered. If you are using an issue tracking tool like Jira
or an automated Build and Deployment tool like Jenkins, Gitlab, or Azure DevOps, you most likely
have a ton of metrics readily available. If you aren’t using these tools yet or collecting data from
them, investigate and set them up!
It’s more difficult to gather detailed data when an item is still just an idea in someone’s head or the
output of a brainstorm session (in the discovery phase). Again, no need for stress, the goal is not to
get data that is 100% accurate but to collect insights to spark a fact-based discussion.
Your visualised output can look something like the chart below. What immediately stands out here
is that most time constraints are not in the activities that are controlled by the development team.
Field Stories for a tool 140

Value stream

Creating ownership and sustainable change

At this point, you have a holistic view of the process. You know what every step entails, and you
have identified constraints as well as improvements. Now it’s time to look at the future, place that
elusive dot on the horizon, and start working towards it! Once again, it’s a group process that needs
the right operational, tactical, and strategical stakeholders included. Involve those who are going to
be implementing changes for them to become explicit owners of the improvements they proposed.
In a workshop day, form small focus groups responsible for a part of the process. Ideally, a group
contains a subject matter expert, someone with a mandate to make decisions and a stakeholder from
related processes. For example, you will set-up groups for ideation, planning, software development,
and organization. The software development group ideally consists of one or more developers, a
business owner, and a manager.

• The business owner will play a role in smoothing out the handover between the business
and the development team(s), by asking questions like ‘What are we making?’ And, after an
iteration, ‘Did we do the right thing?’
• The developers will contribute to turning a need into a solution that fits the (technical) context,
and help release it safely and predictably.
Field Stories for a tool 141

• The stakeholders can help align team scope and software architecture, as well as resolve
capacity issues or other organizational limitations that prevent teams from excelling.

Tip: Use a liberating structure⁴ like “What I Need From You,” “1-2-4-all” or “Troika
Consulting” to discover and formulate your dot on the horizon. After getting to the ideal situation
that is still attainable within your context, start creating action points. What little thing can you do
today to work towards this goal? What topics do you need to investigate further? On what points do
you need structural change, and what do you need to achieve your goal? Can you make a decision
today? If not, which stakeholders do you need to ensure decisions are made?
Bring the entire focus group back together every 1-2 hours and have every one of them present their
progress to receive rapid feedback and ensure alignment. End the day by bringing all ideas, goals,
and action points of the different groups together.

Example from the trenches

Following this technique leads to exciting and actionable insights. For example, we recently used
this technique to map the software delivery flow of a non-profit organization together with their
marketeers, business delegates, product owners, software developers, and testers.
The hypothesis was that reducing the time spent on user acceptance testing (14 days) would
significantly shorten the organization’s TTM. During the process, we discovered that the real
bottleneck was the time it was taking for an idea to make it onto their backlog, namely: a staggering
three to eighteen months!
Regardless, there were still excellent reasons to invest in the technological capabilities of Continuous
Delivery. For instance, by automating tests and deployment, we removed repeated manual and error-
prone parts of the process. Nevertheless, in this case, solely strengthening technological abilities was
not enough to reduce TTM as desired, because there were significant queues and constraints in the
entire flow that needed fixing to realize this. Which brings us back to where we started: to improve
performance, you need to look at the process as a whole, and our approach to (the adoption of)
Continuous Delivery helps you do precisely that!

About the Authors

Pim Smeets

Pim Smeets is a consultant at Xebia giving strategic advice on software development. For Pim
understanding the context of an organization (‘why do we do what we do?’) is key to making lasting
changes: there is no one size fits all.
Creating high-performance teams does not stop at using techniques such as Continuous Delivery,
TDD or BDD. It means producing high-quality software, in close collaboration with its stakeholders;
adding real business value in small increments that can be automatically and securely released.
He believes in autonomously aligned teams by bringing together business and IT using collaborative
visualization techniques, such as Example Mapping or EventStorming.
Field Stories for a tool 142

Kenny Baas-Schwegler

Kenny Baas-Schwegler is a strategic software delivery consultant, Socio-technical thinker, facili-

tator, collaborate modeller, technical lead that builds quality into software delivery at Xebia. He
mentors, coaches and consults management and teams by using practices, techniques and tools from
domain-driven design, anthropology, deep democracy, behaviour-driven development, DevOps, and
Continuous Delivery.
By using and combining tools such as EventStorming, Example Mapping, Impact Mapping, and
User Story mapping, he helps to bridge the communication gap between business and IT. With
these approaches, he aims to create a transparent, safe, and collaborative space with constant and
instant feedback for delivering quality software.

Sources
1. See https://www.leanproduction.com/theory-of-constraints.html¹⁰⁷
2. See https://www.continuousdeliveryconsulting.com/blog/discontinuous-delivery/¹⁰⁸
3. See https://leanpub.com/measuringcontinuousdelivery¹⁰⁹
4. See http://www.liberatingstructures.com/¹¹⁰

¹⁰⁷https://www.leanproduction.com/theory-of-constraints.html
¹⁰⁸https://www.continuousdeliveryconsulting.com/blog/discontinuous-delivery/
¹⁰⁹https://leanpub.com/measuringcontinuousdelivery
¹¹⁰http://www.liberatingstructures.com/
Field Stories for a tool 143

Gathering quality feedback at #play14 with

EventStorming

Written by Cédric Pontet

What is #play14?
#play14¹¹¹ is a worldwide gathering of like-minded people who believe that playing is the best way
to learn, share and be creative!

Tell me and I forget, teach me and I may remember, involve me and I learn
Benjamin Franklin

For two and a half days, people with many different profiles and experiences¹¹² are invited to
share serious games & fun activities¹¹³, experiences & tips, knowledge & insights, laughs & smiles.
Everyone is welcome to join.
A proposed activity could be a lot of things:

• A serious game that you use as a metaphor to understand a new concept

• An ice breaker game where people learn more about one another
• A warm-up or an energizer that you can use to raise the level of awareness and energy
• A facilitation technique that you can use in your daily work
• A team-building exercise that fosters collaboration and self-organization
• A game design session where you invent a new game to teach something new
• A soul searching, deep-dive introspection session where you learn about yourself
• A one-on-one coaching session where you will find some answers with the help of a friend
• A brainstorming session on a question or problem that wakes you up at night
• A creative session where you sketch, doodle, or build something together
• A fun and energetic time with dancing, singing or being silly together
• An improv theater session where you can work on your confidence and ability to speak publicly
• A more esoteric session on a practice/hobby you want to share like yoga, laughter yoga, Tai
Chi, Qigong, meditation, mindfulness, aikido, …

It could be pretty much anything as long as it respects our Manifesto and Code of Conduct¹¹⁴.
#play14 is a place to develop your facilitation skills, increase your ability to accompany change in
your organization, foster your creativity and improve your capacity to innovate.
¹¹¹http://play14.org/
¹¹²https://play14.org/players
¹¹³https://play14.org/games
¹¹⁴https://play14.org/values
Field Stories for a tool 144

You can discover more about a person in an hour of play than a year of conversation
Plato

#play14 is an unconference, where all attendees are also contributors. All you need to do is show
up, and you will be given the opportunity to propose some games or play the games proposed by
the others.
However, #play14 is first and foremost a community of people, a family, and an incredible human
adventure. And I am proud to be one of its founders.

The perpetual quest for improvement

#play14 is now hosted in different cities all around the world, each event being organized by a
different local team.
One of the main characteristics of any of the organizing teams at #play14, independently from the
place or culture, is the sense of continuous improvement, and therefore a need to gather quality
feedback from the participants.
Improving something that works already pretty well is not easy. And to be clear, gathering feedback
at #play14 has always been a challenge. Sure people are ready to share their happy feelings after
two and a half days of intensive play with other people. And it’s always a pleasure to receive some
of the participants’ compliments on the organization. It’s actually quite emotional sometimes. But
when you really want to improve, you need feedback to act on. Something that you really can do
better. Or a new idea that you can work on for the next event.
For years, we have put on feedback walls, with any shape and form we could imagine:

• The simple plus and minus board

• The starfish¹¹⁵
• The Mad Glad Sad¹¹⁶

And probably many others that I have forgotten.

Ther common denominator between all of these techniques were always

• Poor quantity: people were not very engaged to provide feedback

• Poor quality: the feedback provided was superficial and most of the time useless or not
actionable
• Poor collaboration: people were providing individual feedback but they were not sharing ideas

We wanted better quality feedback, but we didn’t know how to get it.
¹¹⁵http://www.funretrospectives.com/starfish
¹¹⁶https://www.teamretro.com/retrospectives/mad-sad-glad-retrospective/
Field Stories for a tool 145

Enters EventStorming
I discovered EventStorming for the first time when I met Alberto Brandolini at Build Stuff in
Lithuania in November 2013. I can’t remember the details of the talk he did, but I remember that
it made my day. Everything he said was right on the spot and resonated with me so much, that
I had to talk to him afterward. Later that day, during the infamous Build Stuff conference party,
I suggested that Alberto could join the first #play14 event that we were planning in Luxembourg,
which he eventually did. In March 2014, we hosted our first #play14 event, during which Alberto
presented a session on ModelStorming, the meta format of EventStorming.
Since then, I have talked about EventStorming at #play14 sporadically. But it was when I saw
Alberto’s talk 50 000 orange stickies later¹¹⁷ at KDDDConf (still named KanDDDinsky at that time)
in 2017 that I realized I should spend more time advertizing for EventStorming within the #play14
community. And it was during the first EventStorming Summit in Bologna in 2018, where Alberto
kindly invited me, that I decided to actively do it. My contribution to the EventStorming community
in some way. Therefore, I proposed sessions about EventStorming during the #play14 events that
followed, London 2018 and Amsterdam 2018, to showcase what the tool was about and how it could
be useful. The subject matter that I chose for that was actually How to organize a #play14 event?.
Funny, right?
But it hadn’t come to my mind to use EventStorming as a feedback tool yet… not until Luxembourg
2019. At the end of the summit in Bologna, we had used EventStorming to gather feedback and try
to figure out the next steps for the EventStorming community. It worked pretty well. So, instead
of trying to run an EventStorming session in just 50 minutes as I did in London and Amsterdam,
which was somehow challenging due to the time constraint and did not really deliver as great an
outcome as I could expect, I decided instead to try EventStorming for the retrospective of the day
in Luxembourg. And it was both a success and a bit of a surprise. In just about 20/30 minutes, we
managed to gather great feedback and I could explain the core mechanisms of EventStorming.
It worked so well that I repeated it at the next Agile meetup in Luxembourg, and then at #play14
Madrid 2019 and #play14 Kuala Lumpur 2019. Even my colleagues Cédric Tamavond and Yoan
Thirion decided to organize a quick feedback gathering at the end of their session on Xtrem
Reading¹¹⁸ at NewCrafts Paris 2019 using EventStorming.

What makes the difference?

By using events as the base of your timeline, you make things very factual. Events don’t leave a
lot of room for interpretation. And building this timeline as a group helps people remember more
precisely what happened during the day.
So, after a few minutes, when you ask people to use pink sticky notes to write down WTF moments,
it comes quite naturally. Having WTF moments at #play14 is what we are looking for. It’s important
for us as a community to disrupt people’s mind, to break some habits, and to help participants get
¹¹⁷https://youtu.be/cG-G6tNCGqY
¹¹⁸https://www.xtrem-reading.com
Field Stories for a tool 146

out of their comfort zone. Gathering that type of information on a normal feedback wall would be
difficult because people would probably be reluctant to share. But with EventStorming, it comes
within the flow. And everyone is doing it, so why not you.
When you then tell people to use green sticky notes to write down their takeaways, it helps them
reflect on what they learned. It’s a nice way for them to anchor and reinforce their learning. Games
and playful activities are very powerful learning tools. Mainly because they allow the participant
to live and feel things themselves, instead of getting explanations of what they should understand
from an external party. The format of EventStorming flows so naturally and is such a powerful
collaborative exercise that it fits right in.
Visualizing the timeline helps a lot. Therefore, when you add the last element of the incremental
notation, the yellow sticky notes with improvements, it is easier for people to find meaningful
things to write down, especially after they have already reflected on their WTF moments and main
takeaways.
Obviously, as an organizer, you tend to focus on the yellow stickies. You strive to get better at what
you do. And it is important to know what you can improve, but it is equally important to realize
that you actually delivered value to the participants. EventStorming is great for that. In a blink of an
eye, you see a whole day of experiences and learning. You can dive in and look at the details of one
moment in the day. You can pay attention to what happened during lunch, or coffee breaks, which
are your responsibility as an organizer, but you also discover some things that happened when you
were not there. Things you did not see. It’s like a colorful time machine.
I mentioned earlier that the main issues we had with the feedback tools we previously used at
#play14 were poor quantity, poor quality, and poor collaboration. With EventStorming, that changed
completely. The quantity of feedback you get in 30 minutes is amazing. The quality is indeed much
better. As I just explained, visualizing a timeline of events helps people focus on what is important
and reflect on their emotions, what they lived, what they felt. Collaboration is so intense, that
it becomes a sort of emotional communion with all the other people that are present. It might
seem a little exaggerated to say that. But believe me when I say that sometimes at #play14, a full
day of playing together can be so physically intense, intellectually exhausting, and emotionally
challenging, that when you close the day with an exercise like that, a kind of magic just happens.
Combining tools
Wall of Technical Debt and Mikado Method

How to use it
The Wall of Technical Debt combined with Mikado Method it’s a powerful source of insights for
software engineering teams.
When a team has a technical debt item, a great way to discover the complexity involved in the
change is to use the Mikado Method per tech debt item. From it, a Mikado graph per tech debt item
can be created, allowing the team to prioritise what needs to be repaid. Also, when the team is using
the Mikado Method per tech debt item, it can discover if tech debt items are linked or not.

Why?

Tips

• Visualise and discover the complexity involved with technical debt

• Potential to visualise if technical debt items are linked
• Insights into the magnitude of the complexity of technical debt items, allowing the team to do
a proper prioritisation
• Use timebox to discover the complexity of technical debt items
• Pair or mob program to learn together

Traps

• Team that doesn’t timebox get lost into investigations of the complexity of the technical debt
items

Authors, attribution and citations

This article was written by João Rosa¹¹⁹. He is a Strategic Software Delivery Consultant at Xebia,
specialised into helping companies to leverage the power of technology to drive their business.

¹¹⁹https://twitter.com/joaoasrosa