The Failure of Agile at OOSP

[This post appeared in linkedin (Sept 28,2015)]

Communication is at the core of Agile. Right form of communication leads to discussion, bounded by shared knowledge with common objectives. What is it then about Agile that it fails when in contact with OOSP (Offshore Outsourcing Service Provider)? OOSPs have gone through a sea change of certifications, from ISO to CMMI and presumably many more, but all in one way or another failed. The failure was not in the certification itself (although the issues here are also legion by now); the certification didn’t add a measurable business value that could be monetised. There was no industry bench mark to suggest that your organisation benefited more than any other organisation. What it did provide to organisations, ready to bear the cost of implementation, was a dense document based process for convincing a prospective client of the cheques and balances in place to ensure visibility of the execution. This turned out to be not always true, if it ever was.

Agile was the saviour, the knight in shining armour. Agile would replace the opaqueness of the document based and waterfall like validation cycles by the clarity of visible, iterative learning, continuous delivery, and not forgetting the often quoted fail-fast (and in some cases fail-frequently). Agile would help the OOSPs to realise the (true) value of their human resources and monetise them accordingly, only this time with the acquiescence of the client. But, all this depended on some very fundamental aspects of Agile, particularly since all other aspects of doing business for an OOSP have stayed static. Although, new communication technology was available, the time zone differences would still pose a challenge.


Perhaps the most critical problem was the historical “way we work” mindset embedded deep into the culture of the OOSPs. This “way we work” mindset enjoyed counting and work-orders, after all up until now it was a numbers game, and whomsoever mastered the abacus won out. This mindset was also married to the idea of communication as mostly a message (unit of work, or work order) packet that is dispatched from the sender to the receiver. In this understanding the message is all important it has both a business value (from the senders perspective) and a monetary value. The monetary value is the cost, to the sender, of getting the receiver to execute the message within budget, while also bounded by a fixed time. In this scenario if the cost is fixed and time is allowed to vary then delivery will impact release, and if time is fixed and cost is allowed to vary then budgets are impacted. So the discussion was not about shared knowledge and semantics of the message, but about the monetary value of the message. Since the message was all important the sender blamed any delays on the ineptitude of the receiver. This mindset was as anti-agile as it could get. In fact this version of Agile was so fragile, it was just lip service. Attempts to improve the situation were made, in most cases only half-heartedly, since normal business was continuing in parallel.

One of the attempts to improve the application of agile was to change the message packet flying from sender to receiver. Thus the message format was formalized. Instead of being just a block of (english) text, it was now a tabular structure. Information in each cell of the table was to convey a unique part of the message, thus no cell contents could be confused with the contents of any other cell. Thus the sender attempted to analyze and break down the message into a less ambiguous form. Of course, this was not the first time an attempt to make the message unambiguous was made, but this was now a necessity to improve the working of Agile.

OOSP organisations also attempted changes, one of them was to try and build longterm client relationships. The idea was that even if results of agile development are seen immediately, the true benefits will accrue over time, as the resources mature and become truly a part of the same development story, and are inclusive in building the shared knowledge. This idea of longterm relationship hinged on Agile implementation shifting the importance from the message to the receiver by removing its monetary value and including the receiver in the decision to identify the effort required and thus indirectly the cost. But, in practice this was very difficult as it depended on trust between the sender and the receiver.

Did these attempts improve matter for the OOSP and their clients? The changes in the message format did lead to less issues of interpretation, but it still left everything in the communication model the same. This new message format still didn’t lead to discussion, if anything the changes to the message format meant the sender was able to go into the receiver blame game even quicker. The message format changes camouflaged discussion (to bring the receiver into the same contextual place) by a table.
The attempts by OOSPs didn’t set the industry on a new growth line either. One of the problems was that if the OOSP country had very little product development culture then the OOSP found it very difficult to find all the different resources required to take the product development forward. Unlike the training for a Java programmer, there was no such training that could create some of the roles required to create a collocated team for their clients. Consequently communication problems persisted as the important players of the product development effort were not with the offsite team. Another problem was that clients (particularly in the early stages of product development) saw teams as fluid structures that can be knocked down and re-built quickly. This was a difficult proposition for the OOSP, their take on “long-term relationship” was income stability. The one team-model fits all clients would be anything but dynamic and fluid; the clients product maturity would dictate what type of team model would suit them best.

If one accepts the main reason for outsourcing as being cost reduction then this turnout of events shouldn’t be a surprise, having only coding-to-delivery keeps the cost down even if it means the cost communication errors go up. Hence no matter what attempts are made eventually the system will take the path of least resistance and gyrate towards one where communication is about the importance of the message and not the receiver.

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in agile methodologies, offshore operations, product management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s