DevOps - all about culture change, not tech adoption

Profile picture for user mbanks By Martin Banks June 27, 2018
Summary:
A couple of use cases to illustrate that corporate culture change is the real challenge around DevOps.

time-for-change
The technology side of DevOps is already well known. The tools and techniques required to move applications development from the traditional waterfall model - where applications updates are typically annual, sometimes tri-annual, and where quarterly updates are considered indecently hasty – to an environment where updates are made in their hundreds per week (and sometimes per day) are well-charted and new ones continue to emerge.

But there is another side to DevOps. This is the human side, which ranges from individual feelings and motivations, through to one of the major potential stumbling blocks for any change in any business – corporate culture. It was good to see, therefore, that this important issue made a main-stage appearance at the DevOps Enterprise Summit in London this week.

A couple of keynote presentations addressed this issue, one tangentially, and the other, more fulsomely, tackled it head on with some interesting solutions.

Chris Hill, Software Engineering Director at Jaguar Land Rover, mainly focused on the story of how DevOps has underpinned the development of the Jaguar iPace and in particular its infotainment system.  But en passant he also addressed the business realities that come with DevOps, and with which corporate culture has to become accustomed.

Yes, DevOps means having the ability to modify, update and add software just as soon as it is ready, but it also brings some huge responsibilities, especially if the corporate culture is towards the notion of caution and conservatism, as Hill acknowledged:

We have to be aware that the delivery of software overnight means the risk of breaking one million vehicles overnight.

DevOps – the thing that goes bump in the night

Addressing such fears, and all the other aspects that make up corporate culture was then undertaken at some length by Aimee Bechtle, Senior Manager of Next Generation Infrastructure Services and John Schmidt, Director Product Management, both at Capital One, the increasingly international commercial and retail banking operation.

Between them they made an interesting double-act: Bechtle as the techie DevOps advocate and Schmidt as the business manager interested in development of financial products that enhance and extend the company’s range and market penetration. She readily acknowledged that her start point was a complete lack of interest in anyone not in her direct line of sight in pushing the bleeding edge of technology.

But after joining the company in 2015 she had come to realise that for DevOps to work she really had to build communications channels with the business management side, which is how she came to meet Schmidt.

He was at the point of acknowledging that, while he felt the applications development team at his disposal was one of the best around, the fact that it took three weeks – at best – to get a single line of code out into production was simply not fast enough anymore.

Between they decided that the status quo of two separate teams – one working on DevOps, one of a mix of legacy applications developers and business managers – should start working together. And to overcome the natural suspicions and cultural differences between the groups the idea of a Dojo should be adopted.

This is an approach pioneered by the US supermarket chain Target, which brings together all parties in an educational/experimental learning environment where the whole group is given a collective project to develop which has to achieve the business goals while getting the development speed and flexibility offered by DevOps.

Both individually and as teams they both learn from each other and from the process of understanding where `the other’ is coming from – and why. Schmidt said:

These things are difficult to plan in any detail and the process is always going to be messy. It is an emotional journey as it is a technical or business one.

He pointed out that there is a real need to find and address the pain points so that they can end up as what he called “happy campers”:

You must not just concentrate on the good bits: you must address the fears and pains. You have to address the simple law of applications development: that speed, minus safety, will always equal a crash.

The route through that problem proved to be the development of re-usable building blocks with which much of any application can be constructed. These also allow for faster and easier adaption and modification when updates or new developments have to be included. It also reduces or eliminates what he referred to as the ‘oops tax’, the situation where an application starts out working well but circumstances eventually combine to cause it to crash because it was not well-written – or written with insufficient foresight.

The Dojo lesson

The Dojo idea worked, and worked well enough for the pair to try it again, this time with the Dev/Ops team and the company’s data scientists. In both cases, it was based on scoping out a challenge, a project that would run for 10 weeks in what he called a psychologically safe place where both teams can learn to work together.

The lesson here is that there are ways of creating the culture change and getting appropriate but currently disparate groups working together, and the justification for try is the observation made by Schmidt:

If the rate at which a company is shipping code is slower that the pace of change out there in the world that company will not make it to the river bank. It will go over the waterfall. So getting the culture change is, ultimately, far more important than the technology.

My take

To me, Schmidt’s final observation says all that needs to be said. And the lessons discussed here in ways of getting different groups to mix are worth any company considering and putting in to practice.