Towards offshoring 3.0 — Software innovation offshoring
Introduction
Either the corporates have learned to turn a deaf ear to the decades old argument, ‘offshoring doesn’t work’, or they have found a workable model to produce the expected results of software offshoring; either way, today corporations in developed economies have accepted the norm of offshoring their software projects. By 2016, the statistics show that the global IT outsourcing industry was worth $76.9 billion USD. It’s widely known that corporates expect to save an average of 15% — 20% costs by offshoring either software needs. However, there is very little literature available to determine exactly how much cost savings is achieved through such software offshoring engagements.
Since the inception of the offshoring industry, almost three decades ago, several contextual factors — availability of high speed Internet, decreasing cost of telecommunications, and also globalisation and standardisation of computer education — have all positively impacted its viability.
In the global industry itself, offshoring needs, concepts, models, key drives and value definitions have all evolved and changed over the three decades. Likewise, the offshore development companies (large-scale businesses and medium-scale businesses alike) have been challenged to change their processes, business models, concepts, principles and even organisation cultures to align with industry trends and new demands in the developed economies.
When analysing the major stages of evolution in the software offshoring industry, we can look at it in 3 key phases.
Offshoring 1.0 — Specs offshoring. Key driver to win: Rigid process excellence
Back in the days when the practice of software offshoring started to pick up in various corporates globally, the main success criteria for the engagement were how well the specs were defined by the onshore company, and how well they were followed by the offshore development company. Large systems were designed and detailed in bundles of specifications with screen mockups and even defined databases, and each data field was defined to the atomic level. This was a readymade package prepared by the architects, BAs and software developers in developed countries for outsource to a company in India (or any other offshoring destination) who would develop and ship it back to the sourcing company. Most these projects were pre-estimated and meant to be delivered within fixed-price contracts. These engagements happened within rigid contracts, including penalties for low quality and time drops. Most these projects followed very rigid waterfall processes to address fixed specifications, defined extremely rigid change management processes, and clearly tracked delivery deadlines. These processes, introduced for software project execution and management, were imported from the construction industry, where they were used heavily for construction projects.
Furthermore, these processes evolved alongside other standards such as CMMI, ISO as well as PMI and Prince2 methods. Project managers at the offshore end often tracked key indicators such as volume of code produced per day and bug count per each individual developer. The trust between outsourcer and outsourcee was totally built upon references and contractual trust. With time, most onsite stakeholders also developed trust in one or two key project management individuals on the offshore side, as a result of frequent communication and delivery track record. Most of the time, the onshore-offshore engagement was built on single points of contact or a small number of managerial contacts from each side. Onshore-offshore ‘team trust’ was not quite visibly seen in this model and often onshore stakeholders were satisfied with a single point of contact from offshore vendor companies, so as to reduce the complexity and the cost of communication.
The biggest pain point of these projects was the lack of transparency in software production. The offshore teams saw only the output of the design process (in the form of confirmed specifications) and onshore customer saw the final product of the system only when it was completed as per the specifications. Often these projects failed to achieve “fit to purpose” and most projects had to go through very tiring post-delivery phases to fix the systems to make them “fit enough” to use. Budgetary and timeline overruns were quite typical in such situations. In most cases, the contract clauses were strictly enforced, and both offshore development companies and onshore customers had to bear the cost and pain of deviations after lengthy and time-consuming arguments.
However, we cannot argue that such contract- and specifications-focused approaches never worked in the industry. Major systems in banking and finance, Telcos and many other industries have developed robust systems using the offshoring 1.0 model, irrespective of the huge hidden costs, overruns and painful processes of offshore development with many additional complexities.
Offshoring 2.0 — Agility in offshoring. Key driver to win: Lightweight process, high onshore-offshore collaboration
As it matured, the software industry came to realise that the heavy methods and processes used in construction industry are not the ideal way to deliver software projects. Industry professionals understood that building software systems should be handled in a totally different way to building a bridge or a house. Rapidly changing business requirements and time to production, as well as the need for frequent market validations of software products, pushed the industry professionals to look to various other methods from lean manufacturing systems instead of copying processes from the traditional construction industry.
The software industry began to experiment with lean and agile methods such as XP, KANBAN, Crystal and DSDM to find better ways of developing software projects over heavy processes and methods. In the early 90’s, Jeff Sutherland and Ken Schwaber conceived the Scrum process, which provided software developers with a lightweight, easily adoptable process for software project deliveries. The Manifesto for Agile Software Development, created by leading software developers in February 2001, further boosted the growing trend towards the use of such lightweight and highly collaborative models specialised for software development. Some of these processes were highly integrated with technical practices such as continuous integration, clean code practices, test automation, continuous deployment, etc.
With rising trends of use of agile engineering practices and increasing recognition of team collaboration, traditional offshore players now faced a new challenge. Mismatched onshore — offshore development and management models created chaos in many offshore development projects. The traditional company hierarchies and cultures of offshore vendors had to confront the fundamental challenge of adapting to the new lightweight ways of working. With offshoring 1.0, many offshore factories had been used to defining and excelling in one protocol with which to manage and engineer every project, but with offshore 2.0 this was never a good idea. Teams had to show high adaptability and ability to collaborate flexibly with their markets and onshore product teams. They had to be able to align with the vision for an individual products and the evolving needs of each product development process, instead following their own company processes and focusing on contractual terms.
Once I went through some interviews with some of the candidates from such companies. It was a pretty interesting interview. When I asked one candidate, “So you practice scrum in your project?”, he said, “Yes.” Then he thought for a while and added, “But I don’t like scrum; it makes me work longer days now.” I was pretty curious, and I dug into the details behind his thoughts. It sounded to me like the developer in this large offshore company works with his onshore customer in more agile way by practicing scrum during his 8 hour working day, but he is also asked to comply with his own organisation’s traditional process of documentation and reporting, so once he completes his 8 hour scrum day he works long hours to fulfil the separate requirements of his own company’s process, which don’t tally with onshore customers agile model.
With requests and pressure coming from some of their onshore customers, and proactive vendors responding to the changes by themselves as early adopters, offshore companies began to get their act-together to deal with the new situation. There was definitely a need to enable highly skilled developer teams, instead of one or two star developers heading many ordinary developer teams. More cross functional teams became the norm. QA engineers were integrated into teams instead of comprising separate QA departments within the organisations. The new situation challenged the traditional PMOs and delivery units of such organisations with respect to their planning, progress monitoring, risk management activities and overall KPIs. During this early-adoption time period, many software enthusiasts wrote articles and books and shared knowledge about how they experienced practicing agile offshore-onshore development project; for example, Martin Fowler’s 2006 article about how ThoughtWorks experienced agile development in the offshore context, and also Jeff Sutherland’s IEEE paperfrom 2007 on Distributed scrum. Agile project management with distributed teams gave much hope that agility in offshoring is not a myth.
Another key aspect that created more headaches to businesses transforming from offshore 1.0 to 2.0 was offshore development contracts. During offshore 1.0, the contracts were made based on fixed upfront requirements and estimations with controlled changed management processes. When transforming to offshore 2.0 most these contracts were not flexible enough to work in an agile manner. Continuous planning, frequent feedback cycles, ongoing changes to the backlog, continuous releases and many other agile practices require flexible monthly pay contracts after seeing what’s being developed for the specific time period. In response, some legal officers developed specialised knowledge of such agile contracts in order to solve key challenges in legal aspects of such engagements.
More recently, the introduction of scaling methods such as SAFe and Less for large scale agile projects helped companies to think agile in larger project contexts.
After more than 10 years of refining agile practices in the offshore engagements, some unresolved challenges still remain. However as a whole, agile transformation has done much good in the onshore-offshore development context, including;
- Less stress on culture differences; a common, respect-based agile culture displaces the division between onshore company and offshore company cultures.
- More visibility of and exposure to offshore development team members, leading to rapid learning.
- Increased exposure of offshore developers to full-stack development work, instead of code cutting- or testing-only work.
- More focus on development and coding practices.
- Equal respect for the work time and skills on both sides, due to the high level of transparency.
- High levels of onshore-offshore collaboration have tremendously reduced “us against them” problem.
Read “Towards offshoring 3.0 — Software innovation offshoring” on a larger screen, or in the Medium app!
