By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.

Quality is not something “owned” by the testers, but the responsibility of the entire team. In fact, you don’t try to “test in” quality, but rather “build it in”.

It places collaboration and teamwork above individuals working alone. It values pairing and swarming around work. It values limiting WIP so that team members work together.

What’s often lost on most organizations and teams is that when you focus on keeping individuals busy and optimize at the functional level, with silos, hand-offs, and dependencies - you go slower. Sure, it feels like everyone is working hard…and they are. But the results, the throughput, the value, is often much slower than it’s agile, collaborative counterpart.

Sidebar

I often try to make this point with my classes, and I’ll share it with you here. Don’t take my word for the above. Instead, run an experiment. Run a sprint the way you normally would do it – without much collaboration. See how many stories you get done. Then take roughly the same story mix and run it focusing on collaboration and swarming. Worry less about keeping everyone busy, but focus on collaboration, swarming, and throughput – getting as much done as possible.
To-date, I’ve never seen a team do less than their waterfall behavior equivalents. If they run an honest experiment, they often get 50% - 100% or even more done by working together. I know, it’s counterintuitive, but please – run the experiment across two sprints.
Then reflect about what’s going on…and try to do more of it.

Distributed Teams

I was talking with a potential client the other day. They had a widely distributed team. Let me describe some of the dynamics:

  • The developers were spread across the country; each in a separate location;
  • The testers were centrally located in a remote office;
  • The Product Owner was in the central office along with the Scrum Master.

They said they were “Agile and doing Scrum” when I spoke to them. But because of the distributed nature of their team, they were skipping some key things. For example, having a daily stand-up was incredibly inconvenient for them. So they skipped it. Instead they sent around status email messages as a way of trying to stay in-synch.

There was no sprint planning or backlog refinement either. Each developer would essentially agree to their specific work and mail in their game plans. It was up to the QA team members to try and figure out how to support each one. Essentially all of the developers were chucking code over the wall to the testers at the end of each sprint and hoping for a miracle.

But the miracle rarely happened and they were struggling with delivery. But guess what else they said?

Bob, clearly agile doesn’t work in a distributed environment. We believe we’re failing because we’ve adopted agile.
I asked them, did you have the same team structure before you adopted agile?
Yes.
Did you have delivery problems before?
Of course, it was worse then. We couldn’t deliver anything on time without killing ourselves at the end. But we thought moving to Agile would fix things.

My Response

I get this pushback all of the time in my agile coaching and training travels. Nearly everyone asks about how agile works in distributed environments. Their challenge is always – that it doesn’t work.

So what does it take to make agility successful in distributed team contexts?

A few things, but one of the keys for distributed teams is COLLABORATION.  

You must collaborate as a team - Imagine that!?!

Have you ever heard the expression – “fake it until you make it”? I think it applies to agility as well. Instead of throwing out all of the collaborative goodies because “they’re too hard”, why don’t you pretend you’re agile in the interim. In other words – commit to collaboration! Commit to the principles of self-directed teamwork, accountability, quality, transparency, etc.

And if you’re COMMITTED, then my supposition is that each team will figure out a way to make things work.

What are some of the key aspects of agile collaboration?

Meet face-to-face whenever possible – I know, I know, you don’t have the budget for it. Well, plan some budget for it. Teams need to be built and you can’t do everything remotely. Consider flying folks back and forth or consider special events where everyone gets together. If you’re starting a new agile project with a distributed team, one of the best things you can do is get the entire team together to charter or kick-off the project. Allow them to run the first sprint “as if” they were co-located. Let them get a feel for each other and working as a team. I talk about this more in this blog post.

Pairing – 3- Amigos – Try to pair (remote pairing) whenever possible – Don’t view it as you’re wasting time; instead consider it an investment in collaboration and teamwork. And I’m not simply talking about developer-to-developer pairing. Testers can pair. Or developers with testers, or you can engage in 3-Amigo style collaboration. The less individual, lone wolf work that is done within your teams the better the collaborative results will be. But don’t force the pairing. It has to come from within each team member and be opportunistic and welcome. But encourage it and don’t “count hours”, but review the results the pairing is driving in productivity AND quality.

