While it is very beneficial to have all the team members of small agile teams co-located, insisting on having all inter-related agile teams in the same location is not worth the effort and is unrealistic in today’s global business environment. In fact, in the last article of this issue of Perspectives (“Why Your Agile Team is Better Off Dispersed: The Case for Location-Independent Agile”), TCS makes the case that agile programs whose teams are distributed can more quickly develop new processes and systems that are more on target with customer needs.
In our own work, we have observed several hundred projects that use location-independent agile teams. Given the challenges involved, it is clear that one way of working does not fit all projects.
For example, some projects may be best suited to having agile teams co-located, at least at first, while others may succeed best with contributions from different agile teams in many places. Companies that are new to agile approaches can also benefit from starting with co-located teams as they work to build distributed capabilities. Which model a company chooses will depend on a variety of factors, including the business knowledge needed and where it resides, whether the work is urgent or has non-negotiable constraints, and the maturity of the organization’s agile development processes.
There are three aspects to successfully implementing location-independent agile teams:
Assess the organization’s distribution of business expertise, the nature of work, and agile maturity.
Choose the right agile working model to meet the organization’s needs.
Continuously improve the agile capabilities of the teams to gain the benefits of location-independent agile.
First: Assess the Organization
Use the three criteria referenced above to determine the organization’s capabilities for location-independent work. Answer these questions:
What is the level of business expertise and other skills required, and to what extent do they exist at a specific location? If a location lacks business expertise, it will require more of it to be able to support agile teams there. As team members accumulate experience, they will build business knowledge, making them both more valuable, and more able to work as part of a distributed organization.
How urgent and volatile is the work? At first, location-independent agile teams should focus on work that is neither urgent nor volatile. If the work is both, if it has non-negotiable constraints (such as overnight fixes, intra-day scope changes, or regulatory requirements), or if there is a need for constant access to the project owner, it’s best to work with teams in the same location, if at all possible.
How mature is the organization? When teams are relatively new to agile approaches, team members should be co-located. Having a common understanding of agile culture, especially among the leadership, indicates the organization can succeed with location-independent teams.
Having a clear understanding of the organization’s starting point will point leaders to select the best approach for moving forward.
Second: Choose the Right Location Model
We have identified four potential models for organizing agile teams, ranging from teams that should start in the same location to those that can be effective in a highly-distributed arrangement (see Figure 1). Descriptions of the models follow:
Local (Model 1)
This model is best when the teams are new to the business area, when continuous access to a product owner is paramount, or when regulatory concerns require the project to be executed in a specific geography. However, when a project or program is ready to scale up, enterprises will need to consider evolving to one of the other models.
Minimally Distributed (Model 2)
The product owner and a few members of a project or program are located together as one team, while the rest of them work together as another inter-related team in a different place. This model requires the teams to understand the underlying business processes for their product. They will still need frequent access to the product owner and infrastructure teams for business decisions and infrastructure privileges.
When it’s time to expand the project or program, enterprises using the Minimally Distributed model will need to adopt one of the remaining two models for quick on-boarding of talent in additional locations.
Location-Independent Agile Model
Figure 1: Four Models of Location-Independent Agile
Significantly Distributed (Model 3)
The product owner and few members of a project or program team are located together as one team, while other teams working with them reside in multiple locations. Enterprises that have already distributed teams with a shared understanding of the business processes of a project or program are well positioned to adopt significantly distributed agile work processes. This model not only offers the scale for enterprises to deliver large programs as well as frequent releases by increasing their access to the right talent, it also provides for business continuity.
Fully Distributed (Model 4)
The product owner may be at any site, while the rest of the project or program team members are grouped in agile teams across distributed locations. These teams each include product specialists with sufficient business knowledge to drive day-to- day decisions within a framework defined by the product owner.
A Fully Distributed model is useful when enterprises need to empower teams with independent decision-making capability, such as when business experts do not have enough bandwidth to drive product leadership on a daily basis.
We have observed that many organizations experience dramatic benefits after successfully deploying one of these four location-independent agile models. For example:
Location-independence makes an enterprise more agile. Using the minimally distributed model (Model 2), a large U.S. retailer with a delivery team of 1,500+ members in India reduced its IT operations costs by 20% and improved end customer satisfaction by 40% in 18 months. These benefits resulted from a combination of steps, including role rationalization, product re- architecting, and the application of DevOps practices for automating new product deployment. (DevOps is an approach to IT software development and operations that emphasizes automation to speed up software building, testing, and installation.)
Location-independence makes an enterprise more productive. By using all 24 hours available to execute work in parallel across time zones, an organization can accomplish more in the same time than co-located teams that are limited by an eight-hour work day. Leveraging 24-hour, five- days-a-week development coverage with significantly distributed (Model 3) teams across U.S., India, and Mexico, a large financial company was able to cut the time it took to introduce new products to market by 78%.
By sharing skills across multiple teams in different locations, companies can accelerate work without requiring business experts to participate in daily decision making. One U.S. retailer was able to complete an integrated channel delivery project in just 11 months with fully distributed teams (Model 4) by leveraging the domain skills of product specialists in many locations. While product owners still have to make prioritization decisions and confirm product acceptance, they can delegate significant amounts of knowledge work involved in product development.
Third: Improve the Agile Capabilities of Teams
Organizations that want to move from the Local model to one of the location-independent models can improve their agile capabilities in five ways:
1. Build business knowledge-oriented teams at distributed locations. Consistently seek to optimize each team’s product and business expertise by promoting the team structure around business concepts. A U.S. retailer was able to move from a fully co-located model to a minimally distributed model in three months by relocating some experienced team members with business knowledge to another location, and leveraging their expertise to form a new team around this business knowledge.
2. Configure teams to take advantage of time-zone differences. For effective collaboration and communication, agile teams need a minimum overlap across time zones. Calibrate each team’s work hours so that as one team heads home, another team can pick up the work, with enough time for communication to ensure it continues at a steady, sustainable pace, with minimal confusion.
Take the experience of a leading U.S. bank as an example. The bank had one team in Texas, and another in Chennai, India. The teams adjusted their hours to overlap based on how much time they needed to resolve their interdependencies. They became motivated to improve how they worked to reduce the number of overlapping hours they needed.
3. Minimize planning overhead. An Australian retailer synced up the sprints and product releases of its three agile teams, reducing the teams’ planning time by 20%. To achieve such results, it’s critical to automate as much of the teams’ work as possible using DevOps automation and design engineering practices.
4. Create a ‘one team’ culture. Teams across the enterprise should use the same agile practices, same work and infrastructure privileges, and share common work characteristics. Culture coaches can help geographically distributed teams understand and appreciate their cultural differences, ensuring the teams have healthy working relationships.
5. Plan the right distribution of work across locations. Organize the work to minimize dependencies across teams while maximizing workflow. At a European telecom provider, software development teams were originally aligned on horizontal areas such as routers and signal processors. When it created agile teams, it restructured to focus on business features such as customer gateways, thereby reducing dependencies among the horizontal areas and enabling more frequent and value-added product releases.
Overcoming Skills, Process, and IT System Challenges
As the scale of change involved suggests, aligning multiple agile teams located in different time zones and countries is a complex endeavor. Challenges may emerge involving shortages of the right skills, employees’ adapting to new work processes, and a company’s IT infrastructure.
To get the most from location- independent agile teams, an enterprise needs to put people with the right skills in the right places. In addition to universal coaching and training in agile practices, one way to do this is to train team members in more than one skill.
For example, instead of having some team members who are application developers and others who are testers, train some people to be adept at both jobs.
Legacy ways of working, and employee attitudes toward them, can hinder the cultural change needed to pursue agile. Some employees will have trouble adapting. They can benefit from coaching that goes beyond teaching agile techniques to practicing new roles. Hands-on practice will help them understand the benefits of pursuing agile approaches to their own work lives.
One important stumbling block to setting up distributed agile teams is frequently the existing enterprise IT architecture which may not support agile ways of working. The systems that underlie the work of developing and releasing new products must be able to handle increased production loads. For example, if an agile team has to produce a product in two weeks, and the supporting architecture requires more than a two-week lead time to schedule a test, the agile team will fail to meet its deadline and become demotivated. Furthermore, the ripples of that failure will hurt productivity across other teams and degrade the company’s ability to innovate. Leaders should assess the strength of the company’s IT architecture when they start planning for agile adoption to identify the necessary improvements.
Capturing the Benefits of Location-Independent Agile
It is possible to take advantage of distributed agile teams and thereby maximize enterprise productivity and innovation, but companies need to know how to do it correctly.
That means knowing yourself—your business expertise, where it resides—and the level of your agile maturity. It also means determining the right location model for your work—local, minimally, significantly, or fully distributed—based on your business’s needs, goals, capabilities, and the competitive landscape.
As your organization gains experience, you can move up the ladder toward a more fully distributed model. With advancement comes the opportunity to acquire additional benefits from organizational agility, as well as the ability to compete more successfully on a global scale.