Successfully Implementing Location-Independent Agile Teams

There are three aspects to successfully implementing location-independent agile teams: 1. Assess the organization’s distribution of business expertise, the nature of work, and agile maturity. 2. Choose the right agile working model to meet the organization’s needs. 3. Continuously improve the agile capabilities of the teams to gain the benefits of location-independent agile. First: Assess the Organization 1 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 commonunderstanding 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 2 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 4). 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 Model 1 Model 2 Model Model Business Knowledge Not Medium to 3 4 at Distributed Location Applicable High High High Nature/Criticality Regulatory/ All Except All Except All Except of Effort Urgent/ Regulatory/ Regulatory/ Regulatory/ Volatile Urgent/Volatile Urgent/Volatile Urgent/Volatile Organization’s Nil Low to Medium High Experience in Agile to Low Medium to High Way of Working Figure 4: 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 work in parallel across time zones, organizations experience dramatic an organization can accomplish benefits after successfully more in the same time than co- deploying one of these four located teams that are limited by location-independent agile models. an eight-hour work day. Leveraging For example: 24-hour, five- days-a-week development coverage with •Location-independence makes an significantly distributed (Model 3) enterprise more agile. Using the teams across U.S., India, and minimally distributed model Mexico, a large financial company (Model 2), a large U.S. retailer was able to cut the time it took to with a delivery team of 1,500+ introduce new products to market members in India reduced its IT by 78%. operations costs by 20% and improved end customer • By sharing skills across multiple satisfaction by 40% in 18 months. teams in different locations, These benefits resulted from a companies can accelerate work combination of steps, including without requiring business experts role rationalization, product re- to participate in daily decision architecting, and the application of making. One U.S. retailer was able DevOps practices for automating to complete an integrated channel newproduct deployment. delivery project in just 11 months (DevOps is an approach to IT with fully distributed teams (Model software development and 4) by leveraging the domain skills operations that emphasizes of product specialists in many automation to speed up software locations. While product owners still building, testing, and installation.) have to make prioritization decisions and confirm product •Location-independence makes an acceptance, they can delegate enterprise more productive. By significant amounts of knowledge using all 24 hours available to work involved in product execute development.

Third: Improve the Agile Capabilities of 3 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.