Daily Stand-up – It’s incredibly important to have a daily synch-point or collaboration event for the team. It sets up a “heart beat” for the team to communicate, share successes and challenges, and to help one another.  So no matter how distributed your team is, you need to agree on a mutual time and be there. But not just attend. You need to be engaged in the standup – listening to everyone and fully participating. Remember, you should have committed to the Sprint Goal as a team, not distributed individuals, so you should be interested in every conversation.

Co-location – One of the ongoing points that folks with distributed teams make is that they can’t be co-located. And I agree, this is a drag. One of the “sweet spots” of agile teams is the notion of a cross-functional, co-located, self-directed team. So it’s a disadvantage. But it doesn’t have to block all collaboration. Put on your creative “thinking hats” and try ways to setup a virtual, co-located environment. Use web cameras, share whiteboards, use whatever tools you have, and yes, pick up the phone. I’ve found that distributed teams can be incredibly creative in setting up virtual co-located environments that are nearly as good as “being there”. But the rub is, you have to put in the extra effort to do it.

Swarming – I’ve worked with a company that has some distributed team members and they constantly push back on swarming their work – preferring that lone individuals work on each story. In fact, if I even mention the word swarming, they become agitated. Imagine how this culture handles more distributed team dynamics? Yes, badly. And their results? Fractured at best. In your sprint planning you’ll want to plan for collaboration wherever possible. I realize it’s hard to swarm around a 1-point user story. So don’t. But what about a 13-point user story? The goal of your sprint execution should be getting each story done (ASAP) instead of keeping individuals busy.

Exploratory Testing – Far too many agile teams don’t know about Exploratory Testing. It’s a technique for “exploring” applications as a group and keeping track if your “journey’s and findings”. I like to do it in pairs. Teams carve out some time to test in pairs in time-boxed sessions. Each session has a charter that defines a pair’s area of the application to explore. Then the pair tests within those boundaries for a session – let’s say 90 minutes. At the end of each session time-box, the pair’s get together to debrief their findings, progress, and plan next steps IF they’re going to run another session. Not only is it a wonderful way to attack testing as a whole-team, but it also reinforces pairing and collaboration.

Customer Demo – Often we forget that the sprint isn’t “done” until you’ve conducted a sprint demo AND received feedback. And the demo is a whole-team activity, so everyone needs to be there. Heck, forget being there, the team needs to be interactive in presenting their results. Now this can be particularly challenging with distributed team members, but put some creative pressure on yourselves to “figure out” how to get the entire team involved in planning and executing your Sprint Demo.

Backlog Refinement & Team-based Planning – It turns out that backlog refinement meetings, ongoing backlog refinement, and sprint planning are FOR the team. They require whole-team engagement. Often this is a contention point in distributed teams because it might be challenging to get everyone together at a “convenient” time. I say tough! These are team-based activities and the team needs to figure out how to get everyone not only attending, but engaged, and working together in the plan and during the execution of each sprint. These meetings are the backbone of your agile results, so they are required.

Leadership Accountability

And focusing on making it a team sport isn’t just – for the team. Organizational leadership must be held accountable for:

  1. In their infinite wisdom setting the organization up in a distributed fashion;
  2. Realizing that it’s less efficient to work in distributed teams; i.e., there will be “drag” and ongoing challenges;
  3. Supporting their teams requests for tools, trips, and anything else that fosters collaboration;
  4. Realizing their responsibility over time is to:
    1. listen to each teams feedback and
    2. reduce the distributed nature of the teams as much as possible.  

Over time, try to move the WORK to co-locate TEAMs as much as possible. Even if that means increasing costs in the short term or disrupting strategic plans that were made before the decision to “go Agile”.

I guess what I’m saying is that distributed teams are a CHOICE. And I’ve found that there is tremendous leadership “wiggle room” in reducing the distribution over time.

Wrapping Up

I’ve often found high-performance distributed agile teams. Frequently they kick the butt of their co-located counterparts.

Why? Normally there are two, high-level reasons.

First, the teams commit to agile principles and cross-team collaboration. You could move some of them to the moon and they’d still find a way to make it work in delivering value to their customers.

And second, their leadership teams understand that they’ve setup the teams with a challenge from the get-go, but they do everything in their power to support collaboration within their organization AND to reduce distribution over time.

In other words, they’re creative and committed.

BTW: I like the hockey picture because ice hockey is one of those sports where true teamwork is fostered by up to 2 players gaining assists for someone scoring. Talk about swarming…

Stay agile my friends,

Bob.

Comment