Pairing an Agile Organization with an Offshore Waterfall Organization
Can it work?
22 July 2015
It's not uncommon to outsource software development to an offshore company. Indeed, there are many variants: simple resource augmentation, entire product responsibility, or a blend of the two. Without adding to the long-running debate on the merits of outsourcing (chances are that the decision to use outsourcing isn't something you can influence right now), I raise the topic of the challenges Agile companies face when working with non-Agile partners, and I outline the path we have taken to overcome these challenges.
We first engaged our outsourcing partner five years ago. We chose a team from a selection of potential vendors that would best fit with our organization. Our organization at that time was diligently following the Waterfall pattern of software development, and it was natural that we would choose a partner that demonstrated not only technical excellence but proficiency in this area too. Teams working for both onshore and offshore vendors worked in strict process silos, safe in their sandboxed areas of responsibility. We spent a number of years working in this pattern and delivered a number of semi-successful projects.
Success and failure in equal measure
We challenged ourselves on how we worked and on how we delivered. We started to learn and gradually change. We failed, we picked ourselves up, we learned, and we improved. We took this cycle and repeated it (we are still repeating this cycle now), all the while keeping the working agreements with our outsourcing partner. Our journey from Waterfall to Scrum was purely on projects with teams that were made up of onshore staff.
We made massive improvements in our organization, but the interface with our outsourcing partner was becoming fragile. On one side of the bridge we had enthusiastic, empowered, multifunctional Scrum teams delivering working software every two weeks (hiccups aside). On the other side we had a team governed by slow-starting projects, heavy up-front requirements, heavier change-management processes, and estimates to complete.
We found that running two different frameworks together was problematic in many ways. The difference limited the team's innovation and creativity -- something we had benefited from greatly in the adoption of Scrum. We also found that it created a hierarchical divide between the teams: It implied a lesser value on the outsourcing teams and created an underlying perceived lack of trust between the two.
We decided to remove the bridge and close that gap.
Get to know your outsourcing team
If you take the time to get to know your outsourcing team, you will find that they are an incredibly talented bunch of people. In our case, they still managed to produce working software within the acceptable Waterfall tolerances, which, under the conditions and constraints outlined above, is pretty incredible. A simple improvement in communications was made by assembling quick headshot photographs and three-line bios from members on both sides. It sparked a number of nonwork-related conversations, helped create and strengthen the bonds between people, and helped reduce that vast physical and emotional distance between them. Getting to know the outsourcing team helped foster genuine care about each other -- and about the product itself.
Bring them closer
Integrate each member fully into Scrum. Bring the team over for training, or send people out to run an Agile course. Take them through the mechanics, and start to integrate them with a single story. Start small and build on it. However, more important than the mechanics, make sure you spend time and effort on the core values and principles. We found that our outsourcing team members had particular difficultly moving from the previous command-and-control model to Scrum and the freedom it provides (and the responsibility it demands). The Agile Manifesto can be at odds with how they've worked, so it may take time before it's fully embraced.
Pay particular attention during the retrospectives to how people are feeling. How do the onshore engineers in the company feel about working on par with contractors? Do the outsourced team members feel part of the team? Do they feel empowered to achieve their full potential? Do they feel like they have a safety net that removes fear and constraints and allows them to flourish?
From a scaling point of view, you can choose to either have completely offshore teams with their own dedicated ScrumMasters and shared product owners, or mix it up across geographic locations. Each has its own benefits and drawbacks. And an approach that might work for one company or team may not work for another.
Isolating the teams that follow a geographical pattern removes some of the logistical problems and creates a tighter, more collaborative colocated team. However, based on experience, the makeup of an outsourced team changes more frequently than that of an onshore one. Therefore, splitting the teams globally may provide a greater degree of stability.
Don't expect it to be easy. Working with distributed Scrum teams over multiple time zones is difficult. Add to that a mix of permanent/nonpermanent employees, and the complexity increases. Stay with it and persevere, and it will improve. The results will be clearly evident.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4 (5 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.