For Distributed Agile Teams, It’s Not All about the Tools

Many managers and distributed team members think that if they just had the right tools, they could make some agile approach work. Maybe, but tools only enhance the work of a collaborative agile team. Before you select tools, make sure you have people who can work together and have enough skills and capabilities for your distributed team. Tools do not make the team; they support the team.

Dave, the manager, called the team lead, Jane, to talk about the tools her team needs. The organization recently decided to use an agile approach because they wanted to release smaller chunks of value more often. Jane and her team were happy about that, but they were distributed across several time zones. They had enough hours of overlap to collaborate, but Dave thought they needed tools to make collaboration happen.

Jane answered the phone and Dave started in. “So, what tools do you need me to buy so your team can use this agile stuff?”

Jane snorted. “I need a team more than I need tools.”

“Come again?”

“I don’t have a full team.” Jane paused. “I don’t have a UX person. I only have a part-time tester. And, with the reports features, I need a database administrator.”

Dave started to say something and Jane interrupted: “No, don’t tell me to share a DBA. I’m not sharing anyone. I need all these people, or this ‘agile stuff’ won’t work. For this project we will need to move fast to be first in this market.”

Dave reluctantly said, “I’ll see what I can do.”

“One more thing, Dave,” Jane added. “I need time to teach them to be a team first. We have so many distributed teams now that really don’t work. I know how we can turn that around, but I’ll need some time to work with them.”

Do You Have an Agile Team?

We’ve seen too many collections of people described as teams. A team has a common single goal: to solve a problem for the business or users. To accomplish that goal, team members depend on each other and collaborate to finish the work. An agile team has all the skills and capabilities it needs to produce the work for that goal.

Creating a great distributed team is more than finding people with the right technical skills. People also need collaboration skills, and that depends on their personalities and how they work. The team needs time to understand each other’s preferences so they can best collaborate to deliver value.

Collocated team members can see when team members are available, and they can see or share the equipment each team member uses or has access to.

Distributed team members, on the other hand, need to be explicit about their availability and equipment. Some team members may have office space. Some may work in a shared family space. Some team members might prefer coworking spaces. Team members should be aware of what advantages and obstacles these different working spaces provide to themselves and the entire team.

Consider taking time for the team to discover their preferences, skills, and abilities. When the team creates their working agreements, everyone can learn how they need to work together.

An agile coach or another experienced facilitator may help the team quickly explore these preferences and decide what might work best for everyone. Some examples might be:

  • Based on our time zones, do we have core work hours? If so, what are they?
  • What should someone do if they have a family issue or emergency that takes them away from these core collaboration hours?
  • What is the best way for the team to share information synchronously (chat, meetings, or something else) versus asynchronously (email, wiki, or something else)?
  • What types of regular meetings (e.g., planning, review, standups) should we put on the team calendar, and what are some as-needed meetings that we might anticipate?
  • How will we review each others’ work? Will we primarily do this together and synchronously? Will it be a traditional review, or would the team prefer pairing or mobbing? If we prefer asynchronous review approaches (such as using Github), what would be an acceptable review size (many teams don’t care for three hundred lines of code to review at once)? How do we resolve an issue when we see asynchronous “conflict” in the review?

Successful agile teams must have all the skills and capabilities they need, understand how to collaborate, and know what they’re supposed to work on. If a team doesn’t have the necessary expertise, they may not deliver the desired product at the right time.

But What about Tools?

Tools serve the team, not the other way around.

Once your distributed team understands how they want to work, consider the least number of tools possible. The first tool a team might use is a physical board—specifically, a kanban board.

Too many teams select a tool with a default board rather than visualizing their current workflow. We recommend you start with a board that reflects your situation as it is now, with as many columns as you need.

Consider using index cards on a corkboard to start. Take a picture of the board and post it somewhere in the team workspace. Especially if you only move a card once a day, this is sufficient until you make your stories smaller and move more cards more often. The benefit of a physical board is that you have total freedom to create the board your team needs, not a board someone (or a tool) imposed on you.

If you don’t like a physical board, consider a shared spreadsheet, such as Google Sheets, where you can easily change the columns to reflect your reality.

Once the team feels they have a good board design, then they might consider tools that can best support their workflow via an electronic kanban board.

Collocated team members can turn around and talk to each other freely. That’s a “backchannel” conversation. It might not be the primary discussion tool for the team.

Distributed teams also need a dedicated team backchannel—a way to conduct informal team discussions on an as-needed basis. We like a persistent text-based tool for the backchannel. Your team might need other audio and visual tools, such as a video meeting tool. Make sure everyone has access and can start a meeting when needed.

And, of course, your team needs software development and testing tools. Every team needs those, so we won’t address them here.

Build Your Successful Distributed Agile Team

Jane worked across the organization—with Dave’s blessing—to reconfigure her team and several others. She led the newly configured team through their working agreements and project charter. She suggested they start with a paper board with an always-on camera so every team member could see the state of all the work. Then they could see if the team needed any new states.

