Will DevOps Kill the Offshore Model?
During the 1980s and 90s, quality management was a popular way to control the cost of software development. Total Quality Management, Six Sigma, ISO9001 and Lean took slightly different approaches to a common goal. But regardless of the methodology, quality management rightfully gained a reputation for being bureaucratic and counter-productive. It failed to explain that quality and cost should be outcomes of a well-oiled machine, rather than two opposing forces, forever requiring compromise, forever creating delays and inefficiencies.
Fast-forward to today, and digital channels have brought opportunities for agility. Established businesses have to invest to keep up with their newer, more disruptive rivals. In turn, customers come to expect the kind of convenience and speed that old methodologies struggle to deliver.
As the internet started to make the world smaller, and outsourcing was seen as a way to bridge the gap. Now, businesses could take advantage of overseas resource to cut spend while ensuring quality.
But is the offshore model really a solution?
The Trouble With Offshore
At first glance, outsourcing development to offshore companies suits a traditional development process. Once the early analysis and design is complete, documentation can be sent to distant developers to support coding and local testing. Once the code is returned, stakeholders can see quality – or some perception of it.
But Agile development turns all of this on its head, because it seeks greater collaboration between teams. Agile is built on the idea that we need shorter development cycles, called sprints. By breaking a project up into bite-size chunks, everyone gets more frequent visibility and feedback. Arguably, this results in a higher quality result through a more realistic, evolutionary cycle of software, with the opportunity to polish and fine-tune as an integral part of the process.
The skills, commitment, knowledge or enthusiasm of offshore personnel are not in question. But geographical distance is a hindrance to agile working, and close collaboration is extremely challenging when people are working across time-zones. Any gap that leads to an instruction being issued, rather than a conversation taking place, is a ‘hand-off’. And that’s what we want to avoid.
The DevOps culture does the exact opposite of what we expect it to do. It demonstrates that low cost can result in higher quality, when compared to more expensive processes.
The secret to efficiency is to maintain high quality all of the time, rather than retro-fitting quality at the end. Other industries have known this for some time, but IT has taken some time to catch up.
This is why we need eradication of ‘hand-offs’. A hand-off is a point where one person notifies another that it’s time to start work, usually when a key milestone is complete. This way of working contradicts the principles of agile development, and slowly allows delays to build up.
Why? Any person waiting for the go-ahead from someone else is inefficient by definition. Additionally, it’s more likely that work needs adjustment so that it meets the pre-defined, precise requirements for hand-off. Any re-work that has to be done represents an unnecessary inefficiency, and teams are creating these inefficiencies as a result of handing off an item of work to another.
So when we talk about collaboration in DevOps, we aren’t talking about cutting down on notifications. We aren’t going to reduce hand-offs to one email, rather than 10. We are collaborating through the entire development cycle – not passing work back and forth in a relay.
Two Worlds Collide
If you need a working example of DevOps in action, just look at Salmon.
After six short months, our teams are seeing weeks turning into days; days and hours into minutes.
In fact, Salmon is seeing such significant savings, it’s having to draw up new units of measurement.
Yes, there’s still a place for the offshore model, but it’s time for your business to re-evaluate the practice of hand-offs, and the impact of geographical separation. DevOps doesn’t mark the end of offshore development, and it’s not incompatible with agile practices by definition. But if you’re purely evaluating cost using a daily rate, changes in offshore pricing may not support your reasoning forever.
In development, quality is paramount. Maintaining a consistent focus on quality is advantageous in practically every respect. And despite higher quality, DevOps will usually bring costs tumbling through the floor.
When deadlines are tight, and budgets are scant, don’t allow quality to be sacrificed. Agile working with DevOps makes tight deadlines and tight budgets achievable, and Salmon has seen the results first hand.