I’ve been sharing about agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:

Does agile work with distributed teams?

And sometimes the question is phrased another way:

That notion of co-located teams is nice in theory Bob, but in the real life, we have team members all over the world. We need to cobble together teams based on our business needs from wherever they are. Does “agile” support that level of highly distributed teams?

I often smile at the repetitiveness of the question. It indicates clearly that enterprise level software development is often distributed. It also indicates that outsourcing is still alive and well.  I’ll try to provide some answers to these questions by sharing two stories of distributed teams I have experienced.

A Tale of Two Distributed Teams

The “Good”

I was lucky enough to be invited to do an agile jump-start at a new client. They are a rather large firm that builds hardware and software devices supporting mechanical control systems. They were kicking off several projects that encompassed many teams, some of them off shore and many of the teams being distributed. They were looking to leverage Scrum as the method for starting these projects and they invited me in to do some training and get the teams “sprinting” in this new style of product development.

When I arrived at my first class session, I learned that they had invited four complete Scrum teams to attend. In fact, one of the teams was based in India and they had flown the entire team in for several weeks. The first week was for our Scrum “Boot camp” and the next few were to work with local teams as everyone started sprinting together.

I distinctly remember at the time thinking how novel this was. My typical experience with firms kicking off agile in distributed teams was more along the lines of the following:

  • Throw disparate individuals (local and remote) together into “teams”
  • Tell them they’re “going Agile”
  • Send them some references on agile, at best, run them through a short class
  • Expect the team to start sprinting…ASAP
  • Expect great results
  • Rinse & repeat if you still have a customer…

Clearly I’m joking a bit here, but there is a good bit of truth in these steps. Many firms don’t start their distributed agile teams up very well. So I was understandably surprised at how thoughtful my client was in investing in their teams’ start-up.

I returned to the client several sprints later to do an informal assessment.  By now the remote India team had returned home and was happily working with the local teams. I sat in on some of their stand-ups and other meetings. I was incredibly impressed with how well they were working as an agile team. I was even more impressed with how they integrated and collaborated with the local teams—it was virtually seamless.

It struck me that the cost the company had incurred in bringing everyone together to generate a solid start was paying them back big time. That solid project start-up had put everyone on the same footing and really solidified them as a set of cross-functional teams that were working towards the same goals.

As an aside, I’ve seen this same investment pay similar dividends at multiple clients. Now let’s explore another story.

The “Bad to Ugly”

I was invited to visit another set of teams to help them with some difficulties they were having working across distributed locations. They were executing sprint five of a twelve sprint release sequence. There was a distributed UX / Design team, two front-end UI development teams, one in the US and the other in Brazil, and there was a backend development team in Singapore. So, a very distributed mix across four distinct teams working on a singular project.

One key challenge I remember was that the front-end and backend teams were really struggling to figure out how to work together. They were using email and documents as their primary means of collaboration. But quite often, it would take days to sort out a simple interaction that was required to move a User Story forward. And the issues weren’t focused on one team or one locale. There were pervasive communication problems across the teams.

One idea came up in a local (US) teams’ retrospective. It turned out that nobody had ever “met” the off-shore Singapore team that they had to integrate with (at an API level and at a project collaboration level). The idea was to have a video conference call across the two teams as a means of introduction and becoming more familiar. Everyone thought it was a great idea and we scheduled the intro.

I volunteered to serve as the facilitator of the video introduction. There were about 8 members on our local UI team. We fired up the video and zoomed into the room in Singapore, eagerly expecting to meet a team roughly our size and composition. And they started filling the room—and filling, and filling.

In the end, over 30 people came into the room from Singapore. We were amazed and during the course of the introduction quickly realized some things:

  • We had assumed some of them were men and they were actually women and vice versa…who knew?
  • There were two expectant mothers in the room…who knew?
  • We thought there were roughly 8-10 members of the team, and there were 30. Even funnier, we’d been working with them as if their capacity was 8-10. Who knew?
  • Clearly nobody on either side had ever seen or met each other. Apparently ALL collaboration was via email, text messages, and documents. Not a phone / video call to be had.
  • We learned about their background and skill levels; realizing that they knew much more than we had been giving them credit for.
  • We learned that they were heavily multi-tasking and being interrupted across many projects. Ours wasn’t their highest priority…who knew?
  • We finally realized that they didn’t like this “agile stuff” and preferred more traditional development. So this was a major change for them…who knew?

It was a fantastic, baseline setting call for the two teams. It created a much better understanding and led to much improved empathy, understanding, teamwork and results going forward.

