Skip to main content

Distributed Agile Teams: The ART of the START

galenNov20I’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:

The notion of co-located teams is nice in theory, but in 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 high distribution?

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 for 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 offshore and many 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 and 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 up their distributed agile teams very well. So I was understandably surprised at how thoughtful my client was in investing in their teams’ start.

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 had the same vision and were working toward 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 number five of a 12-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 a back-end development team in Singapore. In short, a very distributed mix across four distinct teams working on a single project.

One key challenge I remember was that the front-end and back-end 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) team’s retrospective. It turned out that nobody had ever “met” the offshore 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 familiarization. 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 eight 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 … who knew?
  • We learned that they were heavily multitasking 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 approaches. So this was a major and difficult change for them and their leadership … 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. But 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. Who knew?

Three CORE Starting Patterns for Distributed Agile Teams

I hope my two real world stories have 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:

Establish the Team(s)

  • Formation – Take some time to thoughtfully form your teams. Introduce them. Allow for social collaboration of some sort.
  • Leadership – Take a look at the leadership within your organization and ensure that each team has some experienced technical leadership. Also ensure that each team’s 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 that each team must 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 and deployment.

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. Taking 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 – These are the most important and specialized roles within agile teams. Ensure you’ve selected wisely, don’t overload other roles, and provide sufficient training and ongoing 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 start slowly, so that teams aren’t rushing to produce working software, but rather a “working team” should be their first goal.

Establish Norms, Standards, and a Charter

  • Team Norms – Set norms for listening, respect, behaviors, collaboration, quality, retrospectives, etc. Establish these as a team, post them on walls, and continuously remind yourselves of your agreements.
  • Meeting Norms – There can be an awful lot of meetings when moving to agility and conducting them can be exacerbated by time zone differences. 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 four levels of Definition-of-Done (DoD) or Done-Ness consideration within agile teams. There’s a link in the references. This is an area to truly focus on when working in a distributed team.
  • Tooling – Tools become more important in 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. Then grow your tools over time based on team feedback and needs.
  • 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 teams and stick to them.
  • Chartering & Release Planning – These can be critical for cross team integration, dependencies, sharing a mission and vision, and determining and measuring success. The more time you can spend in up-front chartering activity, the better your results will be. So resist 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 good practice.

I’ll leave you with this thought.

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.

It’s simply another choice as you “go agile”. Please choose wisely.

Don’t forget to leave your comments below.

Comments (2)