As IT organizations introduce agile ways of working, they often run head-on into an existing business model that seems incompatible: traditional outsourcing. The agile model, with its strong focus on teamwork, frequently clashes with the traditional outsourcing model, which requires contracting with vendors whose staffs are trained primarily to follow instructions rather than work collaboratively.

To make the agile approach successful, IT organizations often assume that they must insource most of their development processes and forego sizable outsourcing benefits, such as reduced fixed costs and increased access to valuable skill sets. But organizations can introduce agile and continue to outsource. When companies create strong partnerships with vendors, IT organizations can blend in-house and vendor teams into cohesive units that achieve breakthrough performance.  

Getting Started

In a traditional outsourcing relationship, an IT team “throws a project over the wall” to a vendor; the vendor, in turn, completes its tasks and throws the project back. Although this arrangement works well for IT projects that use the waterfall model, which dictates that work cascade from one step to the next, this setup fails when it encounters the agile work process.

Agile demands that an interdisciplinary team works closely together during agile sprints (development intervals of one month or less). Agile maintains that a team shares information, solves problems, creates minimum viable products, and fails fast. And it asks that team members work as equals and that they be given the flexibility to change direction quickly. For the agile model to succeed, one team cannot punt to another; the members of both must execute together.

To foster this working relationship, companies should partner with vendors, tearing down the walls and enabling agile team members to work side by side, whether virtually or physically, to achieve their goals. This approach, which we call distributed agile, creates squads that are composed of company and vendor staff members. All team members participate as equals and work with a one-team mindset to understand the end user’s needs and to find solutions. (See Exhibit 1.) 

Many organizations have formed productive and enthusiastic teams by taking this distributed agile approach, while sustaining the cost savings originally generated by outsourcing. (See the sidebar “Distributed Agile in Action.”) Getting started requires three steps.

Evaluate distributed agile models. To create an effective partnership, a company and a vendor must begin by evaluating distributed agile models. We’ve defined three. (See Exhibit 2.)

In the first model, most team members are onsite at one of the company’s primary locations and report to either the company or the vendor, depending on the long-term development plans.

The second model is similar in that the product owners (POs), scrum masters, and business analysts are onsite at one of the company’s primary locations; however, all developers and quality assurance specialists in this model are situated at one of the vendor’s locations.

The third model specifies that only the POs are situated at one of the company’s primary locations, while all other members are situated at one of the vendor’s locations.

Note that POs are typically company employees, because they need to be close to the business to understand its requirements and priorities. Scrum masters and business analysts can be employees of either the company or the vendor. And developers and testers are typically employed by the vendor.  

Determine the importance of collocation. Some companies think that agile development mandates collocation, but the need for collocation depends on the project. A company developing a mobile home-shopping app knew that it was critical to understand its potential customers in order to create a buying experience that met their expectations, so the company required that the product owner and key team members collocate in the target market. Another company insisted that its peer-to-peer payment app be developed by a collocated onshore team, given that the requirements—and the competition—were evolving quickly. In contrast, a company that was migrating its call center platform saw no need for collocation, because the desired functionality, requirements, and integration points were well understood by all.

Choose the distributed agile model. Deciding on the most appropriate distributed agile model for each project or stage of development will mean understanding and accepting the relevant tradeoffs, particularly in terms of available expertise, costs, and collaboration.

Most companies prefer the first or second model. While these models are more expensive, companies can more easily take advantage of their in-house skills, experience, and business knowledge. In addition, most companies find it relatively easy to set up a team at one of their locations rather than at a vendor’s, particularly if the vendor is situated offshore. No matter which model is chosen, companies and vendors will want to collocate the majority of their team members for two or three sprint cycles before moving core team members to their ultimate location full-time, given that teams need time to adapt to new collaborative practices.

Many companies and vendors choose a distributed agile model and stay with it, while others try the different models over time or make a selection on a project-by-project basis. If a company’s systems are stable and the processes under development are not critical to the business, for example, the company may be open to using the third model from the start. If the processes under development are critical, the company may feel more strongly about starting with the first model and only shifting to the second or third model as the partnership develops.

The Partnership Approach

After the company and the vendor have agreed on a distributed agile model, they can set up their new partnership, which must have three interdependent parts: a new contract, new team practices, and tools and technologies to enhance team communication and productivity.

A New Contract

When companies and vendors partner with each other, they risk being locked into the relationship. As a result, managing the company-vendor relationship is as critical as ever. This requires a well-written, legally binding contract—one that clearly establishes charging mechanisms and governance methods, including KPIs.

