Distributed

Agile

John Okoro, Savita Pahuja, Hugo Messer &

a Group of Agile Enthusiasts
Distributed Agile
© 2018 All rights reserved.
Published by C4Media, publisher of InfoQ.com
No part of this publication may be reproduced, stored in a retrieval sys-
tem or transmitted in any form or by any means, electronic, mechanical,
photocopying, recoding, scanning or otherwise except as permitted un-
der Sections 107 or 108 of the 1976 United States Copyright Act, without
the prior written permission of the Publisher.
Production Editor: Ana Ciobotaru
Copyeditor: Lawrence Nyveen
Cover and Interior Design: Dragos Balasoiu
About the Minibook

Distributed teams are the norm for many organizations today. Companies
are global, communications technologies allow people to live away from
the “office” location, and many new workers are nomads. Even though
most people will acknowledge the wisdom that collocated work is easier,
reality is often different. Companies distribute their offices and partners
globally and people who run projects need to find ways to collaborate
remotely. With the advent of new technology, this movement will only
grow.
We, the authors, have experienced the challenges of distribution. Cultural,
temporal, and geographical distances make collaboration more challeng-
ing.
Teams need to form a certain team spirit or team culture. Why are they
a team? What values are important to them? What are they working on?
Separation among team members influences team spirit. If members are
separated by distance, they have fewer chances for live meetings. Time
differences make it a challenge to meet online. Cultural differences influ-
ence the way they collaborate, often resulting in miscommunication and
misalignment.
Different teams may be working on different products in a product port-
folio or together on one product. The more distributed the teams, the
stronger the need for strong governance. Underlying the products is
architecture. Roles like product owner, portfolio manager, and Scrum-
Master are assigned based on a delicate balance of skill, knowledge, and
location. Organizations need to decide where to form what roles in order
to achieve company goals.
Our backgrounds are in IT. The IT industry is at the forefront of explor-
ing how to work in distributed teams. Over the past decade, people have
found that the Agile Manifesto helps in developing better software. Agile
also helps people communicate and collaborate better. Although the man-
ifesto holds that “face-to-face communication is better” (which implies
collocation), there are many reasons agile works well in distributed teams
too.
In this book, we assume that you already know the basics of agile. If not,
it will help you to read some other books or blogs about agile. We also
assume you (will) face challenges in distributed work and are looking
for solutions. Our book provides solutions that are framework agnostic,
meaning we don’t favor Scrum or LESS or SAFe or kanban over another
framework. We believe the power of agile is in shaping a different cul-
ture, mindset, and way of working. That’s the basis for making distrib-
uted teams work better. Having said that, some of the practices shared
by people in the field (described later) may be biased towards a certain
framework.
Authors

John Okoro is the creator of Auspicious Agile and he has founded ag-
ile-services practices for Rally Software in Asia and for a US management
consultancy. With nearly a decade using agile methods, he is expert at
using agile practices and methods at enterprise scale and in large and dis-
tributed organisations. Okoro is a frequent speaker at agile and industry
conferences and contributes to InfoQ on agile and DevOps. He has con-
sulted in multiple industries for numerous Fortune 500 and Global 1000
companies, including Disney, Toyota, and Accenture. He is experienced
with startups, entrepreneurial ventures, and US government clients.
Okoro is a certified trainer for Scaled Agile and ICAgile, and is certified
by Scrum Alliance. He also teaches enterprise agile scaling at National
University of Singapore (NUS) and as part of the Singapore Skills Future
Initiative.
Savita Pahuja has expertise in Scrum, lean, kanban, and other visual dis-
covery methods. She started her journey in the IT industry as a developer
and contributed to an organizational adoption of agile. She then moved
into the agile world as a consultant and trainer. She has been working
with clients on agile adoption and provinding training on Scrum and
kanban.
Hugo Messer has been building and managing teams around the world
for over 10 years. His passion is to bring together people who are spread
across cultures, geography, and time zones to cooperate. Whether it’s off-
shoring or nearshoring, he knows what it takes to make a global collab-
oration work. He’s the owner of Bridge Global, a global software power-
house, and Ekipa, an agile consultancy in Indonesia. Messer has written
six books about managing remote teams
Contents
What Is Distributed?.......................................................1
Why This Framework?................................................... 2
Overview of the Framework......................................... 3
Questions.....................................................................................................4
Virtues..........................................................................................................4
Communication......................................................................................... 5
Introduction........................................................................................................5
What do we mean by communication?........................................................6
How does communicating with a distributed team differ from
communicating with a local team?................................................................6
Questions..............................................................................................................7
Virtues...................................................................................................................7
PRACTICES........................................................................................................8
Tools to spread knowledge and communicate company-wide,
by Rajiv Mathew.................................................................................................8
A company-wide communication rhythm, by Hugo Messer............. 10
Bring together key team members at the beginning,
by Savita Pahuja............................................................................................... 11
A guide to sprint retrospectives with a distributed team,
by the RealtimeBoard Team......................................................................... 13
Culture.......................................................................................................16
What is culture?............................................................................................... 16
How culture influences collaboration in distributed teams............... 17
How to work with the cultural differences............................................. 19
Questions........................................................................................................... 20
Virtues................................................................................................................ 20
PRACTICES..................................................................................................... 21
Hire for empathy, by Hugo Messer............................................................ 21
The Culture Canvas, by Hugo Messer...................................................... 23
The Culture Map, by Hugo Messer........................................................... 24
Spread the values that matter, by Hugo Messer..................................... 25
Working agreement........................................................................................ 26
Team alignment and Team Canvas, by Savita Pahuja........................... 27
Product.......................................................................................................28
Introduction..................................................................................................... 28
Questions........................................................................................................... 29
Virtues................................................................................................................ 29
PRACTICES..................................................................................................... 31
Stimulate empathy for the product, by Hugo Messer........................... 31
User research in a distributed environment, by Savita Pahuja.......... 32
Product-visioning workshops with the whole (distributed) team,
by Savita Pahuja............................................................................................... 33
Online user-story mapping, by Savita Pahuja......................................... 35
Regular backlog refinement and planning sessions with the
whole team, by Savita Pahuja....................................................................... 36
Conclusion........................................................................................................ 37
What Is Distributed?
Let’s first define what a distributed team is. From our perspective, as soon
as the people you closely collaborate with are not sitting in your office
building, you’re distributed. The simple drawing made by Johanna Roth-
man illustrates four variants:

In this book, we don’t deal with the challenges of collocated teams. Of

