Geographically Distributed Agile Teams Have Choices for Their Lifecycles

I hope that by now you see that you have any number of choices for your lifecycle if you are geographically distributed team and you are transitioning to agile. I do recommend a servant leader agile project manager, for coordination and risk management. With people all over the world, it's difficult to coordinate the project, which leads to more risk.

Scrum is often not the best approach to geographically distributed agile. That does not mean the distributed team should not go agile. It just means they should not use Scrum. If the distributed team can all travel to one place so they can get trained by the same Scrum trainer together, and if they can take the opportunity to talk together to discuss what they need from the Scrum Master then maybe they can use Scrum, especially if they use their retrospectives well. It's a lot of responsibility for the team new to agile and new to Scrum. If you're a team new to agile and new to Scrum, and you try this, do yourself a favor and use a coach.

Electronic tools do not always make seeing and managing the risk easier when you first start–tools can prevent transparency until you understand what you are doing. I like starting with stickies or cards on a wall or board, and as the team members learn how to work, and what they, as a team need, then choosing a tool. I don't see how to choose a tool before you know what tool you need. One tip: do not allow your management to select a tool for you. You, as a team, can select a tool for yourself. You might start with digital pictures of your task board on a project wiki before you decide which tool to use.

Let me recap:

Agile Lifecycles for Geographically Distributed Teams, Part 1 discussed iterations and silo'd teams.

Agile Lifecycles for Geographically Distributed Teams, Part 2 discussed kanban and silo'd teams.

I got all hot under the collar and discussed Why an Agile Project Manager is Not a Scrum Master.

Agile Lifecycles for Geographically Distributed Teams, Part 3 discussed iterations and kanban and silo'd teams.

You should also read What Lifecycle? Selecting the Right Model for Your Project.

If you have several teams all working towards one business goal, you have a program, and that is a different problem. Look for more blog posts on that, later.

These are precisely the problems no one teaches you in project management certification courses. If you have read Manage It! Your Guide to Modern, Pragmatic Project Management, you know I consider knowledge of different lifecycles necessary for project managers.

Project managers who try to control their teams better have a darn good reason—these people are adults. They manage the rest of their lives. Are you trying to tell me they can't manage their work? And, these are the problems that can cause geographically distributed projects to fail, splat.

4 Replies to “Geographically Distributed Agile Teams Have Choices for Their Lifecycles”

  1. I think you’ve got got some good ideas and experience for dealing with distributed teams. But I think you’re splitting semantic hairs by saying this is not Scrum.

    Certainly this is not pure Scrum, but it is based on Scrum and tailored to the circumstances. You could have easily called it “Distributed Scrum” rather than “NOT Scrum”.

    At my company we believe that Scrum’s adaptability is one of its strengths, and every team adapts the process to their unique circumstances (if we didn’t do that we wouldn’t be very agile).

    But if you insist on a “purity test” then I guess my entire company (and its 5,000 software engineers) is practicing “NOT Scrum”.

  2. Yes, we call them Scrum Masters. Our basic core process is Scrum plus the technical practices (from XP) of automated testing and continuous integration. We use Lean principles to guide both tailoring decisions for individual teams, and to guide scaling to larger multi-team programs.

  3. I should add that our program/project managers do not usually become Scrum Masters when they transition to agile (it does sometimes happen, but only for small teams). They are usually responsible for multiple teams, and don’t normally take on a active team role (we have had a few cases where they have taken on the product owner role).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.