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

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.