course, some of the challenges we describe also exist in collocated teams
but the challenges are magnified in distributed teams. The distributed set-
up above depicts cross-functional, collocated teams more than 60 meters
apart. The silo’d setup means functional teams (e.g. a team of developers
or a team of testers) are collocated, while other teams are at other loca-
tions. The dispersed setup has all or most team members working from
different locations. Everyone is remote in that case. Our book deals with
distributed, dispersed, and silo’d setups.

1
Why This Framework?
We started developing this framework because we personally struggled
to make our distributed teams work. And we see this all around us. The
agile world currently offers many frameworks that help on the team level
(Scrum, kanban) or on the organizational level (SAFe, LESS). All of these
frameworks touch on the topic of distribution, but they don’t offer spe-
cific solutions.
Our framework is based on the understanding that there is not a single
path that distributed organizations can follow for success. It’s more like
juggling balls in the air: you throw one up and another falls down; hope-
fully they don’t hit the ground, but sometimes they do. Making distribut-
ed teams work is about identifying challenges, experimenting with solu-
tions, and constantly iterating.
The key is to learn from other people. Therefore, we have decided to out-
source a big part of the wisdom in our framework. The practices are all
sourced from practitioners. They describe what worked for them in their
context. You can experiment with their solutions and see what works for
you.

2
Overview of the Framework
Our framework consists of six bubbles that cover all aspects that have an
impact on distributed organizations.

The bubbles our framework covers are:

1. Communication
2. Culture
3. Product
4. Leadership
5. Teams and Tools
6. Organization

3
In this minibook, we’ll dive into the first three bubbles of the framework.
The other three will be available at a later stage.
Within each of the bubbles, we have described questions, virtues, and
practices.

Questions
As people get to work every day, we slip into “business as usual” mode.
Although frustrations about (distributed) work pop up, we’re often not
aware of the sources of our problems. To help create this awareness, we’ve
developed a simple set of questions within each bubble. Organizations
can use these to assess their current stage of distributed agile practice.

Virtues
Effectively bridging geography and culture depends on human behavior.
Tools or processes can’t replace that. We believe that personal, compa-
ny, and cultural values will drive behavior so we have developed a set of
virtues to stimulate the kind of behavior that fosters distributed collab-
oration. In each bubble, the virtues describe what people can do to make
things better.
As leaders, we can stimulate those virtues in our teams. As individuals, we
can stimulate these virtues in ourselves and our colleagues.

Practices
We learn from people that have solved the challenges we are facing. A
book developed by one guru contains the experience and knowledge of
that person. Wisdom shared by hundreds of people contains a broader
knowledge base. And the domain of agile, technology, and distributed
work rapidly changes. To help you learn faster and keep up with the pace
of change, we gather practices from experts globally. The practices are
open source. You can contribute and consume. The practices in this book
are a selection of the practices we’ve collected on our online platform.

4
Communication
Introduction
Communicating within distributed teams is challenging for most people.
Communicating with people in our own country with whom we share
a language, culture, and many other similarities is already challenging.
With people from another country, time zone, culture, and language, it
is even more challenging. When asked why a distributed project has not
proceeded as expected, people often name communication as the main
reason.
Remote communication can be both enjoyable and frustrating. We still
love opening a computer, starting Skype, and talking with colleagues
from India, Indonesia, Ukraine, or Sweden. We find it exciting to share
with a development team in India the many things we have learned from
talking with people who work in Latvia or Ukraine. We enjoy having a
Monday morning meeting with team members from three locations and
deciding our strategy for the week.
Completing projects with team members in different countries is highly
rewarding. At the same time, we have also been misunderstood by the
other side — and have ourselves not understood what is happening there.
If one of our managers in India is unsatisfied, and we need to figure out
what is going on, it is more difficult to resolve through Skype than it
would be locally. Her perspective is also different from ours, so it takes
skill and practice to understand. It is frustrating when we thought we had
clearly communicated our ideas for a certain function or design only to
receive two weeks later something that is entirely different from what we
had had in mind.
Through practice, we learn how to communicate. This was true when we
were kids, and it is still true as adults when we find ourselves in a new
team with people from different locations who are using tools instead of
face-to-face communication. If we focus on the frustrating parts, it be-
comes difficult. However, if we view it as enjoyable, we will find ways to
make it work. If we are strong communicators and/or lucky, and we have
the right team with remote work experience, team communication may
even work as easily as if the team members share a local office.

5
What do we mean by communication?
We think everything people do in business is some form of communi-
cation. We continually communicate in different forms (e.g., writing,
speaking), through different media (e.g., e-mail, Skype, Slack, Whatsapp,
Messenger) and on different levels (e.g., chit chat, operational, reflective,
strategic). Communication is influenced by many subtle factors such as
the participants’ cultures and accents as well as whether they are intro-
verted or extroverted. Because communication covers such a wide spec-
trum with so many variables, focusing on communication per se is not
the solution to making distributed collaboration work. We need to look
at other aspects.

How does communicating with a distributed team

differ from communicating with a local team?
In many ways, distributed communication is not different at all from local
communication; in other ways, it is very different. Individual members
of distributed teams lack facetime in the office. Facetime with colleagues
allows the opportunity to bond and to chit-chat about things that matter.
Remote team members who lack facetime do not have the same chance
to build strong bonds as those who see each other regularly, resulting in
a weaker understanding of one another’s motives. Even if we use video
conferencing to “see” each other, we may miss emotional cues.
At the project level, we miss chatting at the coffee machine about the task
we are working on together. We miss the brainstorming sessions about
the product we are creating and the clients we are serving. This lack of
face-to-face communication strongly affects the level of understanding
that remote team members have about the product, its purpose, and the
clients who use it.
At an organizational level, we miss the inspiration gained from talking
with the company CEO over a beer at Friday night gatherings. We miss
the way the core values of the company influence the behavior of the peo-
ple working within the onshore office.
To bridge these divides, we need to give more thought to remote commu-
nication. When we communicate with people in our office who are from
the same culture, we do not experience (high) conversational barriers.
However, when we speak with remote colleagues from another country,
we have to think more deeply about the forms, media, and levels of com-

6
munication we choose. Let us look more closely at how we can go about
this.

Questions
To assess the current state of communication within your distributed or-
ganization, the following questions are helpful:
• Do we have a communication rhythm at different levels of the orga-
nization (strategic, operational, team)?
• What agenda do we follow in our meetings?
• How do we make (work) progress transparent?
• What type of communication is supported by what tool?
• Do we have empathic facilitators?
• Do we substitute water-cooler chat with anything and if so, what?

