Outsourcing Agile without Losing Agile

Experience Report Abstract

Internalizing Agile values and practices is not an easy task, many teams invest years before they can think and act as a single cohesive unit. Many others didn’t reach this point and are disbanded or deliver results below expectation. Regardless of how far in the Agile path teams are, many organizations decide to outsource^[1] part of their operations and sometimes complete projects to outsourcing providers such as companies in India and more recently to Latin America. Outsourcing comes in different flavors, staff augmentation for example is one approach commonly used to add extra muscle to a team’s development effort. Other organizations opt to outsource their quality assurance work with the view that this is a safer option. Regardless of what you decide to outsource and to where, at the end of the day you’re introducing disruption in your in-house Agile team.

This experience report seeks to contribute to your toolkit with practical advice from somebody who’s been on the other side of the phone in an outsourced Agile team. You may have heard that culture is a big challenge in a distributed team, if so this experience report has some pieces of advice that can help you overcome this limitation. More importantly, this experience report will contribute with some insights about what to expect when you plan to outsource  work and how to take two not-so-Agile teams to a level of cultural alignment that enable them to work effectively.

 

Introduction

This experience report is not about a particular project or organization, it is a collection of experiences and observations gathered by the author from working in two organizations that provided outsourcing services for software companies based in the US. The involvement in these organizations allowed the author  to be part (performing roles ranging from Scrum Master to Project Manager and Agile Coach) of more than ten teams than served more than half a dozen of clients over the last five years. All these teams and clients were different in many aspects, but all had two things in common: they were trying to outsource part of their work and they claimed to use Agile. Outsourcing operations is a task challenging enough, but how you can outsource something more intangible like Agile? This experience report provides some insight about what worked and what did not and some advice that can help facilitate future endeavours.

Culture First

You might have read and hear about culture and how important it is to understand it when you work with people from other countries. While this is tremendously important it is not the only consideration. Of greater importance is understanding the organizational culture of your future (or current) outsourcing provider.

As workers, we all perform in a small silo in which a particular subset of culture coexists within a much broader expression of local culture. Outsourcing providers put effort to create this internal culture and make it look more like the culture of client’s home countries, but here is the first problem, outsourcing providers are not matching the culture of their client’s organizations ^[2].

Matching culture is not just a matter of speaking the same language (English in this case) it must first be determined what type of culture the client has and then see if there could be some alignment with the provider’s own culture. The Schneider Model provides good foundation for assessing the type of culture of both organizations; the four quadrants in this model are ^[3]:

Collaboration	Control
Cultivation	Competence

A simplified definition of this model would state that organizations in the Control Culture are highly hierarchical and have well defined structures of power and formal procedures in place. Typically these organizations believe in chain of command and concentrate decision power (and creativity) in a few individuals.

The Collaboration Culture is different from control in the regard that its focus is on people and teams. Success for organizations with this culture depends on teams and how well they interact.

The Competence Culture corresponds to organizations that value expertise and knowledge first. These organizations try to achieve excellence by introducing new products and concepts; their focus is in being the best but not necessarily believing in teams as the key for success. Motivation for people in these organizations comes from the feeling of building something great, different and/or technologically challenging ^[4].

Lastly the Cultivation Culture is typical in organizations that believe in that teams should be grown, not only staffed. Cultivation has to do with empowering people and allowing them to experiment with different approaches; a systems of informal believes to achieve goals is also present ^[5].

Outsourcing for economic reasons is perhaps the most common reason for taking work outside your country. The author has not yet worked for a client for whom the motivation for outsourcing was to be more Agile, motivation is always related to getting more people at a lower rate. While this motivation is more than valid usually what comes next is that clients decide where and with who to outsource based on an economic decision but not on organizational cultural alignment.

Critical advice, organizations that are ready to outsource should first understand the type of culture that they have in order to look for outsourcer matching.

Outsourcing in the Control Culture

The majority of the failures seen are related to this mismatching, for instance one client was so into the control culture that its organization had a procedure for almost everything. A ticket-based tool was available and developers worked only on something that has a ticket assigned to it, conversely bug reporting also produced tickets that were prioritized and assigned. Metrics were collected from these tickets to measure productivity and release progress.

When the service provider staffed an Agile team for this client there was a mismatching because the providers team was more into the collaboration culture. It took time and resources to bring this team to understand the control mindset that was required from the client so they could work more effectively.

Standup meetings were more like reporting meetings and further managers’ meetings were held to review metrics. Reports full of data and dashboards were also produced.  Interestedly enough this client believed in Agile and followed some of the principles such as maintaining pace, using frequent delivery and prioritization based on customer benefit. However, the client culture was in the Control Culture and remained there when it outsourced part of its operations to a provider.

Another symptom of the Control Culture is the excessive desire to work on up front requirements that can be derived into a detailed plan. For the provider this translated into user stories bigger than sticky notes and with much more planning detail as can be seen in this example spread sheet:

There is nothing wrong in putting detail into user stories, and it was actually good to keep all this information updated. The problem with the Control Culture is that any changes required a lot of burocracy to be approved and eventually impacted team’s velocity. Further, the overhead of following a heavy change management process prevented the team of taking fully adventage of the Agile Principle: “Simplicity--the art of maximizing the amount of work not done--is essential”.

