Introduction — Towards offshoring 3.0 — Software innovation offshoring
Offshoring 1.0 — Specs offshoring. Key drive to win: Rigid process excellence

Offshoring 2.0 — Agility in offshoring. Key drive 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 paper from 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.

Offshoring 3.0 — Innovation offshoring: Key drive to win: Business value addition via technology innovation