Virtues
• Align: Create a communication rhythm at all levels
• Match communication modes with the right tools
• Facilitate the discussions
• Inclusion
• Transparency
• Openness
In order to make an organization agile, we need buy-in and support at
different levels, especially from leadership and management. To make a
distributed organization work smoothly, such alignment is even more
important. On the team level, agile has built-in meeting rhythms. It helps
to add a communication rhythm at the managerial and leadership level; a
quarterly strategic meeting or a monthly product-ownership meeting are
some examples. Alignment is key.
There is an abundance of tools for communication. Many people still rely
on traditional media like e-mail and phone calls but those are not always
the most effective tools. Big enterprises also restrict people from using
modern tools. We believe it’s crucial to consider using tools that can im-
prove communication. Teams can self-select their tools or organizations
can make metrics to match certain types of communication with the best
tools available.

7
A strong facilitator helps create meaningful discussions. Distributed team
members in a video conference are often uncomfortable talking in a dif-
ferent language with people they have never met. An effective team has
equal talk time for every team member. Effective teams have a clear agen-
da and timebox for their meetings. A facilitator can ensure this happens.
Including everyone affected by a certain discussion topic in a meeting
helps spread the right knowledge. As remote people miss water-cooler
chat and customer interaction, it is paramount to include them in all im-
portant communication. Transparency is one of the key agile values, so
agile distributed teams need to let everybody see what is going on. Shar-
ing product-vision boards, strategic plans, and product backlogs helps
spread important information across the distributed organization. Open-
ness empowers people to help each other solve problems and promotes
better understanding among team members. Sharing everything that’s
important with your peers fosters effective collaboration.

PRACTICES

Tools to spread knowledge and communicate

company-wide, by Rajiv Mathew
Software development is all about people. You need effective communica-
tion channels that help people work together to achieve the vision of your
firm. Over my past decade of work in the IT industry, I have come across
some wonderful tools that have helped software teams overcome their
communication challenges. Let us look at a few of them.
Newsletters
Sending a quarterly newsletter to the entire organization is useful because
it provides employees with an overall perspective of the company and its
projects. Inviting employees to contribute to a newsletter gives them a
forum in which they can express their views. Newsletters regularly sent
from the human-resources, finance, administration, and marketing teams
helps the development team gain a wider perspective of what is happen-
ing on the operational side of the company.

8
Intranet
The intranet is an effective tool for communication in the workplace. One
of the companies I previously worked with used the collaboration plat-
form Jive, which lets developers effectively share best practices on proj-
ects. My current organization uses Yammer, another great option. The
advantage to using a platform like these is that it helps with knowledge
management. Think of it as a Facebook clone within an organizational
setup. The intranet is the best place to share technical insights on various
projects so that knowledge does not remain tacit in nature.
Company websites
Even though the corporate website is an external-facing medium, many
team members visit the website often for company updates and news.
Featuring developers on the company website adds a sense of belong-
ing and thus increases employee engagement and retention. I have often
posted press releases and multimedia on the corporate website and then
sent links to the developers so they can read about what is happening in
the company. If your onshore client has an extended team offshore and
you are a partner, you can use a micro-site to communicate information
to your team. I remember using Google Pages as a micro-site to create
and share information with a partner many years ago.
Storyboards
A storyboard is an excellent way to communicate the vision of a proj-
ect or product to the entire development team. Even complex problems
can be broken down into simple sketches so that everyone understands
them. Whiteboarding ideas and having developers use the storyboarding
methods helps on all kinds of projects. If you have a distributed team, you
can do this via Skype with online storyboarding tools such as Storyboard
That.
Process-flow diagrams
When developers build a platform, explaining the user flow or the process
flow is critical to understanding how the system is supposed to operate.
Once the process flow is clear to the developers, development would most
likely be easy. This is where you also make use of wireframes to demon-
strate the interaction flow using click-through prototypes.

9
Twitter
My teams have created hashtags for certain technical topics in the past,
and then developers — including those from other companies — have
provided multiple insights for solving problems. It is an interesting social
experiment to try.
Live feed
When working on a big project that involved more than 100 developers,
we used Skype for a group chat in which team members posted updates
for the day. Colleagues could observe the updates on a big monitor. The
experience felt much like watching the big TV screens in stock markets!
The 30-second rule
Another tactic that often works is to use the 30-second rule while com-
municating with development teams. If you can respond to a message
within 30 seconds, then you should do it. If you can respond to a devel-
oper’s query instantly, he or she will be more efficient. This holds true
for any client-related communication. Faster replies make clients feel that
you are fully engaged on the project and on top of things at all times.

A company-wide communication
rhythm, by Hugo Messer
Depending on the size of the company, people involved in remote collab-
oration communicate at least three levels: strategic (CEO), process (proj-
ect or process managers), and operational (ScrumMaster and team).
Agile has a set of meetings scheduled on the operational level. The product
owner, ScrumMaster, and team members are involved in the sprint-plan-
ning, demo, and retrospective meetings. The ScrumMaster and team
members manage the daily stand-up (involving the product owner when
needed). I have learned that this meeting rhythm is absolutely crucial to
and beneficial for distributed collaboration. When teams do not use this
rhythm — especially the daily stand-up — things quickly slide down a
slippery slope.
In most cases, the product owner is local and the ScrumMaster and team
are remote. By following the Scrum meeting rhythm, both shores auto-
matically communicate daily. This increased communication allows the
team to continuously adapt, remove hurdles, and create bonds between
all members.

10
In my company Bridge Global, we have learned that the role of process
manager is crucial. We have an onshore account manager and an offshore
process manager. Ideally, the customer also assigns a process manager
(this can be the product owner or the manager who is responsible for the
success of the collaboration). These three managers attend weekly Skype
calls that last about 15 to 20 minutes in which they discuss alignment:
Is the team on track? Are they communicating effectively? Are they still
following the agreements that were initially made? What is going well and
what could be improved? This information is then stored (e.g., in Google
Docs or Atlassian Confluence) and shared with the entire team so that
each week, the collaboration improves a little more. We also give a grade
on a scale of 1-10 that answers the question “How happy are you with last
week’s collaboration?” (Back and forth!)
The top level communicates every four to eight weeks. In the initial stages
of collaboration, it is recommended that they meet at least once every
four weeks. They discuss the progress of the strategic objectives of the
partnership: Are the KPIs still on track? Are we providing value to one
another? Do we have synergy? Do we work well together? What are the
plans for future collaboration?
For example, a big Dutch/Swedish telecom company assigns what they
call a “change manager”. They always have one local change manager
from their company and one from the partner’s side who is remote. These
change managers communicate weekly. The product owners report to the
change managers to keep them informed of the project dynamics. Every
three weeks, the operational managers meet to communicate progress
and the achievement of operational objectives. A meeting is held at the
strategic level every six weeks. This schedule results in continuous com-
munication and adaptation on every level and fosters deeper ties that re-
sult in a long-lasting partnership that increases in value as time passes.

