For some, integrating testers into agile teams stands to be the real challenge, especially when working with distributed agile teams. I’ve shared 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?
- A Tale of Two Distributed Teams
- The “Bad to Ugly”
- Establish the Team(s)
- Train the Team Together
- Establish Norms, Standards, and a Character
- Sprint Review Together!
- Wrapping Up
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 agile teams I have experienced.
A Tale of Two Distributed Teams
The “Good”
I was fortunate to be invited to do an agile jump-start for a new client. It’s a 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 agile teams. They wanted to leverage Scrum as the method for starting these projects, and they invited me in to do some training to get the teams sprinting in this new style of product development.
When I arrived at my first class session, I learned 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 or 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…
I’m joking a bit here, but there is a grain 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 back big time. That solid project start-up had put everyone on the same footing and 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"
One key challenge I remember was the front-end and backend teams were struggling to figure out how to work together. They were using email and documents as their primary means of collaboration. Quite often, it would take days to sort out a simple interaction 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 emerged in a local (US) team’s retrospective. It turned out that nobody had ever “met” the offshore Singapore team 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 near our size and composition. The remote team began filling the room… and filling… and filling.
In the end, over 30 people filed into the Singapore room to our amazement. During the course of the introduction we had some quick realizations:
- We had previously assumed some males were females 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 they knew much more than we had been giving them credit for … who knew?
- We learned they were heavily multitasking and being interrupted across many projects. Ours wasn’t their highest priority … who knew?
- We finally realized they didn’t like this “agile stuff” and preferred more traditional development approaches. 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 had this meeting not happened first thing when the teams were formed and the project begun? They could have avoided a tremendous amount of frustration, waste, and missed progress. Who knew?
Perhaps I convinced you that a fundamental aspect of successfully implementing distributed agile is how you start your teams and projects. Here’s a checklist of three core starting patterns as well as some tips you can use to help 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 each team has some experienced technical leadership. Also ensure 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 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 time early to establish team and cross-team roles and responsibilities and/or rules of engagement 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.” That should be their first goal.
Establish Norms, Standards, and a Character
- 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. This includes members of each team and teams who 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 in the Art of the START, of questions attendees often ask about distributed agile teams, here’s another question I hear a lot:
Do we really have to do _______? It’s really hard to support that agile practice because we’re distributed!
You can 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.” 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 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 up to the business to commit to properly starting their projects, and the teams to commit to agility to figure out how to drive great results.
It’s simply another choice as you “go agile.” Please choose wisely.
Stay agile my friends,
Bob.
For Further Reading
- A related blog post from Johanna Rothman and Shane Hastie: http://goo.gl/YypJY
- I highly recommend a wonderful book related to Agile Chartering. The title is Liftoff: Launching Agile Projects & Teams by Diana Larsen and Ainsley Nies.
Up Next:
Do you want more effective, self-directed agile teams?
Watch our free webinar for best practices on Essential Patterns of Mature Agile Teams. Please apply password, “ZenBox284” to watch.