Maximizing resource utilization is another highly desirable goal in the Control Culture. In this case the clients management team were constantly challenging and monitoring office attendance and reported hours. Reports like these were generated:

Of course,  these reported hours did not necessarily correlate with productivity or creativity or even motivation, but from the Control Culture perspective there was value in seeing everybody punching hours constantly and at an steadily pace.

Typical with this culture is having the Scrum Master and Product Owner performed by staff on the client’s side, part of this is because both roles are attached to management positions inside the client’s hierarchy. Large number of team members is another characteristic of this Control Culture, and this is because of the upper management belief that project managers can and should effectively manage large teams.

This project was successful to a degree but it required cultural adjustment that consumed resources. The provider’s team didn’t develop or perform to all of its potential, at least not from the Agile perspective.

Outsourcing in the Competence Culture

One client had a visionary idea for a new product that would use the latest and greatest technology and be delivered in less than six months. Time to market was critical and there was a good injection of venture capital. The client decided to seriously invest in recruiting talent in the US; hiring experienced developers in different cities. Since this was a project based engagement no relocation package was provided and work from home was the standard. The outsource provider role was to staff a team of experienced quality assurance engineers.

The client’s approach to tackling a challenging project was by throwing talented resources and a highly experience and decorated manager. All team members had experience with Agile from other projects/organizations.

Again most standard Agile practices were used. For example there was a daily call in which everybody talked about what they were doing. As this was a very distributed team these calls usually took more than 30 minutes for the 10 team members. However other meetings were then introduced to coordinate more and more activity since it became evident that developers were creating code that had already written.

Integration problems were then solved by setting up a continuous integration server and introducing some procedures for preventing duplicate check-ins. However, due to the culture of competence, collaboration among developers had to be constantly promoted. Perception in the team was that everybody should prove to be the best in their field, this complicated QAs work since reported issues were extensively debated before being accepted.

The outsourced QA roles eventually also fell into this competence mode and collaboration was being replaced by trying to prove who could find the most difficult bug or who can find more bugs in a regression pass. Group metrics were not as important for our client as individual metrics, this again contributed to create more competition among team members.

Product features and innovation was promoted but highly debated since every team member wanted to leave his/her mark in the product. The Project Manager/Product Owner was focused on building a stellar product to enhance his reputation, concentrating product decisions into his hands was not symptomatic of a “command and control” mentality but more of a “I have all the knowledge” mentality. No Scrum Master was appointed since this role was not wanted by any team member.

The project ended way beyond the intended schedule and with a cost overrun; however it was a market success. By talking to the team members in the project review it was evident that the project had been very exhausting because of the competition created. Team members didn’t feel that they have been part of a team and the same was true for the client’s team in US. Technically speaking the project produced good portions of code but written by different hands and with some lack of coordination.

Even though one of the Agile Principles says “Continuous attention to technical excellence and good design enhances agility” this is referring to the aim of the whole team for technical excellence, not only for individuals and their private quest for excellence in detriment of team collaboration.

The conclusion from this experience is that outsourcing in the Competence Culture is possible but it doesn’t necessarily follow the Agile mind-set, values and practices. Even if you develop the project internally the competition created among team members is not good for helping the team to work as a single cohesive unit. Depending on individual talents can be more risky and may restrict creativity or the team’s ability to collaborate and explore different approaches with innovative ideas.

Outsourcing in the Collaboration Culture

One of a most successful projects experienced was for a client that asked the outsource provider to staff a team for him that was not full of technical experts but a group of individuals that get along together. A team was formed with team members that had been working together for years in other accounts. This team had a good mix of experience but at the same time it was very diverse in ages, gender and skills.

From the very start of the project the client was interested in knowing all the seven team members in his outsourced team. He visited on several occasions and each time he contributed to build team rapport. They had many dinners and team building activities, the result was that the client flew back home the team were constantly asked him when he was coming back. Some of our team members visited him and again the same experience, good team building activities and good team collaboration.

This process did of course consume additional resources (time and money) but it greatly contributed to foster communication and cohesion among team members. A result of this effort was that the code quality was twice that of  the previous release created by another outsourcing provider in another country; the project was also delivered three times faster. Statements made by the client.

Furthermore, the team was able to keep its pace during the whole project fulfilling this Agile Principle: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. The following chart shows a typical productivity report generated for this project:

During the project review the client was asked why he hadn’t tried a similar approach to build the same type of working relationship with this former outsourced team. His response was that he tried but the culture of that outsourcing provider was more like in the Control Culture with little interest in team formation and satisfaction and more oriented to process and supervision.

This project achieved the three levels of success: technical, business and personal. Both the outsourced team and the client shared a common culture that allowed both parties to develop to their full potentials. Also to support this statement is the fact that one of Agile cornerstones is teamwork and teamwork needs the right conditions to flourish, conditions that in time are enabled by having the right team mind-set. Furthermore, this experience was evidence that the Agile Principle “The best architectures, requirements, and designs emerge from self-organizing teams” can be achieved when a team is provided with the right supporting culture to let it self-organize.