Bring together key team members at

the beginning, by Savita Pahuja
Proper initiation of a project is important for smooth execution later.
Members of newly formed teams need some time to come to understand
each other and best collaborate. This process is more complicated in dis-
tributed teams whose members are not physically together.

11
According to the theory of communication richness shown below, face-
to-face communication is the most effective form of communication.

It follows that distributed teams should always look for ways to increase
face-to-face communication and when starting an agile project, it is ben-
eficial to bring together team members from different locations to allow
them to communicate in person. In the beginning, the team should work
together on initial modeling, understanding high-level user requirements,
technical strategy, and risk assessment.
We should not stop face-to-face communication after starting. From time
to time, our people should travel to meetings and we might think about
rotating team members among locations — this might be expensive but it
leads to a high-performing team.
Share the pain of time-zone difference
Agile teams practice multiple agile/Scrum meetings such as daily stand-
ups, planning sessions, reviews, retrospectives, and backlog refinements.
We recommend holding joint meetings and sharing the pain of time-zone
difference by taking turns to compensate, either getting up early or stay-
ing up late.

12
After repeatedly staying late for meetings, people start missing these
meetings, and this harms team communication. I have seen many teams
in this situation and figured out the pattern: after a few initial sprints,
team members start to hate daily stand-ups or other meetings for which
they need to stay late.
Find a common language of communication
People cannot properly communicate if they do not understand each oth-
er’s language. It is crucial for the team to agree on a common language
for team communication. English is the most commonly used global lan-
guage but there are some exceptions in, for example, Japan, China, etc. For
scenarios in which there are language differences, there are a few options:
Learn a new language. Encourage the team to learn another language.
However, many times people are not open to learning a new language and
it is also difficult to excel in a new language in a short amount of time.
Use a translator. The team can use a translator who can speak the re-
quired languages, but a single translator could create more dependency
and block effective communication. Additionally, this option is expensive.
Use translation tools. The team can use one of the many capable transla-
tion tools for conversations.
Sometimes, even after deciding on a common language of communica-
tion, people cannot understand each other’s accents. To overcome this
challenge, companies provide training to listen to and understand the ac-
cents of people from different countries.

A guide to sprint retrospectives with a

distributed team, by the RealtimeBoard Team
As teams become more distributed, running sprint retrospectives be-
comes challenging. But this is not a reason to quit doing them. Here are
some tips from RealtimeBoard and Lieuwe van Brug from Lerni.io, who
has practiced running retrospectives with distributed teams many times.
Step 1: Attendance and engagement
Be creative and surprise the team while organizing the retrospective —
you’ll get a lot of different feedback.

13
Retrospectives are a lot about emotions, attitude, etc. This is easily lost
in a distributed environment. To solve this — partially — you could use
good cameras and make sure everybody is visible during the retrospec-
tive. Asking more explicitly about emotional subjects can improve the
situation as well.
Step 2: Sprint review
Choose subjects you want to focus on during a retrospective — one sub-
ject per sprint. If you focus on different subjects every sprint, you donʼt
get the same problems mentioned every time.
Step 3: Discussion
Itʼs important to catch everyone’s opinions. One of the things you can do
is to give everybody a personal part on RealtimeBoard. Copy the visuals
you are going to use during the retrospective per person and let every
person zoom in on their personal part of the board. In the discussion
rounds, assemble all input to a central place on the board. This way, you
make sure everybody is heard.
Step 4: Actionable commitments
Make sure that you prioritize what to solve in one sprint. Small achiev-
able goals work better and are sustainable over longer periods of time.
A tool that will help you to go through all these steps with the distribut-
ed team is an online whiteboard. It offers all the benefits of a traditional
whiteboard, while giving all participants an unhindered view with the
ability to add and edit information in real time. To start your next retro-
spective, just choose one of templates, some of which are discussed below.
Template 1. Start, Stop, Continue
Participants identify actions that they want to start in the next iteration,
and those from the previous iteration that they want to stop doing or
continue with.

14
Template 2. Glad, Sad, Mad
Each participant is given the opportunity to describe their observations
and place it on a whiteboard. The whiteboard is divided into three cate-
gories: Glad, Sad, and Mad.

Template 3. Sailboat
Here a sprint is compared to a sailboat. The team records things that
helped the sprint move forward or slowed it down, and places them either
on the sail or below the boat, indicating that they are anchors or wind.

15
You can read the article in full and find additional tips and templates on
the Realtime Blog.

Culture
Most distributed teams consist of people from different cultures, working
from their home country. While working remotely is itself a challenge,
cultural differences influence collaboration beneath the surface. As ide-
alists, we may believe we can work with anyone from any culture, but
after some time, we might realize that we’re not truly understanding each
other. Culture influences communication through different beliefs about
openness, responsibility, hierarchy, and work in general.
As the title of the article implies, we believe that teams need to “manage”
cultural differences. It’s not something that we can or should “overcome”.
And it’s also something that can be seen as positive, as bringing additional
viewpoints to a team.

What is culture?
It’s not always clear what we mean by “culture”. It can refer to habits with-
in a group of people from a certain country, from a single company, or
from any other distinctive group.
Within a country, people form certain behaviors; different values and
norms that shape how we act and we communicate in different ways. But
we are often not aware of this and we fail to recognize other people’s be-

16
havior within the context of their own culture. While the national culture
influences collaboration, the solutions to intercultural challenges lie at
the company and team level.

How culture influences collaboration

in distributed teams
Our experience at the team level has shown us that culture influences how
we collaborate in various ways.

