Embracing the Agile Methodology in a Multi-Region Team

By Ryan Kelly

So, your home office had great success using the agile process and now you’re ready to tell the world—specifically, all your company’s global offices. Whatever your adoption reasoning may be, embracing the agile methodology across a multi-region team can be tough, so here are some factors to consider, as well as some best practices.

Getting Buy-In

The first hurdle you may encounter is getting buy-in to use this new and unfamiliar process, so let’s start by talking about how to sell agile to your coworkers across the pond. Addressing the “what, why and how” are the most important questions to answer up front. With that said, let’s address the core components of the agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software/systems over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Keep in mind, this new framework can look scary to someone coming from a different process background, so it’s best to break it down simply:

  • “We want a lightweight process with a team that works closely together, rather than relying on processes and tools to communicate.”
  • “We want our software/system to work, instead of documenting what we know will change as the design evolves.”
  • “We want to work with our customers to build the right software/system, instead of negotiating contracts to decide what will be delivered.”
  • “We want the ability to respond to changing business needs quickly, instead of realizing we built the wrong system six months down the line.”

Now that I’ve introduced some basic concepts, how will the agile methodology accomplish these goals?

The process starts with a backlog of all the stories we’ll need to accomplish to finish the project. The backlog is somewhat analogous to a project plan, but is easier to change over time. A story defines the business requirement and associated tasks to complete the story. And a story or task is only considered complete once all acceptance criteria are met. And once we’ve defined the backlog and stories, the team can start pulling stories into a sprint. A sprint is a two-to-three-week cycle (usually) in which the team has set to accomplish a set of stories.

During a sprint, the team performs five different ceremonies. First, we plan the sprint by pulling new stories from the backlog. During this time, stories are estimated and assigned, and acceptance criteria is refined. Once a week, we groom the backlog by reordering stories to match the realities of priority and availability of resources. New stories can be added and an initial estimate can be made. Every day, a short stand-up meeting is conducted where each team member talks about what tasks were worked on yesterday, what will be worked on today and if there are any blockers. At the end of a sprint, a sprint review meeting occurs with the stakeholders to demonstrate some of the work that has been done. Then the team will meet for a retrospective to discuss process improvements based on what went well, what didn’t go well and what can be done better.

Let’s rewind for a second to this concept of estimation. There are many ways to estimate a story, but my preference is story points. A story point is a relative unit of measurement based on time, complexity and difficulty. A great analogy that I can’t take credit for—and I’m looking at you, Brian Blanchard—is that of measuring a ball. The human brain knows that a baseball is smaller than a basketball. The human brain does not know instinctively that a baseball is 74.68 mm in diameter. So, why do we estimate in such exacting terms if the human brain doesn’t know how to execute it? Instead, we can say one story is bigger than another—and then give it more points. Over a couple of sprints, the team will figure out how many points can be completed in a sprint and, in turn, gives us the team’s velocity. This velocity can then be used to determine the time necessary to complete the entire backlog.

At this point, we know what agile is and how it works, so let’s tie it all together:

Why Iterations/Sprints?

  • Allows for quick feedback cycles and flexibility to change the plan

Why Backlog?

  • Represents the project plan as an ordered list of all issues that need to be executed against

Why Stories/Issues?

  • Captures the business requirement and who’s requesting the requirement in a straightforward way

Why Acceptance Criteria?

  • Reduces confusion about what needs to get done and allows detailed tracking of what’s been completed

Why Story Points?

  • Relative sizing captures complexity, effort and unknowns to create a relative estimate instead of using a precise—but often incorrect—estimate

Why Velocity?

  • Translates story points into duration, which gives a more accurate prediction of how long the project will take

Why Standups?

  • Creates transparency in what work is being done and reveals blockers so that they can be addressed

Why Retrospectives?

  • Gives the team an opportunity to be honest about what’s working and what isn’t in the process

Why Reviews?

  • Ensures stakeholders that progress is being made and gives added transparency to the project

The Self-Directed Team

Our coworkers have now been eased into understanding the agile process, why we would use it and how it’s executed. So, now who’s going to run the project? Well, the team is! The team will choose the stories that they believe they can complete from the top of the backlog—and ordering, estimating, assigning and deciding on an execution strategy for each. By empowering your team to make these decisions, estimates will be more accurate and the timeline will be more realistic. The team then has accountability to complete the tasks they’ve chosen and they’ll be more likely to work hard towards the solution that they have chosen.

Meanwhile, the product manager defines the stories (business requirements) and decides the order in which the team should accomplish those stories. By enforcing this separation of concerns, each side is protected from committing to something they are uncomfortable with in terms of delivery. Agile emphasizes that there is one team and as such, the implementers, the product manager and project manager should be working closely together.

Don’t Split the Team

Effective team cohesion is a big part of agile and represents a unique challenge to multi-region teams. As any good Dungeon Master will tell you, bad things happen when you split the team. Participation by all members of the team in all agile ceremonies is extremely important. Often time zones are a factor in attendance to agile meetings on a multi-region team. If one region must be at work early or late to attend these meetings, switching up the meeting times during each sprint to accommodate a different region may help. In the end, the more people who attend, then the less likely miscommunication and misalignments will occur. Everyone will know what everyone else is working on and what the expectations for each sprints’ deliverables are.

Be Mindful of Cultural Differences

This can mean a lot of different things depending on who you talk to. It can be as simple as knowing that certain countries have different business hours or as complex as navigating class hierarchy to contact the correct person to get a task done. Educate yourself on these differences and talk about them within the team to adjust the process to work for everyone. Thus, your team will be more efficient and more unified moving forward.

It’s Tool Time

Even though it’s important not to overemphasize tools in agile, they can be extremely effective in terms of transparency and teamwork. While there are many agile tools out there, there are three main objectives to meet when utilizing them within a multi-region team:

  • First, they must reflect a physical representation of our backlog and sprints. This way, every region will know what stories are being worked on—and what stories are coming up in the backlog.
  • Second, the tool must be effective in asynchronous communication. This means a chat program that can keep a history of conversation so that teams working—while others are sleeping—can catch up with each other. Full-text search and group chat features included in these tools help direct the conversation to the correct people.
  • Lastly, you’ll need a tool with source control. Any artifacts coming out of the project need to be available to all team members—and not just sitting on Bill’s computer. Particularly, because of time differences, sharing artifacts can become difficult without a source of truth and the ability to see changes over time.

We work with many different versions of these tools, but here are a few of the more popular ones around the office:

  • Agile Planning: JIRA, TFS (VSTS), Trello, LeanKit (Kanban)
  • Asynchronous Communication: Slack, HipChat
  • Source Control: TFS, Bitbucket, Github, GitLab, SVN

It’s All About Teamwork

In the end, the key to any successful agile project boils down to—you guessed it—teamwork. It’s important to achieve cohesion in both local teams and those separated by geographical distance. If you work toward a collective goal with a common understanding and mutual respect, you’ll find that embracing agile in a multi-region team isn’t so scary after all—and you’ll wish you would’ve done it sooner.

As always, follow us on Twitter to stay on top of the latest software development trends and check us out on LinkedIn to learn more about the day-to-day life of consultants like myself.