Author Q&A: from Chaos to Successful Distributed Agile Teams

Johanna Rothman and Mark Kilby have written a book titled From Chaos to Successful Distributed Teams: Collaborate to Deliver. The book provides advice for anyone working in or with a distributed team on how to overcome the common (and some uncommon) challenges that distribution and distance bring to effective team collaboration. 

The book can be purchased either here or here and InfoQ readers can access a sample chapter here.  

Rothman and Kilby spoke to InfoQ about their ideas. 

InfoQ: Why did you write this book?  What is the problem you want to address?

Johanna Rothman: Back at Agile 2017, I was walking to the last session and saw Mark [Kilby] walking to the last session. I asked him, "Did you see anything useful about distributed agile teams?"

He said, "Nope, you?"

I said, "Nope." Then I paused. Very briefly. I asked, "Wanna write a book with me about distributed agile teams?"

Mark Kilby: I took a very long time to think on it (about half a milli-second), and said "Let’s do it."  That’s when our journey as a distributed writing team began.

Rothman: Here’s why I asked Mark [Kilby]. I’d been working with clients who thought they were collocated. They weren’t. Worse, I’d worked with clients who, even though they were distributed, thought they could work the same way a collocated team could work. All of these people could not make their preferred agile approach work.

Kilby: I had worked with several teams and companies where they had valued experts in different locations. Some had prior experience with agile and some did not. They wanted the benefits of agile without having to relocate everyone. Some of these same teams had also worked on open source projects and had experience working remotely. They just wanted better communication and collaboration.  

What agile gave them was a way to rethink the game of distributed development.

Rothman and Kilby (we often say this together!): We wanted to solve the problem of thinking distributed teams could use exactly the same practices as collocated teams. And, we wanted to help the distributed agile teams work better.

InfoQ: It seems that more and more organisations  (agile or not) are using distributed teams - what is driving this trend, and is it a problem?

Kilby:  At Sonatype, where I am now, they specifically started with distributed teams to bring in the best talent from all over the world.  Their products grew out of the open source ecosystem.  So many of their people understood how to work effectively as remote workers.  

What they also wanted was to leverage agile principles and practices so they could collaborate quickly and easily.  They knew they would be in a rapidly changing market and wanted to use agile to respond quickly to that market.

Rothman: Some of my clients had different reasons. They wanted to make it easier for people in metropolitan areas to live wherever they wanted to live and not spend all their time in the car commuting to work. Or, not spend all their money on housing. 

Some of the managers also wanted resiliency in their organization. The more dispersed you are---assuming everyone has a reasonable infrastructure, the more resilient the teams and therefore the organization is. You have some people in weather somewhere? (Think hurricanes and blizzards.) Chances are good that other people are not "enjoying" the same weather. 

There is one potential problem we see: thinking a distributed team will save you money. Neither of us has found that to be true. The fewer hours of overlap the team has, the longer the cycle time. The longer the cycle time, the longer duration and more expensive the project. 

So, no, distributed teams are not a problem because we now have sufficient tools to use for communication and collaboration. However, if managers focus on resource efficiency, they too often lose the value of the people doing the work.

InfoQ: Are there some common patterns for distributed teams, and what are the characteristics of the different types? 

Kilby: We see three basic patterns for distributed teams:

Satellite teams have most of the team collocated and one (or a few people) remote.  Usually, the remote people work from home.  Typically, this pattern arises when you have work-from-home programs or you have one team member whose spouse finds an opportunity in another city.  In this latter case, the employee may be prepared to leave the organization but they are so valued, they are offered an opportunity to work remote.

Cluster teams arise when you have sub-groups of the team in different locations.  This might occur by function (product owner, scrum masters, developers, QA, etc.) or it could be a more random arrangement.  The difference is the majority of the team is not in a single location. 

Rothman: We often see a couple of developers in one location, a couple of testers in another location, a PO in a third location, and possibly an agile project manager/Scrum Master/coach in a fourth location. 