If our teammates have a local mindset, they might prefer to work with
people in their own city, speaking their own language. What distributed
teams need, however, is a global mindset, where people are interested in
getting to know the others involved and learning about their cultures.
Having too many people with a local mindset on your distributed team
runs the risk of creating an “us versus them” mentality: “We over here
flock together and we know how stuff works. Those people over there
make all the mistakes and they don’t understand what we need.” This type
of attitude often derails the whole team.
Task versus relationship orientation
People in the West (especially in the US) are often task-oriented and
goal-oriented. They want to get their stuff done. People in the US, for
example, may make quick decisions on hiring a certain vendor. If the ven-
dor has what they need, they can quickly decide to give it the project. (Of
course, this isn’t always the case as, for example, US government contracts

17
can take a long time to resolve.) If the vendor screws up, the company will
as easily pull the project back.
In Asia, people are very social and believe in building long-term relation-
ships. They want to know with whom they are going to work and would
rather spend several months cultivating a relationship before granting a
project to a new vendor. But within Asia, there are vast differences. Hugo
Messer has recently moved to Indonesia and has noticed that people in
Jakarta move very fast. After a first talk, people ask for proposals and con-
firmations follow within days.
European culture lies somewhere in between (with vast differences be-
tween the countries in Europe!).
Level of openness
Another big influencer is the level of openness. Do we keep opinions to
ourselves or will we easily voice them? Here we again have a West/East
divide. The Dutch, for example, are very open. People in Asia tend to be
less open, especially when authority is involved: contradicting a boss or
project manager may be seen as disrespectful.
If our boss is in the West and we’re in the East, our Western boss might
keep asking us to be more open or proactive. And that might confuse us
because we’re not used to being encouraged or even allowed to voice our
ideas. If our boss tells us “This is the way to do it,” we’d rather do that ex-
actly, even if we think it’s a crazy idea.
This behavioral difference impacts most of the agile ceremonies. For ex-
ample, if a product owner asks in sprint planning if we can take more user
stories, people in some Asian cultures tend to always say yes regardless of
their actual capacity, which defeats the whole purpose of planning. Sim-
ilarly, in retrospectives, people in these cultures hesitate to share their
challenges and problems — for example, to avoid offending a superior.
Note that this is one reason that it is not recommended to have the team’s
superiors present at every retrospective.
Tendency to always agree
An interesting case of culture, often discussed in global organizations, is
Indians’ tendency to always say yes. Ged Roberts of TCS wrote an article
in one of Messer’s e-books titled “Cultural Differences or How I Managed
to Learn to Work with Both Dutch and Indians Without Losing My Hair”.
The following excerpt describes the “yes” well:

18
 “When I first started working for an Indian company, I was given a very
sound piece of advice. I was told the following: “Ged, there are three ways an
Indian person will say ‘yes’ when asked whether they can do something, and
the response will mean one of the following:
1. Yes, I can do that.
2. Yes, I can do that (it will take me 19 hours per day but I can do that).
3. Yes, I can do that (actually I can’t do that, but you are the customer and
I cannot say no to a customer).
If you wish to be successful in any relationship with an Indian company,
your challenge is to understand which version of “yes” you have just heard.
When we probe deeper, mainly into the version #3 of “yes”, we find a number
of cultural items at play. The first aspect is the extreme levels of customer
focus and customer centricity which plays within the Indian psyche. Con-
cepts of “the customer is always right” and “the customer pays our wages”
(management just handles the money) are prevalent throughout the culture.
The second aspect is that there is an assumption that someone will always
say “yes”. Consequently, if you want the business, or you want to maintain
the relationship, then saying “yes” ensures that that relationship stays with
you. Although there is the worry that the commitment is given without any
thoughts to the consequences, this relentless level of customer focus has lead
to some quite amazing achievements. The Indian’s unremitting drive to hon-
or the obligation is breathtaking and far more often than not, the goals are
reached. In reality, many times, the version that you hear is not version #3
or version #1, but version #2.”
This kind of behavior hampers collaboration and trust between distribut-
ed teams. It also obscures the transparency within a team that is the core
of agile teams.

How to work with the cultural differences

The above shows that culture is relevant. It impacts organizations, teams,
and outcomes. To work with the influence of culture, we’ve developed a
set of questions that organizations can ask. These questions help create
awareness of the impact of culture. It also helps identify any possible pain
points. We’ve also defined a set of virtues: behaviors that help organi-
zations manage cultural differences in distributed teams. And we’ve de-
scribed some practices that can be used to address culture.

19
Questions
The questions below are a good starting point for cultural awareness.
They are best used in a facilitated team session with people from the re-
spective cultures. They can also be shared online as a survey or in a Trel-
lo board (columns with questions, tickets with answers and discussions).
They are meant to be played with.
• Are we experiencing impact from cultural differences?
• Do we have an “us versus them” paradigm?
• How do we deal with differences?
• What will we do to get the differences to the surface?
• How comfortable is each culture with being open, sharing matters of
mind and heart?
• What’s the impact of cultural differences if we’re collocated versus
distributed?
• How much hierarchy do we have in our organization?
• How does each culture perceive hierarchy?
• How much self-organisation do we expect?
• What can we do to get everyone on the same level of self-organiza-
tion?
• To what degree does language have an impact?
• Does everyone have the same understanding of saying no?

Virtues
There’s a handful of behaviors that help people with cultural differences
effectively work in a multicultural distributed team:
• Empathy: Accept differences, jam with them
• Awareness: Become aware of the differences
• Openness: Share what’s on your mind
• Trust people more than process
• Transparency
Awareness of cultural differences is the starting point to acceptance.
Once we become aware that certain behaviors originate from other peo-
ple’s cultural background, we generate understanding. With this under-
standing, we can move on to accept the differences as a fact of our situ-

20
ation. Based on this acceptance, we can find ways to organize work with
or around differences.
Empathy means “putting ourselves in the shoes of another person”. People
with high degrees of empathy tend to be good listeners. They are strong
at experiencing and feeling what someone else experiences and feels. This
heightened understanding helps people better collaborate across cultures.
Complete openness (or honesty) means that when we have an image
about something (an object, a situation) in mind, we share that image with
others exactly as it appears in our mind. We’ll share any information we
have in our minds. We will not change or hold back anything that matters
in this situation. Openness helps people understand each other. It helps
teams inspect what’s going on and adapt in order to achieve the outcomes
they’re after.
Transparency is the key to building trust among team members. Being
distributed makes it even more important to be transparent, to share
achievements as well as challenges and co-create the solutions. If some
discussions and acts of any team member do not resonate with our cul-
ture, we need to be transparent and share our perspective.
We create processes to bridge cultural gaps, but we need trust to make
processes suited to our work style — trusting people has more value than
following processes.

