Enter your keyword

post

Can Distributed Agile Teams Work?

Can Distributed Agile Teams Work?

“One trend to watch is the increasing involvement of offshore teams in agile development. Although collocation is important, as long as the developers and testers are in the same time zone, even if not in the same physical location, agile will work.”  Gerie Owen

Can Distributed Agile Teams Work?

The concept of offshore agile development has received popularity over a number of years, primarily because of the ability to save time, cost and optimization of product development procedures. There are a lot of companies that rely upon offshore teams to deliver quality services within the prescribed time. When compared with traditional forms of teams, offshore team management involves a lot of challenges and hurdles, including multiple locations, task management, cultural differences, source of communication, time zones and discipline. In fact, many organizations find themselves struggling to make agile work with distributed teams. Expanding by the means of new locations, Mergers and Acquisitions and outsourcing/offshoring has been resulting in companies having to develop across multiple locations as opposed to the prescribed co-located development.

The need to employ an effective methodology that does not only cater all cultures and traditions but also provide favorable conditions to distributed teams to serve with their best.

So is it possible to make Agile work when teams are not co-located?

How do most of the successful company’s manage their offshore Agile teams? What kind of techniques do they employ to keep their scattered team at one place without allowing different cultures and time zones to affect their productivity? Is it possible to make Agile work?

Answer is…..

Yes. Agile can work. But it depends…on the strategy and tactics that are implemented to make it work.

Here are the tactics and strategies that will help you make Agile work with Distributed Teams;

  1. Follow a long term recruitment strategy and Recruit motivated individuals

You will need to invest time in finding exceptionally self-motivated individuals because they will need to work harder to communicate, stay engaged, and stay focused and productive.

  1. Invest in collaboration technology

If you invested enough time to find the right people, you will need to support your motivated teams to be more effective with distributed source-code management, continuous integration, continuous delivery tools, wikis, video conferencing, and chat platforms such as Slack. While helping high performing teams, these tools 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.

  1. Co-locate, at the start, to let teams form, storm, and norm

Avoid old-school team building exercises. Instead invest in bringing teams together for a 4 sprints to develop the working relationships that are essential to future performance.

  1. Invest in more Up-Front Modeling and more Up-Front Planning

Greater the distance, higher the risk. Therefore you will need to invest a little more time (Not Waterfall duration) in exploring the scope the architecture model and planning roadmaps and releases

  1. Stick with Continuous Integration

It sounds like a standard agile thing to integrate regularly and this should be applied even if the teams are distributed. However along with the geographical distance, the larger scope of program can also increase the risk of this strategy if not implemented effectively. In SAFe, the risk is reduced by the use of an Integration team, in DAD, this is done with an Independent Testing team. So keep in mind the complexity of the domain and the size of work before disregarding the need for a Separate test team who can increase the quality while continuously integrating.

  1. Standardize light Governance (DoDs, Defect Reports etc)

Consistency reduces delays in wramping up. Make your development environment consistent across the teams. Create light guides and how-tos, to speed up the set-up.

Have standard way of writing Definition of Dones to make it easier to manage expectations and build rapport across teams. A firm definition of done eliminates ambiguity in the work. For instance, when shipping a release that involves multiple teams, make it clear what it means to be “complete”: code written, pull request created, code reviewed, tested, and merged into the appropriate branch.

Not everyone is online when problems come up. Having clear guidelines for bug reports and troubleshooting how-tos makes it easier for anyone on the team to track down an issue. Code review and good automated tests also share knowledge about the code base and empowers the affected team to make the fix and validate that the change. Thus, no team becomes a blocker.

  1. Ensure regular coordination meetings between locations amongst sub-teams (Prod Man, SMs etc)

Have a boundary spanner who is located on site and focuses on enabling communication between sub-teams throughout the day as well as within their sub-team. Boundary Spanner can be a Scrum Master, a Product Owner or a System Architect.

They should work closely with their peers, having regular coordination meetings across all sub-teams as well as impromptu one-on-one meetings to deal with specific issues between individual sub-teams.

  1. Share the pain of time-zone separation (Use Golden Hours) and Minimize hand-offs and wait times

Ensure there is always an overlap of working hours between each team. The golden hour (when a team is about to knock-off in Australia and another team is about to clock-on in India) is when the daily coordination should be arranged to happen for distributed teams. This is not as perfect as all teams being co-located however this approach will still help avoid some of the delay that is caused by Report and Park (i.e. Email the remote team and wait for a team member to start their day to resolve a blocking issue before you come back to work next day)

So in a nutshell, you can make your distributed teams work in Agile. It is a lot more of work if all teams are new to Agile however once the decision is made and time and effort is invested into employing the right strategy and tactics, it is possible to get returns in terms of improved quality, time-to-market and cost effectiveness.

No Comments

Add your review

Your email address will not be published.