For the first couple of weeks, the team modified the board almost every other day. By the end of the second week, they were able to use WIP (work in progress) limits and manage how they flowed work through their team. Their board changes prompted them to consider other tools they might need to improve their collaboration and meet their goals.

Tools become the least important decision for the team. First, make sure you have enough people to cover the skills and capabilities you need on your team. Next, the team either articulates their shared goal or works with someone such as a product owner to define it. When the team learns about and respects each others’ work preferences, the team can function and thrive. Then they can determine the workflow that allows them to collaborate toward the shared goal.

Focus your tool selection on how well these tools support the team, their workflow, and their preferences. Great distributed agile teams might need fewer and different tools than you suspect. Make sure you have a collaborative team who can see how to work together to solve the customer’s problem. Then, offer them the tools they need.

User Comments

Doug Husovsky's picture

Does it really make sense in 2019 to suggest using note cards on a cork board for a distributed team where one group has access to them and others don't?  There are too many collaboration tools available to go back to this method. Many of them are free that duplicate this method.  Cards create a massive amount of overhead, and encourages not following any process. For a younger generation this is the equivalant to a horse and buggy.  I would love to hear success stories using this method with a team of globally distributed millennials.  

I would like to see a suggestion on a brand of camera that can show both the cards in a legible fashion and the people in the room at the same time.   We use cameras in our meetings  to humanize those we can't see face to face. Unless you have pan and zoom controls that most fixed cameras don't offer, this suggestion does not work. 

For what it would take to get this you may as well buy a subscription Agile tool to support your team.   I would bet at best you will see little more than the title on a card and not the user story supporting it or any notes and details.

I have to agree with the call to limit communication channels, as there does not appear to be one Agile tool that supports all that needs to be done.  Pick one, Skype, Slack, Team's etc.  But pick only one and use the heck out of it.

Until there is a better way to address 8, 12.5, or 14 hour time differences outside of having one part of the team work in the middle of the night and giving up on having a normal life, distributed teams will continue to be a disaster.   How can we claim to "respect" a co-worker when they have to work far outside of "normal" business hours to be able to communicate?

This model prevents collaboration and communication and will never lead to same results as collocated teams. Distributed teams will never be great teams they will be okay at best due to the roadblocks put in front of them. 

It's time to stop feeing the beast that that claims distributed teams are a good idea. It's time to say this is a failed model that needs to be put to rest.  Chasing workers to the lowest cost center dejour and expecting outstanding results is insanity. 

April 4, 2019 - 5:00pm
Johanna Rothman's picture

Doug, aside from Mark's comment, let me clarify one more thing: we recommend a separate camera to see the cards on the wall. My experience is that very few teams can actually complete even one story a day. When teams limit their WIP (Work in Progress), the camera doesn't need to see much.

When you talk about "teams" with few to no hours of overlap, I have several guidelines: don't use an agile approach which relies on collaboration. Limit the "team's" WIP, and hand off work. Stop having meetings. Use proxies to conduct those meetings. Bring people together in person at least once a quarter. 

Teams with few to no hours of overlap aren't a team. You can call that group a team, but they aren't. Stop using agile approaches, all of which depend on teamwork. 

I now assume I have offended your management. But, it's time for us to face the fact that software development is collaborative learning. People who can't work together can't collaborate.

April 5, 2019 - 9:05am
Mark Kilby's picture

Hi Doug.  Very valuable feedback, but perhaps not in ways that are clear.

  1. We would never recommend staying with the approach of using index cards and a camera.  We mentioned in the article, it's a starting point.  In some cases where it's not convenient, I've even started the "board" with a Google spreadsheet, work with the team figure out their value stream, and THEN see what tool may best replicate that workflow.  I've seen too many teams get tied up on the details of a commercial project tracking tool by starting there.  We may not have been clear on that.
  2. We would never recommend teams with 8+ or more hours of difference. (I've worked on those teams.)  What we do recommend is having teams with a minimum of 4 hours of acceptable hours of overlap.  This is not a 4 hour time zone difference.  It's having the team look at their preferred work hours where they are based and determine where they can set those core hours of overlap.  We may not have been as explicit there.  We did have a word limit on the article. 
  3. Currently, I have 15+ teams in one organization working this way .. all by choice.  No one was forced to work this way.  They hired on knowing the teams were completely distributed.  No one is working outrageous hours.  The teams have set their own core hours and manage much of their own process.  I and two colleagues coach the teams on how to adapt their process and also coach the organizational leaders on how to improve product management and evolve the organizational structure. 

We have other stories in our book but I wanted to provide some specifics here for you.  I just didn't want this to be a "buy the book" pitch. 

One last thing, we are not saying this is the "wave of the future".  We don't think it's for all teams or organizations.  But what Johanna and I have discovered working with multiple organizations is that if you focus on setting the right environment for communication and collaboration, are willing to experiment beyond the way things are now, and go back to agile principles and not try to force an agile practice that works well under one context and not another, you can have a successful agile team.  This tends to work for collocated and distributed teams by the way.

Hope this helps clarify.

April 4, 2019 - 9:22pm

About the author

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.