Many organizations find themselves faced with the challenge of making distributed agile work. Mergers and market consolidation, geographic expansion, and offshoring have made multi-site development the norm rather than the exception. Companies with sites in competitive labor markets can find distributed team members as an alternative when they can’t recruit locally.
Agile can work in a distributed environment, but it’s a lot of work; more work than you'd expect if you've never done it before. Here are eight hacks that can make it easier.
Reasons why distributing the team might make sense
You might not be able to get all the people with the right skills in the same location, but the world is filled with talented, motivated people, and being open to working in a distributed way opens up your options.
In addition, today’s technical professionals have more choices about where they live and work. They may like where they live and not want to move. In short, the people you need may not all live in the same location.
Local knowledge matters. If you’re developing a product that needs to appeal to customers in different countries around the world, you’ll need people who know the local culture and language. There are also political or security reasons for distributing development—from tax advantages for doing work in certain countries, to restrictions on data crossing country borders, to the need for people on the team with particular security clearances.
As you can see, there are a lot of reasons a company would choose to have a distributed team, and whether we like it or not, the number of remote workers is only going to grow. With that in mind, here are eight simple distributed-agile hacks that can set the right tone for a successful remote team.
Recruit motivated individuals
It is possible to make distributed development work; open-source projects do it all the time. They have a couple of advantages that other initiatives often lack.
- Their team members are often exceptionally self-motivated, at least if they are committers.
- They often don’t have to deal with stakeholders or requirements, because they are often building a project for themselves, so they know the problem domain very well.
In more normal situations, having highly motivated team members is really important, and the remote team members are going to have to be exceptionally self-motivated. that's because they are going to have to work harder to communicate, stay engaged, and stay focused and productive. They won’t have the informal network of co-located team members to fall back on.
The co-located team members are going to have to work harder, too. They are going to have to make a special effort to engage their remote team members.
Invest in self-organizing teams
The worst thing to do when forming any team is to assign people to work on it; it kills motivation and destroys initiative. Since distributed work is even harder than co-located work—because it requires even greater motivation—the distributed team needs to be strong, with members who are committed to the mission, to the way of working, and to each other. That level of commitment doesn’t happen by accident.
Letting people choose to be part of the team—to work with one another—is an important first step. They must want to work in an agile way, and they must want to work with one another. Let people volunteer to join the effort, and then bring them together to establish their norms and working agreements.
Co-locate, at the start, to let teams form, storm, and norm
Forming a team usually takes at least a couple of sprints, sometimes longer. You will make your life, and theirs, much harder if you don’t invest in helping them develop into a high-performing team. It takes time and experience working together as a team to develop the trust, commitment, and mutual accountability that they need to perform well together and to be transparent about the state of the work.
Artificial team-building exercises do little to help teams go through the forming-storming-norming-performing process. Bringing teams together for a couple of sprints is really the best way to develop the working relationships that are essential to future performance.
If the effort is large, have co-located teams at each site
Let’s say that an organization has sites in multiple locations, as well as multiple teams, each with team members at every location. In this situation, you're going to end up maximizing the amount of extra work for everyone.
Instead, you should try to form co-located teams at each location and let them figure out how to share the work among themselves, extending Scrum with a scaled agile approach such as SAFe or Nexus. In this approach, multiple teams are working on the same product.
With a scaled Scrum approach such as Nexus, you help multiple Scrum teams simplify cross-team collaboration by resolving and preventing cross-team conflicts and ensuring that they deliver an integrated product increment with every sprint.
Regardless of which framework you use, you should make sure each team has a Scrum master. Masters will not only help their own team perform better, but they will also help everyone else who needs to collaborate with that team.
Co-locate development teams with their product owner
This sounds obvious, but I’ve encountered plenty of strange situations where this is not the case. I've seen companies with the development team in one location and the product owner in another. This really hurts collaboration and communication, so don’t do it. Find a different team or a different product owner, move the product owner, or empower a local delegate for the remote product owner if the product owner is co-located with another team.
Invest in collaboration technology, but invest first in teams
Collaboration technology really helps teams be more effective—distributed source-code management, continuous integration, continuous delivery tools, wikis, video conferencing, and chat platforms such as Slack all help high-performance distributed teams be more effective. But they can’t make a low-performance team into a high-performance team. Lack of these tools can reduce the effectiveness of even a high-performance team, however.
Share the pain of time-zone separation
When a team has members at multiple sites, they demonstrate mutual respect by sharing the burden of working odd hours. Some teams make the mistake of having the team with the most members set the workday rules, but this sends the message to teams at other sites that their contributions are not valued as much. Making everyone share the burden is not only fairer, but it also creates a sense of empathy with what other team members have to endure.
Minimize hand-offs and wait times
Time zones increase wait times. When a person at one site must wait for a team member at another to start the day in order to resolve a blocking issue, the rest of the day is lost. These delays add up. The daily stand-up can help uncover these problems, but the team will have to look not only at today’s work but potentially at tomorrow’s as well to know what issues might block them. It won’t be perfect, however, and some additional delay is inevitable.
Flattening roles and refining the product backlog to spot potential conflicts earlier can help. With dependencies reduced, and with teams having members who potentially can work on any product backlog item, blocking issues and slow hand-offs will be less frequent. But the issues can’t be completely eliminated.
No shortcuts to great teams
Distributed agile development is harder than co-located agile development. Time zone differences make collaboration more challenging. However, teams with members working at the same site but in different buildings will find collaboration more challenging as well. Being agile requires transparency, which doesn't exist unless team members trust one another, and developing trust requires time spent working together.
Organizations make a big mistake when they think of teams as simply a group of individuals. A great team is far more than the sum of its members’ contributions. Being part of a great team is motivating—it challenges people to do their best, and it rewards them with a sense of shared accomplishment that individual accomplishment cannot. Great teams take time and investment to build, and they are worth protecting when they come together.
When distributing work, for whatever reason, focus on forming great teams. These teams can be formed with distributed individuals if they are motivated and supported, but it does take more work on everyone’s part.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
