Building or Maintaining Agility in Geographically Distributed Teams

By now, with all of my tips, you have a good idea about how to start a project with your geographically distributed team.

You have a project charter.
You have a timezone bubble chart. That helps everyone see where people are in the world.

Those two things help everyone know the goal and what their timezone differences are. In addition, you and the team have considered collaboration needs:

How to build trust,
How to use checkins to create transparency,
Avoid micromanagement,
The goals for the team: what the team needs to build.

Now, it's a simple matter of building and maintaining agility. Or, is it? Anytime you hear anyone say, “It's a simple matter…” you can be sure nothing is simple.

Outcomes Are Not a Simple Matter of Anything!

Agility is not about the mechanics of iteration or flow. Agility is all about the team's collaboration to release business value at a sustainable pace as they adapt to what the business needs. The agile practices support delivering business value at regular intervals so that the team can keep doing this forever.

Is your team organized for sustainable pace? If not, what would you have to do to create sustainable pace?
Is your team ready for releasing business value at regular intervals? If not, what would you have to do?
Is your team and the organization ready to adapt to changing needs? If not, what would you have to do?

Do you and your team know how to use the power of the iteration or flow to be most effective for your organization?

There is not just One Right Way to be agile. You might want to read my series about lifecycle choices.

Once you are organized for agile success, you have to maintain the project. That's when risk and our friend Murphy and his law raises his happy head.

Manage the Risks Before they Manage You

Unmanaged risk is the biggest threat to maintaining agility in a distributed team. And, because much of the risk is that the team is invisible to each other and the rest of the people in the organization, the agile servant leader can always monitor these areas to reduce risk:

Make sure the people who can't see the team supply the team with the requirements in the way the team needs.
Make sure the team is ready to demo and the people who supply the requirements are ready to see the demo.
Make sure there is a roadmap of requirements for the product, and that the roadmap is updated on a regular basis.
Make sure there is a servant leader who continues to remove the team's obstacles.
Make sure the servant leader continues to remind the team that there is always another way to solve the problems the team encounters.

If you don't have a servant leader for your geographically distributed agile team, your risks will multiply. Your team will not succeed.

With a servant leader demonstrating agility, the team has help and a risk manager. It's one of the best ways to maintain agility in your distributed team.

Related 2012 Newsletters

I wrote these newsletters in preparation for a workshop Shane Hastie and I delivered in 2012. That was a tremendous success and led to my work with Mark Kilby on From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver.

The newsletter series:

Useful Links

The Pragmatic Manager newsletter archive
My books
Managing Product Development blog
Create an Adaptable Life blog

Johanna

Vol 9, #9, ISSN: 2164-1196