Applying the Scaled Agile Framework® in an Outsourcing Context: Infogain Case Study


Scaled Agile Framework is applied by many geographically distributed organizations. In some cases, companies choose to leverage their outsourcing partners to establish development centers in remote locations. In this case study, we are going to talk about one such example. Infogain Corporation ( is an outsourcing service provider that adopted SAFe for a number of programs in India to foster alignment with the client stakeholders and teams and to provide reliable, synchronized software delivery mechanisms.

Infogain went through a series of SAFe Quickstarts for its three different programs. Training, consulting, and facilitation of the program level events were provided by Alex Yakyma, SAFe Associate Methodologist and Principle Consultant at Scaled Agile Inc.

Aligning to a Common Vision

When a company engages in offshore outsourcing, one of the common problems is to align the offshore teams to the same business goals as those of the in-house developers and testers. Part of it is in lack of daily communication, part is suboptimal team and program composition and part is a lack of regular programmatic means for elaborating and sharing key business goals with all the teams involved. Building more business on top of misaligned teams is fundamentally wrong. Early in 2012, Infogain had swiftly responded to their big client’s transition to Scaled Agile Framework by fully supporting the process and by creating a favorable environment for the smooth adoption of SAFe practices on their end. It was an important and really welcomed change as all the programs are relatively big (consisting of 35 teams total), operating in highly heterogeneous technology environments for both new product development and maintenance of the existing solutions.

Some of Infogain’s teams were either already operating in the Scrum model or used some Agile practices in different aspects of the process. Nevertheless, all the teams in all three programs went through the same SAFe ScrumXP training as part of the QuickStart to ensure a common way of operating in the context of scale (see Figure 1):

Figure 1. All teams on the train go through the same training with the same instructor at the same time

Most of the teams in India had a local product owner, while some still had remote POs. Over the course of a year, even more teams got their local POs. Previous remote POs would gradually transition into team stakeholder roles. While still helping strategically, they would transfer the authority of tactical decision making to their local counterparts. This change was very helpful as in the preparation to PSI planning Product Management would present top features from the program backlog to the POs and thus give an opportunity to the teams in India to preview the overall scope. This “preview” effort, however, proved to be really effective only when the discussion was instantiated with better and more specific examples of the functionality to be developed. Otherwise some teams would discover gaps in their understanding of the scope during the PSI planning.

Distributed Release Planning

When properly prepared, orchestrated and facilitated, distributed program events, such as PSI planning or Inspect & Adapt, become relatively easy. The process starts with the right people, who are capable of organizing the preparation activities and are able to react to unexpected complications during the process. In Infogain’s case, every train had a local proxy for the release train engineer, who would co-facilitate the event on the Infogain side. Also in many cases, a development director level person would visit Infogain teams from the client side. That was an incredibly powerful aid to the teams and to the entire program: someone who could share relevant context and provide decision making authority. It is definitely advisable to arrange for such travel for every PSI planning. At some point, when Infogain had to support PSI planning in two different Agile Release Trains, the client representative who visited one train specifically during PSI planning provided a lot of help to the teams on another train by sharing some critical context and by helping the teams get in touch with the specific stakeholders on the client side. Also, after just one such visit and collaborative planning effort, teams normally establish very effective communication channels with the person and his/her remote peers or subordinates on the client side which turns out to be very useful for post factum interaction, even if the interaction is fully remote the next time.

Technical preparation deserves a separate mention. It is required to have at least the following two-way channels to make a distributed PSI planning possible: video, audio and presentations. It is not a trivial task and requires thorough preparation and up-front testing.

Next was the agenda. Having distributed programs plan “together” requires a certain amount of overlap. Teams in India showed real professionalism and dedication. They stayed till 2-3 am in the morning to go through the plan review and other important activities for every PSI planning. The following 3-day agenda was used as a template (see Figure 2):

Figure 2. Distributed PSI Planning Agenda

The distributed PSI planning sessions provided a number of important benefits. First of all, the remote teams had a chance to hear directly from key company stakeholders during the briefings on day 1. This emphasized the fact that everyone cares what the large distributed program will produce during next 10 weeks. When remote teams hear a statement directly from their stakeholders that “we are spending $ X million on postal cost, and now through Electronic distribution system we are trying to manage this cost more effectively”, the teams clearly understand “why are we doing this work”. Second, communication with peer client teams, specific program stakeholders, and domain and technical experts substantially improved. Finally, teams were able to commit to a realistic plan assuming dependencies and risks as well as the alignment with respect to the key program priorities.

The process itself is very dynamic and lively. Pictures below capture a few moments during the planning:

Figure 3. One of the key stakeholders presents business vision to US and India teams at the same time
Figure 4. Infogain part of the program – all teams in attendance


Figure 5. A team during first breakout session – discussing backlog items for 4+1 iterations in the PSI
Figure 6. Another agile team on the train, on a call with the client teams to assist in story breakdown and estimation
Figure 7. The hourly Scrum of Scrums shows the progress of PSI planning


Process Transparency

Distributed PSI planning creates high transparency for the process. So, Infogain teams would present PSI objectives formulated in business terms. The planning would be finished only with the client stakeholders approving the plan and sharing their sense of priorities by assigning business value to the PSI objectives that the teams in India would provide. This created a meaningful and powerful communication and alignment mechanism that allowed to remove the formal boundaries between the client and the vendor teams.

After a couple of PSIs teams acquired much more confidence in open communication, sharing their viewpoints and maintaining transparency. Such a close communication helps both Infogain and their client to effectively manage risks and respond to issues in a timely manner.


Outsourcing can be very effective, and companies can leverage talent in different parts of the world. However, clients and vendors typically experience low productivity in the distributed case as a result of problems with a lack of alignment and solid program execution. Infogain fully supported the client initiative of adopting SAFe and created the environment where the teams could effectively plan and execute PSIs in close collaboration with the client stakeholders and peer teams. All three distributed trains left their station and synchronously moved forward towards achieving the client’s business goals.

Leffingwell et al. © 2011-2014 Scaled Agile, Inc.