Facebook, Amazon and Google, the darlings of Silicon Valley use DevOps – a concept aimed at improving interaction between app developers and IT operations staff – to continuously deliver software.
It’s true, DevOps does enable organisations to release code on a frequent basis while maintaining stability and security.
So if the concept helps some of the world’s largest and most successful IT companies improve software productivity, there’s no reason why it can’t help you do the same.
I will boldly claim that if you use DevOps, you’ll be able to deliver software two to three times faster than using a waterfall approach.
But before you get dazzled with such lofty goals and while speeding up software delivery is important, it’s not the only benefit of moving to a more agile delivery model. In fact, it runs much deeper than that.
This week, I met with Gary Gruver, a DevOps guru who is releasing a book titled, “A Practical Approach to Large Scale Agile Development.”
When he was VP, operations, engineering and quality at US retailer, Macy’s, Gruver convinced the company to increase its innovation budget from 5 per cent of base to 40 per cent in three years.
This increase was achieved from better use of the company’s resources and assets not simply by investing more money in innovation. As Gruver explained, when you have to write off a few million dollars worth of test automation scripts, it is not a great experience.
Born from necessity
Now, Gruver should be viewed as a hero, but instead he just wanted not to be “the bottleneck.”
This is the genesis of how DevOps was introduced into Macy’s – the retailer that had 2 million lines of code and monthly software builds so moving to an agile approach was just good common sense.
There were no big goals of being fast or saving money. It was all about improving the quality of software delivery.
I asked Gruver about what was the hardest part of making this shift. Was it moving from monthly or weekly release cycles or the shift weekly to daily, and then to hourly?
His advice was not to start with this goal and this should be secondary to a focus on executive support. He went on to explain that the frequency of releases should not be defined by the software development process - but by the organisation's needs.
Doing what the business wants
If your organisation’s needs are already being met, then don’t try to apply DevOps. It is just not necessary. However, if this is an issue then use the common sense approach and ‘automate and eliminate’ as much as possible. It is likely that what you tackle are issues that have been around since the beginning and have never been addressed.
Gruver said to achieve 15 builds per day, he needs the team to redesign, and in some cases, isolate the process. For example, service virtualisation was applied to isolate DevOps from the expensive mainframe – where cycles cost money. Moreover, this is as much about people as it is about technology and process.
Shifting the culture
You have to engage the leaders, use common tools, achieve ‘green builds’, have a clear definition of when something is "done" and adopt flexible planning. Each of these is a challenge and this is a journey that takes a number of years.
By tackling this, you will shift the culture to where continuous delivery is the goal. The only way to achieve this is to increase the frequency and quality of feedback to developers.
Do this now and you just might just achieve he cultural shift you are looking for.
David Gee is the former CIO of CUA where he recently completed a core banking transformation. He has more than 18 years' experience as a CIO, and was also previously director at KPMG Consulting. Connect with David on LinkedIn.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.