The new contract must reflect the change in the company-vendor outsourcing relationship from a traditional one to a partnership model. For example, whereas the traditional vendor relationship may require a fixed-price contract for developing a predefined product or service, a partnership requires a contract that allows the company to effectively hire resources from the vendor for a preordained period.

The KPIs must also change. Traditional vendor contracts typically call for measuring KPIs such as the time it takes to fix a problem. The new contract should allow for measuring different KPIs. For example: Did the vendor assign the right people with the right skills and experience to the team? Did the vendor allocate the appropriate number of dedicated resources and what was the attrition rate? How well did team members collaborate? And how much work did the team tackle during a single sprint? 

New Team Practices

The reporting dynamic in a distributed agile model is different from that in a more traditional outsourcing model: although there are still various levels of expertise and seniority, everyone works on, and contributes to, the same product. A number of best practices will help smooth the way.

Build a shared culture. One of the most important practices in distributed agile is building a culture in which people share an understanding of agile principles and the role that each individual will play. The company should coach and encourage its employees—as well as the vendor’s employees and leadership—to make this cultural change a success.

The company’s employees, in particular, may have to learn how to change their behavior toward the vendor’s employees. For example, the company’s staff should refer to an agile squad as the team; using terms such as the vendor team and the company team reinforces differences rather than unity. In addition, team members should be considerate of each other. For example, if vendor employees are offshore, they should not be the ones who always work late; instead, team members should alternate staying late or coming in early. Even small cultural adjustments can make an outsized difference.

Facilitate collocation. Another important practice, no matter which model is chosen, is collocation. It can be particularly important during the first two or three sprints and just before any essential, quantifiable deliverables are due. Some team members should collocate throughout that initial stage, and teams can send ambassadors to visit company and vendor sites on a recurring basis. However, after a team is well integrated, it can reduce how frequently ambassadors visit. When not collocated, squad members who are located in different time zones will need to adjust their work schedules to create dedicated time slots with a three- to four-hour overlap so that they can communicate with other members using videoconferencing tools.

Make a full commitment. A team must be fully committed to all agile ceremonies, which take place biweekly to discuss progress, demonstrate projects under development, and divide the work among team members. These ceremonies should be held at a time when all team members, even those in different time zones, can attend. In addition, team members should be coached to understand that every meeting is important.

Empower vendor resources. If a vendor’s employees are unable to make their own judgment calls, progress will be slowed. Instead, the company should ensure that vendor resources are empowered to make decisions and move forward between meetings, rather than waiting for permission from the PO. If they make a mistake, it can be fixed—particularly given the highly iterative nature of agile development. In our experience, companies that empower developers to begin writing code on the basis of their own understanding of an application can circle back to the PO with a prototype, instead of waiting for confirmation or clarification before they proceed.

Tools and Technologies

Companies that implement distributed agile should use tools and technologies to enhance communication and productivity. Basic collaboration tools for screen sharing and messaging are the minimum enablers for effective interaction. Teams also need communication tools that can bring everyone together for live discussions. The company and vendor should therefore ensure that all members of a team are on the same enterprise platform and that everyone has access to high-quality audio and video equipment for conferencing, as well as to tools that support collaborative writing and whiteboard sessions.

In addition, all team members should have access to agile life cycle management tools, such as Jira Software, which will improve transparency and help track KPIs. They should also have access to the same development environment for building, testing, and deploying new products and services. And companies should establish an integrated pipeline of work that allows team members in different time zones to continue to work on products after members in other time zones have finished their day’s work.

Collaboration may not always be straightforward. In one instance, a company found that offshore team members were continually missing videoconferences with US-based members—but not for the reasons it expected. The offshore members had a number of practical constraints. For example, the offshore members couldn’t stay late for videoconferences because the area around the office wasn’t safe at night, and the team members couldn’t join videoconferences from home because they lacked the required internet bandwidth. The company and vendor quickly resolved this issue by paying for high-speed internet connections in the homes of those who needed it.

Implementing agile ways of working throughout the IT organization is a journey—a long one. Recruiting a vendor as a partner for the journey lets companies transform IT development while continuing to reap the benefits of outsourcing. This distributed agile partnership requires that a company and a vendor cooperate on many levels, learn from the results, and adapt together. For those that get it right, the rewards are large, including significantly lower costs, access to a large pool of technology-savvy talent, and an ability to work continuously and rapidly, even across multiple time zones.