PRACTICES

Hire for empathy, by Hugo Messer

If our team consists of people who are only data-oriented and focused
on getting stuff done (e.g. writing code) and not on fostering and under-
standing relationships, we might face a lot of miscommunication. Our
team will feel not like a single unit but rather like a collection of indi-
viduals scattered around the globe. To counter this, it helps to hire some
people with high emotional intelligence, particularly when it comes to
empathy. Paying attention to gender balance can affect this.
In my experience, leadership must stimulate empathy on several levels, as
shown in this graph:

21
1. Country
By organizing training that addresses culture in group discussions, lead-
ership stimulates understanding within the team. Given the chance to
empathize with another culture, people will naturally better understand
the behavior of people from that culture. People will better understand
why I behave X and you behave Y. Based on that understanding, we can
organize around the perceived differences as a team. We can discuss
them and find ways to deal with them. This eventually leads to effective,
well-balanced teams.
2. Company
Especially if the setup is headquarters in country X and remote team
members in country Y (and others), it’s important that leadership stim-
ulates understanding about the company itself. People at the headquar-
ters automatically feel closer to the company’s mission and value system.
They’ll discuss it over coffee, they meet the leadership team regularly,
they have more company parties, etc. But remote team members need
to be engaged too. A specific program to spread the culture needs to be
designed, planned, and executed.
3. Product
People far away don’t (often) talk to users of the product they’re building.
They don’t have coffee chats with the product owners. They may even
lack the context of the product (for example, if we’re developing an in-
surance product, my country might have a completely different insurance
system). It’s crucial to encourage remote team members to understand

22
everything about the product. This may include meetings with the users
of the product, trips to the headquarters, videos to transfer knowledge,
and more.
4. Team
Finally, leadership can encourage the team to form bonds within their
teams. Allow a budget for training or trips. Allow teams to take time off
work to do exercises together, to discuss off-work topics. Our webinar
participants recommend that quarterly gatherings would be the optimal
frequency with which to bring everyone together at one location.

The Culture Canvas, by Hugo Messer

Another useful tool is the Culture Canvas. The distributed team members
fill out these diagrams together (ideally in one space).

As a Dutch team member, I would fill this in regarding the collaboration

with my colleagues in, for example, India. I’ll take the perspectives and use
sticky notes to show how I consider my Indian teammates. I’ll indicate
what pains and gains I derive from the collaboration, etc. I might write
that I have a lot of gain from the creativity my Indian team brings to my
project, as this helps me deliver a better product to my customers.
My Indian teammates will in turn fill out a Culture Canvas for me. They
might say that they consider me to be very open. In a way, they gain from

23
this because they know what’s going on. But they may sometimes feel
hurt because I come across as blunt.
After colleagues from both cultures have filled the canvas (and, yes, it re-
quires openness from both sides — so you may want to do some warm-up
exercises before doing this), we can compare the results. We can list the
top five issues we identified and discuss ways to deal with them. What
could we change in our communication or in our process to avoid the
issues going forward? Or, could we introduce some specific tools to help
us improve?
This Culture Canvas is inspired by the empathy map of Alexander Oster-
walder.

The Culture Map, by Hugo Messer

Alexander Osterwalder created a tool called the “Culture Map”. The Cul-
ture Map is a good variant of the above canvas and is meant to clarify
corporate culture, but it’s generic enough to apply to intercultural col-
laboration.

We start by mapping behaviors in the second row. In this box, we have to

map how our team acts or conducts itself within the company. What do
we do or say? How do we interact? What patterns do we notice? Some ex-

24
amples are: “Although we are self organizing teams, not everybody takes
up work equally,” or “Not everyone is openly saying ‘no’ when asked if
they don’t understand something.”
Next, we map our outcomes. What are the concrete positive or negative
consequences of the behavior we’ve mapped? An example is: “The behav-
ior of not taking up work autonomously by some team members leads
to unproductive teams and unfulfilled sprint commitments. Because not
everyone is open about not understanding certain user stories, time is lost
during the sprint for clarification. And often things are built that were not
completely what the product owner had in mind.”
We finish by mapping our enablers and blockers. This is where the Cul-
ture Map gets really interesting. In mapping enablers and blockers, we
have to record all things that lead to the positive or negative behaviors
inside our company. What policies, actions, or rules are influencing em-
ployee behavior — and ultimately influencing our company’s outcomes?
Some examples of blockers are a poor bonus system or no budget for
sticky notes. Some examples of enablers are a smart management team or
a well-made metrics dashboard.
We can ask all team members to fill this map individually and then dis-
cuss the results. Or we can do it as a facilitated group exercise (and maybe
hire Osterwalder to lead the exercise?). Once we’ve mapped out all the
negatives, we can start reshaping the culture. We could come up with be-
haviors that will produce the outcomes we’re after. We could reorganize
work, policies, salary systems, tools, etc. that promote the behaviors we
want, which result in the outcomes we’re after.

Spread the values that matter, by Hugo Messer

When I started my company in 2005, I had no experience with intercul-
tural teams. One of the first things I did was to sit with my Indian team to
define what values everyone had in common. In a session of several hours
and some iterations, we defined six core values for Bridge Global. These
core values are still in effect today. Throughout the years, we found that
two of these values have had the biggest impact on working with distrib-
uted teams: openness and entrepreneurship/responsibility.
Indian culture is less open than Dutch culture. By making openness a
core value, we’ve always been able to attract people in India who are more
open than average. We’ve created an onboarding program in which ex-
isting colleagues share how openness and other values have helped them

25
work with colleagues and customers and how openness has led to person-
al growth and creates the outcomes the company needs. In collaborations,
people share what’s on their minds. They ask questions if requirements
are not clear. They discuss openly what bothers them.
Entrepreneurship has led our people to feel accountable for the results of
their work. We put our people in front of customers from day one (where-
as many Indian companies hide workers behind project managers, team
leads, and other roles). Our people get direct feedback from customers in
the form of monthly ratings. Their salaries even depend on that rating. So
people deliver and don’t hide behind their superiors or colleagues.
By defining what behavior is desired, organizations create clarity. If de-
fined clearly, the behavioral values work across cultures. We can then use
these values to give people feedback on their performance and behavior.

