Barriers to enterprise adoption of DevOps
Source – computerweekly.com
Until recently, the DevOps movement was considered off-limits to enterprises, with the naysayers struggling to see how these large, complex and unwieldy organisations could ever hope to emulate the agile software development practices loved by smaller, nimbler startups.
Big organisations are just too weighed down by bureaucracy, legacy technologies and waterfall-style software development techniques for DevOps to thrive, and any attempt to challenge the status quo will come to nothing – or so the rhetoric went.
But what the detractors perhaps did not bank on is that many of the characteristics they considered to be at odds with DevOps are actually fuelling an appetite for change within enterprises, as many come to realise that doing things the way they always have done could put them at a competitive disadvantage.
Safeguarding competitiveness
As such, enterprise IT leaders now realise that lengthy and restrictive software development cycles are no longer conducive to safeguarding their competitiveness or their ability to keep pace with the changing demands of their customers.
Accordingly, they have grown frustrated with pushing out software products that their competitors have already bettered or whose functionality is out of step with what their customers want.
They are also looking at how their competitors are drawing on agile concepts to ramp up the pace of software innovation within the walls of their companies, and seeing that – despite what the naysayers think – it is possible for DevOps to take hold within large organisations.
For proof of that, one only needs to look at the roll-call of household enterprise names that are joining the DevOps movement, and see how many of them operate in highly regulated industries that some may traditionally consider ill-suited for agile.
“If those organisations with a reputation for being conservative, even within the IT population, can get on board with this, it just gives us more evidence that it really can be done,” says Gene Kim, co-author of The DevOps Handbook. “If you look at The DevOps Handbook, we have 48 case studies that show how these organisations have applied these principles… and 12 are based on unicorns such as LinkedIn, eBay, Google and Amazon – but the rest of these [success stories] are coming from large, complex organisations that look like the rest of us.”
Computer Weekly has previously written at length about the steps enterprises must take to get their DevOps plans off the ground and scale them up so the entire business can benefit from agile thinking. This often means overcoming common challenges familiar to any organisation pursuing a DevOps agenda, including securing senior management support, fostering a collaborative working environment and creating a sustainable, continuous delivery pipeline.
These are all considered important stages when it comes to scaling and converting small-scale (or departmental) DevOps activities into a company-wide initiative that the whole organisation can get behind and benefit from.
But, as more and more enterprises pin their colours to the DevOps mast, other barriers to company-wide adoption are emerging that are either industry-specific or related to how an organisation operates.
One such area relates to getting senior management to appreciate what continuous delivery and improvement really means in the context of DevOps, and the benefits this approach has on the software products they produce.
As such, it is important for them to understand that continuous delivery means software projects may not be finished, in the traditional sense, by the time of release and subject to ongoing, iterative improvements.
Otherwise, DevOps practitioners could see support for the projects they are working on dry up, warns Nicole Forsgren, CEO of the DevOps Research and Assessment (DORA) consultancy, as senior leaders mistakenly believe a product entering production means it is completely finished.
Part of the problem is that many senior leaders are still wedded to the idea of using software maturity models to gauge how projects are progressing and, in turn, how they should be financed.
“The challenge with maturity models, particularly ones that are codified, is that it can become institutionalised and set in stone in ways that are difficult to break because suddenly you have a target – and once you reach that level, you’re done,” says Forsgren. “Then the organisation might decide you’re done, and the resources that readily flow to support that initiative might disappear too.”
And that way of thinking is out of step with how continuously developed products needed to be supported, says Forsgren. “There’s this strong push [from senior management] to go from level one to level five, for example, but we don’t see the industry working that way,” she adds.
Grassroots movement
In situations where DevOps has begun as a grassroots movement within an enterprise, senior management support is considered essential to encourage its spread to other business units and for DevOps to be accepted as the company’s preferred means of developing new software products.
As the number of success stories about DevOps-adopting enterprises grows, more examples are emerging of companies whose decision to join the continuous delivery cause can now be traced back to senior management leading the way.
An example is German financial services firm Allianz, which credits a visit to Silicon Valley by its senior management team for encouraging DevOps to take hold within each of its business units. On their return, Allianz Deutschland senior leaders instructed each of the organisation’s business units to create an app in a DevOps style within a year, with the crop arriving three months ahead of schedule in August 2016.
Where senior management is the driving force for DevOps adoption in the enterprise, resistance to change can occur lower down the company if the people responsible for delivering the firm’s agile ambitions are not quite bought into the idea too.
Pockets of resistance occurred at Allianz, the company’s head of IT, Andrea Hirzle-Yager, admitted during the DevOps Enterprise Summit (DOES) in London in June 2017, with members of its security and compliance team most affected.
The initiative also ran into teething problems, as the organisation’s developers and operations teams got to grips with how best to work with each other, which Hirzle-Yager rectified by getting members from both teams to sit round a table and discuss how to proceed.
“It was amazing to see that once they were all sitting there together and actually talking about what needed to be done, so many of the issues disappeared,” she says. “Some of it was just a misunderstanding of what the person actually needed.”
This environment also encouraged the members of Allianz’s security and compliance team to air their DevOps concerns, allowing the developers and operations teams to address them directly, says Hirzle-Yager. “If you don’t have your entire organisation aligned, it makes it that much more of a challenge,” she adds.
This has involved setting up leadership teams in each country to lead the DevOps charge locally, he says. “We set up our centres of excellence across the countries and set up competency centres, which assist with scaling DevOps in each of the countries to give that local touch of execution and ensure [they feel like] we’re there on the journey with them,” says Timmeny.
In some organisations, there may be individuals who feel particularly aggrieved, or even alienated, by the company’s move to adopt DevOps, regardless of whether it is being pushed by senior management or emerged as more of a grassroots initiative.
It is not always easy to find out who these individuals are, says New Zealand-based IT management consultant Rob England, who touched on this in his “Surviving DevOps” talk at DOES.
“You will have innovators and early adopters who are straight in working the new way and enthused, and it’s very easy to create the illusion that [the whole] organisation is on the move,” he says. “Then there will be the majority who are ambivalent and are talking the talk but are not necessarily on board; then you have the conservatives who take a long time to understand and adopt new ways of thinking. We have to embrace the diversity of people.”
If the resistance of these individuals risks holding up – or even derailing – the progress being made by the rest of the DevOps team, some practitioners advise taking a hard-line approach, and follow the “if the people don’t change, change the people” mantra.
But England advises a more softly-softly approach that starts with getting to grips with why those individuals are downbeat about DevOps, before educating them on the long-term benefits of getting with the programme.
“If you align yourself with a particular technology, your career lifetime is limited,” he says. “The same is true of every technical role. All of us must reinvent, grow up and move on, but the pace at which things are happening now, particularly the pace at which DevOps transformations are sweeping through organisations, has put terrific pressure on individuals to move on.”
Motivating non-movers
When dealing with people who may not see the urgency or need to “move on” in this context, England says there are a few questions that can be used to “gee them up” and stimulate a bit of self-reflection about what they want from their career.
“I tell them to look me in the eye and answer these questions: will your work be better in a year, will you be producing better results, and will you be having a better time in a year?” he says. “If they can’t say yes, they are not continually improving, so the whole fundamentals of continuous improvement are just non-existent. Also, talk about the possibilities the transformation presents to people, in terms of a better life and in terms of the opportunities to learn new things and move on.”
In DevOps teams featuring a mix of enthusiasts, ambivalent types and conservatives, parachuting in “exemplars” – individuals with skills and behaviours you want the rest of the team to develop – can prove useful, says England. “Either hire them in or move them from a high-performing team to a lower-performing team, and hold them up as a model of the kind of behaviours you’re looking for others to exhibit during the transformation.”
Altered behaviour
It is also important for senior leaders to realise that getting people to alter their behaviour takes time and patience, and not to expect the laggards to change their ways and thinking overnight.
“We can transform technology in an instant and transform process fairly quickly, but the rate of change of people – of culture, of behaviours and organisations – and getting senior management to understand can be challenging,” says England.
But if these individuals really have no appetite for change, or any interest in helping the firm achieve its DevOps goals, senior management should help them exit in a graceful way, he says. “Work moves on, and we need to move people along and that is part of the challenge. That might mean they exit, but we want them to safely exit the transformation and look after the people who go.
“You know that saying: you’re either on the bus or off the bus, and that’s fine but let’s make sure no one goes under the bus.”