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?
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.
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:
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.
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:
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)
Train the Team Together
Establish Norms, Standards, and a Character
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.
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.
Up Next:
Watch our free webinar for best practices on Essential Patterns of Mature Agile Teams. Please apply password, “ZenBox284” to watch.