Kilby: The third type of pattern is the Nebula.  You have everyone dispersed.  No one shares an office and everyone collaborates online all the time.

You can have hybrid combinations of these patterns, but you will still see these three patterns in the hybrids.

Rothman: Notice that all these names have a reference to space. What we don’t have in a distributed team is the physical space. What we need is to bring the space-time continuum to the team. 

InfoQ: What are the particular challenges that distributed teams face when they are trying to work in an agile manner?

Kilby: One of the biggest challenges occur when experienced agilists try to apply the same practices to distributed teams as they do for collocated teams.  A typical practice like the retrospective can become complicated and painful depending on the distribution of your team members and their hours of overlap.  

Instead, we recommend going back to principles and looking at how the practices you want to use were trying to apply those principles.  How might the principles suggest different practices for your context to achieve the same goal?

Rothman: For the retrospective, how much can we do asynchronously in prep for the meeting, and how much do we need to do together? Mark [Kilby] has extensive experience with asynchronous prep and synchronous discussions. 

Maybe the team has a small kaizen event every day, especially if they don’t have too many hours of overlap. Maybe the team only has a retro when they are together, once every quarter. 

InfoQ: What changes do distributed teams need to make in order to use an agile approach (can they use Scrum-out-of-the-box)?

Rothman: Distributed agile teams can rarely use an out-of-the-box approach, such as Scrum. Scrum, specifically, has many real-time rituals. Many teams find that they spend hours and hours and hours in meetings. That much meeting time doesn’t make sense for a distributed team.

Instead, if teams use the agile and lean principles, and adapt the practices to their context, they are much more likely to succeed. 

Here’s the biggest challenge I see, specifically with Scrum: When does the iteration start and end? 

If you’re within six hours of overlap, that might just be a working agreement between the team members. But what if you only have four hours of overlap? What to the westerly people do when the iteration "ends"? When do they demo? When do they conduct a retrospective? I don’t actually see how to manage Scrum when you have fewer than six hours of overlap. Yes, that means that if you have team members across the US, I recommend you don’t use Scrum.

There are many other challenges. Most of those challenges are because the team doesn’t have sufficient hours of overlap

InfoQ: You’ve mentioned "hours of overlap" a few times - why the emphasis on this?

Kilby: Many people talk about timezones and how they separate people. But I’ve worked with people who preferred to work early or late times in their local day so they could collaborate with the rest of the team members.

And, I’ve worked with digital nomads. Those are people who travel the world, living in some place for a while, then moving to another place. These people decide when they will work, so they can work with the team. 

Timezones don’t matter. Hours of overlap do.

Rothman: When Mark [Kilby] first said the phrase, "Hours of Overlap," I did that little Eureka thing. You know, where you say, that’s exactly the right way to phrase it? Then all we had to do was show what we meant.

I’d used time zone bubble charts before. Those work well when you’re not changing to or from standard time. But, they don’t work under these conditions:

• When the country or state changes to daylight savings time. Every country seems to change on their own schedule. And, some states in the US don’t change at all.
• When people prefer to work early or late and that works well for the team.
• When people have daytime obligations that take them away from work. Even if it’s an intermittent thing like a child’s doctor’s appointment, if the team creates its weekly Hours of Overlap chart, everyone can see the effect on the team. 

The hours of overlap chart is like an information radiator. It tells the team when we can work together.

InfoQ: Are there any examples of organisations that have achieved effective collaboration with distributed teams, and what did they do to achieve it?

Kilby: There are several examples.  Automattic which develops the Wordpress blogging platform.  Gitlab which builds software development platforms for distributed teams.  Also, my current company Sonatype has successfully been using agile practices in distributed teams for the last 6 years and had small collaborative teams before that.