Working agreement
People in different cultures have different takes on punctuality so distrib-
uted teams that have common meetings across locations need to consid-
er other team members’ attitude toward timing. For example, in North
America and in India, being on time typically includes a five-minute grace
period because of traffic and transportation hiccups. In contrast, being on
time in Germany means arriving five minutes early.
When Savita Pahuja works with teams, she helps team members create
working agreements. A working agreement is a set of standards that the
team creates and promises to follow without fail to make members more
efficient and successful. It is a powerful technique born of a discussion
that reveals different mindsets and behaviours and helps people find
common ground. Teams use a working agreement to schedule Scrum
ceremonies with punctuality grace periods and to determine what will
happen if someone doesn’t follow the standards.
A working agreement is also helpful to assess team members’ assump-
tions and to have them question why they hold those ideas or beliefs. By
doing this and discussing with others, the initial barrier to intercultural
communication can be overcome.

26
Team alignment and Team
Canvas, by Savita Pahuja
It is difficult to get every team member to change how they think over-
night. Rather than trying to build understanding about agile methods as
a full set, first align everyone on goals, values, roles and skills, and rules
and activities. This is a good way to avoid conflicts in a team. Alex Ivanov
and Mitya Voloshchuk offer a model called the Team Canvas for team
alignment.
The Team Canvas is the Business-Model Canvas for teamwork. It is a free
tool around which leaders, facilitators, and consultants can quickly orga-
nize team-alignment meetings to unify members, resolve conflicts, and
build productive culture. Ivanov and Voloshchuk say that their experi-
ence and research into company cultures have allowed them to identify
the key components of self-leading teams: these teams tend to have sus-
tainable creative culture and high performance standards. It is a mix of
purpose, openness, and mastery. Based on these attributes, Ivanov and
Voloshchuk came up with the Team Canvas.

The Team Canvas is divided into Goals, Roles and Skills, Values, and
Rules and Activities.
Goals asks what the goals are for the whole team as well as for each team
member.

27
Roles and Skills asks what roles and corresponding skills each team mem-
ber possesses.
Values asks for the core values that team members share.
Rules and Activities asks for the ground rules on which you want to agree.
How are you going to communicate? How will you make your decisions?
How are you going to plan, execute, and evaluate those decisions?

Product
Introduction
What is a product and how do we define it? Various people give many
definitions; teams can use any definition to define their product. Mike
Cohn, founding member of Agile Alliance and of Scrum Alliance, consul-
tant, author, and founder of Mountain Goat Software, defines a product
as “something (physical or not) that is created through a process and that
provides benefits to a market”.
Having the right definition of product is important for successful deliv-
ery. Large-Scale Scrum (LeSS) describes why it is important to have the
right definition of a product:
The product definition needs to be clarified because it will affect:
• the scope of the product backlog,
• who will be the product owner, and
• the size (in teams) of the product .
Product definition should be broad enough to avoid dependencies be-
tween smaller products.
The second important step is to set up a cross-functional team for the
product to enable the team to deliver end-to-end features without much
dependency from other teams.
Many scenarios can lead us to choose to have a distributed team for the
product:
4. We are building a product for multiple locations and the business
people are located in these multiple locations.

28
5. We already have a product in one location and we’re extending it for
other locations. In this scenario, we should create a cross-functional
team in the target location but we still need help from the business
and developers at the product’s existing location.
6. Due to a lack of the required skill set in one location, our organiza-
tion must hire people in other locations.
There are many more scenarios in which a distributed team builds a sin-
gle product. Whatever the reason, teams face challenges because of dis-
tribution.
Product development is not only properly defining the product but is
also developing it in the right direction. This sense of direction is often
a challenge for distributed teams. Because of the distance between team
members and markets, users and product owners, teams may be left in the
dark. To solve this, we need to use the right set of meetings and tools to
close the distance between teams and the product and its users.
To better understand whether we are successfully managing our product
development with our distributed teams, we should pose the questions in
the following section to ourselves and our team members.

Questions
• Are team members in all locations aligned with business on product
vision?
• Is everyone aligned on the definition of product?
• Do all team members take part in product visioning, roadmap cre-
ation, and backlog refinement workshops?
• Are the product vision and roadmap visible to everyone everywhere?
• Do all team members directly work with business and users?
• Are our multiple teams distributed as cross-functional collocated
teams?

Virtues
To effectively manage products, we have developed a set of virtues. A
distributed culture that fosters collaboration can evolve based on these
virtues:
• Enable all team members to communicate with users.
• Practice product transparency so that roadmaps, visions, and goals
are visible to everyone.

29
• Think from the user’s perspective.
One of the biggest challenges we see in distributed teams is the distance
between team members and the users of the software. In traditional mod-
els, the project manager is the interface between stakeholders and users
and translates requirements to teams. In agile, our philosophy is to reg-
ularly bring together stakeholders, users, product owners, and teams. As
Henrik Kniberg, agile coach at Spotify and Lego, author, and co-owner of
Crisp AB, explains in his famous “Agile product ownership in a nutshell”
video, collaboration ideally looks like this:

But distance doesn’t help there. As a result of geographical and time zone
differences, product owners often play the role of project manager. They
communicate as the go-between with the users and the team. We believe
that having all team members regularly communicate with users via
whatever means is crucial.
Remote team members lack the energy of a head office. They can’t par-
ticipate in lunch breaks, Friday-night beers, and coffee chatter. They also
won’t see our product roadmaps, vision, strategy, etc. if these are purely
physical manifestations. Although it may seem obvious to include remote
workers in your plans, we have seen too many remote teams who were
completely in the dark about the product they were building. Product
transparency means we should use wikis, whiteboards, cloud drawings,
and other online tools to share the energy of a product with all our dis-
tributed team members. It also means we should value regularly gathering
together all distributed team members to update and revise all the prod-
uct documentation.

30
In order for development teams to build great products, they need to
truly understand what they are building for whom. They need to build
products with the user’s perspective in mind. Remote teams may of-
ten just build features invented by someone else far away. Product man-
agers can make a conscious effort to get their remote teams energized for
their product and users. Teams can use workshops, frameworks (e.g. Lean
Startup), interaction, and tools to get a better understanding of who uses
their product and how and why they use it.

PRACTICES

Stimulate empathy for the