Just one thing, I wonder why this wasn’t the FIRST THING that happened when the teams were formed and the project begun. They could have avoided a tremendous amount of frustration, waste, and missed progress. Oh well…

Three CORE Starting Patterns for Distributed Agile Teams

I hope my two real world stories convinced you that a fundamental aspect of successfully implementing distributed agile is HOW you START your teams and projects. Here is a bit of a checklist to help you improve your distributed agility:

#1 - Establish the Team(s)

  • Formation – take some time to thoughtfully form your teams. Introduce them. Allow for some social collaboration of some sort.
  • Leadership – take a look at your leadership within your organization and ensure that each team has some experienced technical leadership. Also ensure that each teams’ local functional leadership is aligned with agile leadership fundamentals.
  • Co-locate in Clusters– look across the members you have to work with and try to cluster team members together (geographically) as much as possible.
  • Skills Aligned with Backlog– remember that team skills need to align with the product Backlog AND they need to have sufficient skill and domain experience to deliver high quality results.
  • Cross-Cutting Concerns- Consider how the team will handle cross-cutting concerns like UX Design, Architecture, and Integration Testing & Deployment.

#2 - Train the Team Together

  • Basic Training– if possible, training should be approached as a whole team effort and is best done face-to-face. Everyone needs to ‘hear’ the same things. Simulations should be a part of the training so that the teams get the opportunity to “work together”.
  • Roles & Responsibilities– developing clarity around expectations is crucial for agile teams to start up. Take the time to establish team and cross team roles and responsibilities and/or rules of engagement early will pay dividends during Sprint execution.
  • Focus on Scrum Master and Product Owner– are important and ‘specialized’ roles within agile teams. Ensure you’ve selected wisely, don’t overload other roles, and provide sufficient training and coaching for these individuals. It’s crucial in distributed teams!
  • Start the First Sprint Together– if at all possible, start your first sprint with the team in the same locale. If that’s not possible, then slowly start, so that the teams aren’t rushing to produce “working software”, but instead are producing a “working team”.

#3 - Establish Norms, Standards, and a Charter

  • Team Norms– for listening, respect, behaviors, collaboration, quality, retrospectives, etc. Establish these as a team, post them on walls and remind yourselves of your agreements.
  • Meeting Norms– there can be an awful lot of meetings when moving to agility and conducting these are exacerbated by time zone difference. Place heavy focus on just enough, just in time, and well facilitated meetings. Don’t forget the power of a time box.
  • Definition of Done– I have a nice presentation that depicts 4 levels of done-ness consideration within agile teams. This is an area to truly focus on when working in a distributed team.
  • Tooling – tools become more important in the support of distributed teams, but they can also get in the way of collaboration and learning. Carefully select a minimal set of tools, while reinforcing face-to-face collaboration.
  • Commitment to Agility– It is clearly harder to support agile tenants and tactics when participating within a distributed team. It will test your mettle. Establish broad commitment to your agile principles across the teams and stick to them.
  • Chartering & Release Planning– is critical for cross team integration, dependencies, sharing a mission & vision, determining and measuring success. The more time you can spend in up-front chartering activity, the better your results will be. So resist “diving in” and sprinting too soon!

Sprint Review TOGETHER!

One final point, distributed teams should perform their Sprint Demo/Reviews together as much as possible. That would include members of each team AND teams that are working together to deliver a project or product. The more you can integrate the demonstration of results, the more you will drive effective cross-team collaboration.

And improvements surfaced during the reviews will naturally cascade into the teams’ Retrospectives—driving collaborative improvements.

Wrapping Up

Going back to my theme of what attendees ask me about distributed agile teams, there’s often another question:

Do we really have to do ____________? It’s really hard to support that agile practice because we’re distributed!

You could fill in the blank with any of the following: swarm, collaborate, stand-up, groom, sprint plan, code review, design review, pair, test, talk to each other, etc.

My consistent answer is always—yes, you do. Now you may need to get creative with the how and the when in your support of solid agile team collaboration tactics, but “skipping them” when the “going is tough” is rarely a good practice.

I’ll leave you with that though. Is agile harder to do in distributed teams? Of course it is. But is it possible to do it well in distributed teams? Absolutely. It’s truly up to the business to commit to properly starting their projects and the teams to commit to agility and figure out how to drive great results.

Thanks for listening,

Bob.

References

  1. Here’s a link to a related blog post from Johanna Rothman and Shane Hastie - http://goo.gl/YypJY
  2. And here’s a link to a presentation on Agile Done-Ness Criteria – http://goo.gl/GXL3u