Distributed agile: How to make it successful with your team

Distributed agile software development seems like an oxymoron. The original agile software manifesto prescribed colocated software teams. The writers believed that working in the same physical space boosts communication and team cohesion. Having your whole team in one place does convey real benefits, but that's often not possible. When your team isn't all in the same place, you still need to make sure you're working together effectively.

I've been working on and managing distributed agile teams for nearly ten years now, and along the way I've figured out a few things about how to make distributed agile work. In this post, I'm going to outline how to make your distributed team just as effective as any other. It's not always quite as easy, but with focus and preparation, you can turn your distributed agile team into a powerhouse.

Sweat the standup

I know this might sound counterintuitive, especially to a team that's used to working in the same room, but your team standup, or huddle, is the primary touchpoint. In colocated teams, the standup is often done around a shared pod of desks, and it only takes a few minutes. In a distributed team, neither of those things are true. A standup is a true meeting for a distributed agile team. Developers need to stop what they're doing, log into a video call, and wait for everyone else to show up. Then they'll wait patiently, mostly not listening, while everyone gives their update. When it’s their turn, they'll give their update. There will usually be one person who takes far longer than everyone else and goes into too much detail. You might have a time period where you follow up on other discussions, then everyone goes their separate ways.

In short, for most distributed teams, standups are full status report meetings. Instead of being a casual, short check-in, it's a full meeting that interrupts the flow of the day. If you're distributed across time zones, it's likely that your standup will be during a time that's inconvenient for at least one person. And the standup will probably take way too long.

How to make distributed agile standups work

What's the easiest way to make distributed agile standups work? Don't have them.

I'm only half kidding. Remember what we just established? Distributed standups are status report meetings that your team has every day. I reckon that if you took a straw poll of other departments within your company, you'll find that none of them have full status report meetings every day.

Instead, focus on how to get the value of a short, daily standup meeting without the intrusion. The most effective standup meetings I've experienced are those where everyone has already communicated the details of their status before the meeting started. Instead of listing the details of their work, the standup was a quick check-in to make sure that nothing else had come up and that nobody needed to talk about anything in more detail.

The second recommendation I'd offer is to focus your standups on the team, not the work. Every meeting within a distributed agile team is an opportunity to build team cohesion that doesn't come naturally. When your standup is a full status report meeting, people will be bored. They'll lose focus. This is just another box they have to check to keep their job. If you instead focus the standup only on big blockers, your team will have a chance to catch up and communicate with one another.

Get your retrospectives right

Another agile ceremony that distributed teams often get wrong is the sprint retrospective. Not every team does these the same way, but they're often much more clumsy for a distributed agile team than for a colocated one. The reason for this clumsiness is pretty simple. Most colocated teams sit down at the start of the retrospective and lay out the things they want to talk about. This serves as a kind of brainstorming session. It's also pretty fluid; developers have been working together all sprint, so talking about things that went well or didn't go well triggers memories.

Distributed agile teams often don't approach retrospectives the same way. They usually ask the team to put together a list of things to talk about before the meeting starts. What's more, two people working on the same team might have experienced things very differently. One person might think something went well, while another person found that same experience frustrating.

Preparation is key

The biggest problem, though, is that people often come unprepared. They won't spend time before the meeting thinking about the previous sprint. If someone starts to talk about something, they'll contribute, but they're not working to make the retrospective effective. As a manager, I've pressed developers, and their response is usually that it's difficult to identify anything that stood out during the sprint. Once they dive into a conversation, they can remember specific things, but not while they're preparing for the meeting.

As a manager, this is something you can help with. During the sprint, keep notes on things that the team worked on. Take a quick note of things that seemed to go better than expected or things that didn't go as well as the team had hoped. Then seed these things into the conversation and help spark the team's memories.

It's important to remember that you don't want to steer the conversation. The retrospective is a chance for the team to provide feedback and to shape the team's future. With a little work, you can make retrospectives a lot more valuable for you and the team.

Distributed agile one-on-ones are critical

In my experience, a lot of distributed agile teams think the team should be managed differently than a normal team. Because the focus is on success or failure as a team, they skip regular check-ins like one-on-one meetings. To be clear: this is a big mistake. One-on-one meetings are even more important in distributed teams than they are in traditional colocated teams. Distributed teams have far fewer opportunities for ad hoc conversations between managers and developers. That means you need to carve out time specifically to have conversations with developers, and you need to make sure they count. Many one-on-one meetings devolve into status updates, but you're already doing those. As we discussed, you're probably doing too many of them.

Instead, focus on connecting with the person. Talk about their life outside of work, their professional goals, or their big-picture joys and frustrations with their current job. A one-on-one is a time and place to invest in your people. Since people are the core of any effective agile team, investing in your team members' well-being and success is a key part of being an effective leader.

Use the right tools

Working with a distributed agile team means rethinking some of the ways you operate. You need to plan activities that used to happen organically. Your team needs to build cohesion between team members. That's where a tool like Range can be so effective. It helps lubricate daily interactions and makes it easy to remember what someone worked on yesterday. It's also focused on people rather than projects. It's not there to track how far you are from finishing a task; it's there to help ensure developers are succeeding as part of the team.

You'll need to remember that distributed agile teams aren't necessarily better or worse than colocated teams, but they are different. If you're transitioning to a distributed team, expect an adjustment period. But with the right focus and the right work, you'll find that your team members are growing together just as effectively as they were before.