From my experience at Sonatype and other companies, and from what I’ve read about companies such as Automattic and Gitlab, many of these companies achieved this distributed collaboration by giving their employees choice, by being very transparent with their employees, and by being willing to experiment with new ways to work.

Another way to explain their success: they trust their employees to work in the company’s best interest even though they can not see them every day.

Rothman: Particular Software is a 100% dispersed (nebula in our terms) organization. They achieve collaboration partially through technical tools such as Github, and partially through collaboration tools, such as Zoom. 

One of the company values is around what they call "maturity in interaction." That means they offer feedback to each other and retrospect on the work. I would call this inspect-and-adapt on everything: how they collaborate to produce the work, the interactions for that collaboration, the work itself (process and product).

Here’s what I noticed: they team on everything. They do almost nothing as individuals. They say, "Our success working remotely is a function of EVERYONE working remotely, of the tools we use and how we use them, of our values, and the culture we have carefully crafted over time.  And, of course, the quality of the people we hire."

Because they default to collaborative work, and they create transparency around everything, they can effectively communicate.

InfoQ: How should leaders engage with and support their teams when they are distributed? 

Rothman: We recommend everyone start with these three mindset shifts:

Mindset 1. Manage for change. This means experiment.
Mindset 2. Emphasize communication and collaboration.
Mindset 3. Use agile principles, not practices.

When leaders embrace these mindsets, the leaders optimize for the team by focusing on flow efficiency.  The leaders do not focus on resource efficiency, optimizing for the individual. 

The leaders remove the too-typical "remote" impediments, such as insufficient infrastructure access, or insufficient licenses or permissions for the various tools. And, when leaders use agile principles, they don’t consider attempting to standardize on boards or frameworks for the teams.

If an organization wants the benefits of distributed agile teams, the entire leadership must embrace these mindsets. That’s a big ask.

Kilby: You should always start with small experiments.  Decide what one thing you want to change. What guidance can you get from an agile or lean principle?  How does it apply to your remote context?  Don’t just try to replicate a collocated practice in a remote environment.  That will likely fail.  Often the small change might mean coming up with a new practice that aligns with agile and lean principles.  Discuss the proposed experiment with those interested and impacted to get ideas on how to best run the experiment.

Once you have the "experiment" started, run it for a short period of time (days or a few weeks) and make sure you can get feedback from those potentially impacted.   This is another area where communication and collaboration come into play.  What did we observe?  What worked well?  What surprised us?  Did we prove what we set out to prove?

Once a team or organization becomes accustomed to small experiments, you can take on a larger one.  One organization I coached started with lean coffee Q&A sessions to help connect people across the organization in an informal manner every two weeks.  The format became so popular for building relationships across the company, we went for a larger experiment with one of the all-hands meetings.  Since everyone in the organization would physically collocate for a few days during these all hands meetings and we could never set an agenda that satisfied everyone, we tried an open space format.  The company has used this approach for the last four years with great success in raising key issues, planning new initiatives and building stronger connections across teams.

About the Authors

Johanna Rothman, known as the "Pragmatic Manager," provides frank advice for your tough problems. She helps leaders and teams see problems, resolve risks, and manage their product development. Rothman was the Agile 2009 conference chair and was the co-chair of the first edition of the Agile Practice Guide. Rothman is the author of 14 books that range from hiring, to project management, program management, project portfolio management, and management. Her most recent books are From Chaos to Successful Distributed Agile Teams (with Mark Kilby) and Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. She is working on books about modern management. Read more of her work here and here. 

Mark Kilby, with over two decades of experience in agile principles and practices, has cultivated more distributed and dispersed teams than collocated teams.  He has consulted with organizations across many industries and coached teams, leaders, and organizations internally. Kilby also co-founded a number of professional learning organizations such as Agile Orlando,  Agile Florida, Virtual Team Talk, and the Agile Alliance Community Group Support Initiative among others. His easy-going style helps teams learn to collaborate and discover their path to success and sustainability. Read his most recent ideas and articles here.