The 10th annual State of Agile Report is out.  I love reading the results of these surveys, as I learn so much about what other businesses are thinking and doing in the agile software development arena. Each year the results show the growth of acceptance and adoption of agile around the world. Gone are the days when recruiters would tell me to “get that agile stuff (or some word like that) off of your resume, or I can’t even get you an interview”. That is the good news!

But the survey also brings to light some uncomfortable facts about how agile is being attempted or practiced in the real world. This is just as important as all of the happy news. Identifying what is not going well is more important than just feeling good about the fact that all of this “agile stuff” is starting to take hold. Just as inspecting and adapting is built into our psyche as agilists, we need to apply it to our own movement.

One item that really stood out for me was the fact that more than 80% of responding organizations are distributed at some level. This is an incredibly high number, and more than twice the level it was last year. All of the research and experiential learning shows that one of the best things you can do for productivity and communications is to co-locate your teams. So is this a problem? I think it is. Teams need to be able to talk to each other, and should be able to do it without having to schedule a conference call, not to mention dealing with time zone issues.

Distributed Agile Teams

One of the 12 principles of Agile Software Development is “The most efficient and effective method of conveying information to and within a development team is face to face conversation”.  So distributed teams mean that we can at best be 11 and 1 in our agile world.  And the odds are not in our favor that this is the only thing we are “setting aside”.

So is this all bad? I don’t think so. But it is something we need to address and work on. First, let’s ask ourselves if we absolutely must have these teams distributed.  Just because they always were distributed, doesn’t mean they still need to be. If we absolutely must have distributed teams, we need to find the best way to facilitate conversation. What are some options we can consider to help that happen?

Form Teams Around Location

If you can, make the team at each location a fully functioning team. Rather than having QA in Denver and Development in Dublin, have a team in Denver that handles some features, and a team in Dublin that handles others. Or, if you can, just have each team pull from a common backlog. Emphasize the need to eliminate any perceived dependencies rather than just identifying them with yarn.

Anything But Email

Email continues to maintain its status as the world’s worst form of communication we’ve ever invented. There are many good online chat tools, as well as using Conversations in VersionOne that can help remove the formality that gets in the way of real conversation.

Respect

One of the most important, and least recognized, challenges to a distributed team is the “senior partner/junior partner” attitude that pervades most distributed arrangements. No team should be called “the offshore team” or “the remote team”.  Make sure to alter times for meetings so that the same team isn’t inconvenienced every time. It is better for each team to share the inconvenience of time zone disparities.

So yes, while I would love for all teams to be able to engage in face-to-face conversation, the world is clearly moving to multiple distributed environments. We could rail against this, or we can learn to work with this reality and find ways to make it as effective as possible.

Find out more by downloading the 10th annual State of Agile Report.

State of Agile is a trademark of VersionOne Inc.

728x90-red-demo

Join the Discussion

    • Mike McLaughlin

      All great points, Steve. I’ve seen more and more orgs with distributed Scrum teams across multiple time zones in the past several years. I think it’s driven in large part from the desire to cut costs, as hourly rates tend to be about half of what they are here in the US, compared with India or China. Time zone differences are the tricky bit, particularly when there’s more than 8 hours difference. Having fully functioning Scrum Teams in each location (time zone) is better, and seems to work well when we have a Proxy Product Owner in that location, and they’re sync’ing with the Product Owner on a regular basis. By the way, love the feature in VersionOne where we can have ‘conversations’. Great way to document and avoid the use of email. Everybody can see what’s going on and it’s tied to a particular story or other asset in the tool.

    44 + = 45