I've collected experiences and observations from serving in two organizations that provide outsourcing services for software companies based in the U.S. My involvement in these organizations has allowed me to be part of more than ten teams that have served more than half a dozen clients over the last five years (my roles ranged from ScrumMaster to project manager to Agile coach). These teams and clients differed in many aspects, but all had two things in common: They were trying to outsource part of their work, and they claimed to be Agile. Outsourcing operations is a challenging enough task, but how you can outsource something as intangible as Agile?
We've all read and heard about culture and how important is to understand it when you work with people from other countries. While this is indeed tremendously important, it's not the only consideration. Even more important is the organizational culture of your outsourcing provider.
As workers, we all perform daily in a small silo in which a particular work-culture subset exists within the much broader expression of local culture. Outsourcing providers make a good attempt to create an internal culture that looks like the culture of the client's home country, but here's the first problem: Outsourcing providers often aren't really matching the culture of their client's organizations.
Matching culture isn't just a matter of speaking the same language — English, in this case — it's related more to first determining what type of work culture the client has and seeing if there can be some alignment with the provider's culture. The Schneider model provides a good foundation for diagnosing the type of culture of both organizations. The four quadrants in this model are Collaboration, Control, Cultivation, and Competence.
A simplified definition of this model would state that organizations in the Control culture are highly hierarchical, with well-defined structures of power and formal procedures in place. The Collaboration culture is different in that its focus is on people and teams. The Competence culture corresponds to organizations that value expertise and knowledge first. And the Cultivation culture is typical of organizations that believe in that teams should be grown, not simply staffed.
Outsourcing in the Control culture
The majority of the failures I've seen are related to mismatches of these types of work cultures. For instance, one of our clients was so into the Control culture that the organization had a procedure for almost everything. A ticket-based tool was available and developers worked only on whatever had 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 we, as service providers, staffed a team for this client, there was a mismatch because our team was from a more collaborative culture. It took time and resources to bring our team to the control mind-set that was required from the client. Stand-up meetings were more like reporting meetings, and we had manager's meetings to go over metrics. Reports full of data and dashboards were also produced. Interestingly enough, this client believes in Scrum and uses some of its practices, such as timeboxing and prioritization. However, the client was firmly within the Control culture and remained there when outsourcing part of its operations to us.
Typical of this culture was the fact that the ScrumMaster and product owner were on the client's side, partly because both roles were attached to management positions inside the client's hierarchy. Large numbers of team members are also characteristic of this culture, because of upper management's belief that project managers can and should effectively manage large teams.
Outsourcing in the Competence culture
Another client had a visionary idea of a new product that would use top-notch technology and had to be delivered in less than six months. Time to market was key, and there was a good injection of venture capital. The client decided to seriously invest in recruiting talent in the U.S., 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. As an outsource provider, we staffed a team of experienced quality-assurance engineers.
Again, the client used some Scrum practices; we had a daily call during which everybody discussed what they were doing. Since we had a widely distributed team, these calls usually took more than 30 minutes for ten team members. Other meetings were introduced to coordinate further, since each developer was trying to work pieces of code that, often, somebody else had already written.
Our QA team eventually fell into this competence mode. Collaboration was replaced by trying to prove who could find the most difficult bug or find more bugs in a regression pass. Group metrics weren't as important for our client as individual metrics, and this also contributed to creating competition among team members. Product features and innovation were promoted but highly debated, since every team member wanted to leave his or her mark on the product. The product owner was focused on building a stellar product to enhance his reputation (concentrating product decisions within his hands was not symptomatic of a command-and-control mentality as much as of a I-have-all-the-knowledge mentality). No ScrumMaster was appointed, since this role was not desired by any team member. However, some Scrum practices, such as timeboxing and short releases, were used.
The project was completed far beyond the projected schedule and with a cost overrun; however, it was a market success. By talking to the team members in the postmortem, it was evident that the project had been exhausting because of the competition involved. Our team members didn't feel they'd been part of a team, and the same was true for the client's team in U.S. Technically speaking, the project produced good portions of code, but they were written by different hands and there was some lack of coordination.
Outsourcing in the Collaboration culture
One of the most successful projects in which I participated was for a client who asked us for team not of technical experts but of individuals who get along together. As outsourcing providers, we staffed a team with members who had been working together for years on other accounts. This team had a good mix of experience, but it was also diverse in terms of age, gender, and skills.
From the start of the project, the client was interested in knowing all seven team members within his outsourced team. He visited us on several occasions, and each time he contributed to building team rapport through dinners and team-building activities. The result was that whenever our client flew back home, we immediately asked him when he was coming back. Some of our team members visited him, and again the experience of good team-building activities and good team collaboration was the norm.
Of course, this process consumed resources. But it also contributed greatly to fostering communication and cohesion among team members. A result of this effort was that the code produced was twice as good as the code of the previous release (created by another outsourcing provider in another country); the project was also delivered three times faster.
Outsourcing in the Cultivation culture
One of the few projects — if not the only — in which I've seen the Cultivation culture at work was a project in which one of our clients requested a junior team with the intention of training it and eventually having it develop the next generation of products. This client's system of belief was strongly attached to personal development and growing career paths.
In its first year, this team didn't produce much in terms of product releases; they work on hot fixes and, in the process, studied the architecture of the client's product. Also during the first year the team had a mentor — one of the client's senior staff engineers — who coached them in technical aspects. Initially there was a ScrumMaster from the client's staff, but after some months this role was transitioned to someone within the outsourced team.
By the second year, the client decided to start integrating this team into a larger team that developed the next version of the product. Each junior engineer in the outsourced team collaborated with a more senior partner in U.S., and the results from this collaboration were exciting. The combined team was able to pull a release that was far more stable and of higher quality than the previous release. The retrospective meetings indicated that the "fresh air" of the junior engineers contributed to the team's success. More than that, however, the common vision of a great product was the true enabler.
In its third year this team was encouraged further to think outside the box, and this independent thinking provided fantastic results because a couple of junior engineers came up with a revolutionary solution for a performance problem that had been dragging back the product over many releases. The solution was implemented, and that release was the most successful in the history of the product.
The Cultivation culture is perhaps the most costly from a simplified perspective, since you need to invest in growing a team that, frankly, may not produce exciting results at the beginning. However, this particular client already had the Cultivation culture well embedded in its workforce. This is how they'd grown their own team, so for this client it was logical to extend its culture to the outsourced team. Another interesting aspect of the client's team was that its members believed — and I mean truly believed — that they could contribute to the betterment of society by producing great projects.
Doing it right
If you're thinking about outsourcing some work, you should first think that what you're outsourcing is work, and maybe processes — but may well not be Agile. Outsourced teams have their own sets of values that, for contractual reasons, they try to match to their clients' values. This accommodation of cultures is what I believe is the key factor in the success or failure of an outsourced project. Some recommendations that I can provide are as follows:
- Before even thinking of outsourcing, do an analysis of your own organization and try to determine the type of culture existing within the project/unit you plan to outsource.
- This analysis will also provide some insights about how your current organizational culture matches with Agile principles and values. Note that there's not one culture that's better than another; all the cultures described in this article are exemplified by successful organizations. Some cultures, however, are better aligned with Agile. This is especially true for the collaboration and cultivation cultures.
- If your analysis concludes that you have X or Y culture, then your next step is to look for an X or Y culture within your outsourcing provider. For instance, if yours is a Collaboration culture, look for a provider that considers team members and teamwork a vital part of the organization itself.
- Mismatches are the caveat here; just imagine if you have a Collaboration culture and your provider has a Control culture. You'll be surprised by how much formality and process orientation your outsourced team is used to working with. If you, on the other hand, are in the Control culture, an outsourcing team might be the perfect vehicle for starting to explore and experiment with Collaboration or Cultivation cultures. Experiments outside your organization have the advantage of being safer and cheaper.