product, by Hugo Messer
Empathy is an important virtue for making distributed teams function
productively. I developed an empathy plan for distributed teams a couple
of years ago. I described its use in the context of culture in the InfoQ arti-
cle “Managing Cultural Differences in Your Distributed Team”. The plan
is meant to stimulate empathy at four levels. In the context of the product,
we want teams to be excited about the software they create — to be fa-
natic. Startups and (new) products succeed if their teams are thinking day
and night about their products, their users, and improvements.
Product owners can stimulate this empathy for the product by running
their product like a startup. Team members who clearly see the vision
and roadmap of their product and regularly interact with the users get
more motivated. Let them interview users, let them go into the street to
observe how the software is used, let them attend the meetups or confer-
ences that their users attend. If (part of) the team is remote, it’s even more
important to consciously stimulate product empathy, because the remote
team members miss the action of the head office. A small travel budget
plus strong video and audio conferencing tools can do the trick. Users
can join a short Skype call; they’ll probably even find it interesting to talk
to a foreign team.

31
User research in a distributed
environment, by Savita Pahuja
Our product’s success depends on our understanding of user needs. If
teams build a product without knowing their customers, it could be dan-
gerous for the business.
There is no substitute for inviting everybody from the team to user ses-
sions to build a shared understanding of the user problems. Witnessing
users struggle with the product will motivate people to fix problems im-
mediately.
I particularly like Christian Rohrer’s summary (outlined in the table be-
low), which lays out a three-dimensional decision-making framework
and provides notes about the position in the product development cycle.

We can easily run user-research activities remotely. Conduct remote us-

ability tests through video calls. We can record the on-screen action using
QuickTime or another tool while observing the user’s reactions. We can
use tools like ethnio or UserTesting to recruit users and put our products
in the hands of customers as soon as possible. Run tree tests, card sorting,
surveys, and more with Optimal Workshop.
Remote teams can also set up Atlab, Atlassian’s online user-research lab,
to conduct interviews and usability tests with customers and non-cus-
tomers. This creates empathy for users, and arms design team with in-
sights to make the products more usable and useful.

32
Teams can use online survey tools like SharePoint, forums like Discussion
Board, and social listening to gather user data. Companies have used the
Internet to conduct all sorts of user research for understanding customer
needs. Online surveys are a faster way to collect data from respondents
than other survey methods such as paper forms and personal interviews.
Below is an example of an online survey for a travel company. It consists
of questions about vacation planning by travelers.

Product-visioning workshops with the whole

(distributed) team, by Savita Pahuja
At the start of product development, the team and business create the
product vision in a workshop. It is crucial to include all team members
from all the locations in the creation of the product vision. Non-partici-
pants would find it difficult to grasp the purpose of the product.
The first choice of a business should be to fly its people to a central lo-
cation for this exercise. People who cannot possibly attend should be in-
cluded through some other means.
Many teams like to use physical media to establish vision, and not hav-
ing everyone in the same room could create problems in using physical
methods such as whiteboards or sticky notes on walls. In these scenarios,

33
34
I recommend using online boards like RealtimeBoard with video confer-
encing for better collaboration among remote teams.
If teams are using simple techniques like an elevator pitch or the Busi-
ness-Model Canvas, people at every remote location can create their own
versions and share them online. All groups can use video conferencing to
discuss all versions and converge to one.
When I was building a new product a few years back, we started with a
distributed team right from the beginning. Two of us worked from home
in the Netherlands, four were in India, and one was in Turkey. One of the
first things our distributed team did was to create a Business-Model Can-
vas. Each of us prepared by watching videos about the Business-Model
Canvas and then we each made notes for each block in the canvas.
I facilitated the group session, which took us about three hours. In the
session, I tried to go through the canvas block by block, eliciting ideas
from all our team members. The result was a plan, and everyone thor-
oughly understood the product we thought we should build (we changed
a couple of times). I believe this is a strong start for any team: let the whole
team join the ideation phase, so they understand the idea, the market, and
the cash flow instead of only recognizing features to build. Here’s what
the canvas looked like, built in Canvanizer (see page 34).

Online user-story mapping, by Savita Pahuja

Teams usually use user-story maps for release planning. A user-story map
arranges user stories into a useful model that helps us understand the
functionality of the system, identify holes and omissions in our backlog,
and effectively plan holistic releases that deliver value to users and busi-
ness.
User-story-mapping workshops are collaborative and engaging. The
team needs everyone’s input to make sure all types of features are added
to the backlog.
Remote teams can use online tools like StoriesOnBoard to create story
maps. I use mostly this tool with my distributed teams and it is as effec-
tive as using a physical story map in a collocated team. Below is an exam-
ple of a story map created with StoriesOnBoard.

35
Regular backlog refinement and planning
sessions with the whole team, by Savita Pahuja
Anyone who is part of product development should participate in back-
log refinement, along with a business liaison. During backlog refinement
meetings, teams usually discuss:
• Understanding user stories
• Ordering of the product backlog
• Splitting big user stories into smaller user stories
• Writing acceptance criteria
• Estimating
Going through that list, it becomes clear that we require the whole team
to participate in the discussion regardless of the members’ locations.
To smoothly run refinement meetings in distributed teams, teams can use
video conferencing with online boards like they would for product vi-
sioning. Teams can also use online product-backlog management tools
like Jira, VersionOne, Trello, etc.
Similarly, the whole team should take part in planning by using the same
online tools.
Apart from the above-mentioned practices, teams should focus on these
important activities:

36
• Build a user-feedback communication rhythm. Invite users to the
demos and encourage the whole team to communicate with them.
Alternatively, record videos of users giving feedback and using the
product, and share that with all teams.
• Use tools like Confluence to establish a comprehensive overview
of all artifacts related to your product — for example, vision, goals,
roadmap, personas, and marketing collaterals.
• Find the most comfortable time slots for product reviews and plan-
ning ceremonies.
• The ScrumMaster should maintain high-bandwidth communication
between the development team and business representatives.

Conclusion
Managing distributed teams isn’t easy. Many aspects influence how work
is done across the globe: e.g., communication, cultural differences, geo-
graphical distance, and time zones. As practitioners of software develop-
ment, we have found the agile principles to be of strong help. Our distrib-
uted agile framework consists of six bubbles (as of now — we expect more
in the future). This book describes the questions, virtues, and practices
that underlie the first three bubbles: communication, culture, and prod-
uct.
Our work is based on an open-source, community approach. We expect
these practices will be an ever-growing body of knowledge. We believe
they should be, because things change and every expert needs to find the
right practice for any given context. If you are such an expert and you
would like to contribute a practice, please e-mail one of us at hugo@ekipa.
co (Hugo Messer), gjokoro12@gmail.com (John Okoro), or savita.pahu-
ja@gmail.com (Savita Pahuja).

37