Teaching the business DevOps
There can be no doubt that agile and, with it, DevOps are core parts of enterprise IT: digital transformation is changing how business processes are structured and customer interaction is being radically changed, with a focus on self-service digital strategies.
Management consultants Version1 recently published figures pointing to a clear trend toward adoption of agile and DevOps among its customers base. These customers are already moving away from simply dipping a toe in the water.
“The overall rise in adoption correlates with an expected 29% decrease in ‘Triallers’ as this group matures in their agile and DevOps journey,” it said.
Version1 expects fully-fledged ‘adopters’ will grow by 12%, and what it calls ‘practitioners’ by 21%, in the next 24 months; with a full 55% of respondents using agile and DevOps principles in over half of their projects within two years.
Analysts have said that agile is now seen as a key strategy for outpacing the competition. Forrester’s 2019 ‘digital playbook’ Agile and DevOps Adoption Drives Digital Business Success is a case in point, saying that while many companies are scrambling to meet customer expectations, agile ones, which it calls ‘application development and delivery organisations’, are “are leading this response, transforming to deliver high-quality, innovative software solutions that delight customers and outpace competitors”.
Other analysts have observer similar trends. Freeform Dynamics, for instance, says that the “top 14% of European organisations that score highly on their breadth, depth and consistency of agile and DevOps use” are over two and a half times more likely to be growing revenue at a rate over 20%.
Crucially, though, the same report says that they are also 2.4 times more likely to have “culture and practices [that] support collaboration across development, operations and IT security”.
Mark Brennan, DevOps lead at The Dock, Accenture’s Dublin research hub, says that the benefits of agile are already clear enough.
“Businesses strive for speed to market and to be the first out with the next best thing DevOps allows businesses and teams to work rapidly and deliver changes based directly on customer feedback, quickly and efficiently.
“Core areas such as automation, meaningful metrics and continuous delivery allow businesses and teams to act immediately and turn ideas in to real value streams as quickly as possible,” he said.
Some are even suggesting a further move. As far back as 2011, Forrester’s Mike Gualtieri, while applauding DevOps said that what he really wanted to see was “NoOps”. Whether this is feasible or just rhetoric, in the here and now, DevOps is the change that is being demanded — and demanded, though they may not know that they are demanding it, by customers.
Brennan said that working to deliver IT in small projects that can be continually updated brings about a step-change in how services are consumed, both within and without an organisation.
“To satisfy today’s customers businesses must keep adapting and redefining their products and services,” he said.
“This is especially true for those that use technology to interact with their customers and where they may have originally built themselves on older technology and systems. Businesses need to be geared up to deliver at speed and take feedback directly from the customer and act on it, quickly.”
It is a fair point, and one that is widely understood, at least in a theoretical sense, throughout IT departments: agile methodologies like DevOps are driven by the desire for digital transformation, which is in turn driven, at least in part, by the need to meet customer expectations. These expectations have changed in our always-on, hyper-connected and mobile world.
In a sense, consumers are simply reacting to how the Web has changed their experiences: updates are frequent, and preferably seamless, for instance, and this is driven by an application model that is increasingly cloud and service based rather than monolithic.
“We were getting a new version of, say, [Microsoft] office every two years, and so that’s what people were used to,” said Dejan Ćušić, business director for Ireland and UK at Comtrade Digital Services.
“That was the predominant mindset, but it started to change five to six years ago. The thought was that the traditional business cycle was not good enough.”
The question, then, is: how do we get there from here?
Annie Andrews, head of technology at Curo Talent, a specialist IT recruitment firm in Reading, said that the answer is to think in terms of people rather than technology.
“Traditionally, if you take the stereotypical view of development and operations, they’re different with walls between them; different line managers and even different attitudes to life. They can work together, that brick wall can be broken down, but it’s not easy,” she said.
“It’s not just implementing a tool and you’re done. There can be all kinds of human factors, and those are the most complex things. I’ve always been interested in technology, although I’m [also] very interested in debugging people.”
After all, the last thing that any business needs to adopt is a scorched earth policy.
Everything old is new again
Agile is hardly the first revolution seeking to up-end development. Indeed, in his 1989 book “Behind the Silicon Curtain: The Seductions of Work in A Lonely Era”, Dennis Hayes recorded the frustrations of programmers just a few years earlier who worried that structured programming techniques set them on the path toward de-professionalisation. A few short years after the book was published, Steve Jobs would transform NeXT Computer into NeXT Software and push for object-oriented programming to become the norm. No doubt this development was met with the same fears. A few years later as free and open source software came to the fore similar concerns about the potential for job losses were again raised.
Today, agile stands in the same position: a revolution in progress that promises to cause a rapid increase the speed of development. This history, however, raises an interesting question: what if rather than championing agile and DevOps, IT departments fear it?
Paddy Corry, scrum master at eShopWorld, says that buy-in has to operate in both directions: from staff up and from board level down.
“In eShopWorld we have a member of the board who is very supportive,” he said.
“That culture has been moving forward for the last fifteen months and it filters down through the organisation. You can’t really have an organisation that is serious about process improvements unless the board is supportive.”
According to Corry, this means focussing on clear business-oriented goals.
“The metric we use to measure our success is the efficiency of the process. Agile approaches are about making sure you’re doing the right thing; though, as well as efficiency. It’s about making the right decisions and delivering the results faster,” he said.
Avoiding a disconnect between the business goals and the work going on IT departments is key then.
“I’ve seen, in some cases, very agile business with slow IT and I’ve also see the other way around: very agile IT in very slow businesses,” said Ćušić.
This does mean an entirely new mindset is required, however.
“I recently had a discussion with one CTO and I asked him: ‘If you have to put a name in the log files of the live server, what do you think, how much time would you need?’ This is a fairly trivial task. He was shocked by the question and said: ‘A few days’. He called into the room his head of delivery and asked. It would take four and half weeks, 31, 32 days. Imagine [if] something more complex had to be done.”
Leading from the front
If, through good internal communication, it can be ensured that IT is not a barrier to agile, then what should be its wider role in deploying a strategy for change? John Brophy, head of professional services at Daysha Consulting, a DevOps solutions company with offices in Dublin and London, says that it should have a consultative role.
“Can the IT department facilitate it, yes? Should they lead it? I really think you need some C-suite,” he said.
Every business needs to take stock of where its IT is at the moment, and this should be the first task.
“Probably the most common question we get asked is: ‘what do we need to do to move to agile?’ The short answer is: ‘where are you now?’”
The only people who can give a meaningful answer to ‘where are you now’ are, of course, those in IT.
Brophy, which has worked with the Irish Computer Society to provide DevOps talks and training, says that the model for agile and DevOps is not as unique as some of the more breathless claims may make it appear to be.
“Fundamentally it’s similar to things that have been changing in the manufacturing world for decades, things like lean [and] JIT [just-in-time] delivery; you’re starting to see that come into in the IT world,” he said.
Once this is understood — that the new methodologies have precedents and have not simply fallen from the sky — then organisation-wide adoption is more likely to proceed smoothly. This is an area where an IT department can educate the board, breaking down the jargon associated with technology.
However, Andrews from Curo Talent stressed that it is important that staff in IT departments’ do not feel that that their role is being deprecated in the process. Education plays a central role in this, she says.
“The right answer is, no IT [alone] shouldn’t be it driving it, but if IT feels it’s something being done to them, then it will create problems. It needs a certain amount of education.”
“If the business is driving it, IT needs to feel like they’re not being told that what they’re doing already is rubbish,” she said.
Anecdotally, this reporter has heard just such complaints from IT staff at a major investment bank based outside Ireland.
Accenture’s Mark Brennan says that in his own experience IT can have a role in defining a unique working culture that is centred on the practical experience of working toward delivering the goals of a business.
“Culture shouldn’t be something you try and define or roll-out, it should be a product of the work and effort put in to all areas of the business,” he said.
“When talking to clients from various industries at The Dock — our multidisciplinary research and incubation hub in Dublin — we primarily see two types of cultures at play: a ’culture of compliance’, where teams feel they need to work in a certain way, regardless of their own thoughts or ideas because that’s the way ‘it has always been done’, and then there’s a ‘culture of commitment and accountability’, where teams are committed to owning and building great technology solutions using their own skills, ideas and strengths while still aligning to common goals and aspirations of the team and business.
“This is the ideal scenario,” he said: “Don’t chase culture, let your culture find you.”
Developers working at the sharp end of the practice say that, however this culture is built, it has to be taken seriously. For instance, David Denham, of Agile-Lean Ireland, an agile meet-up community, says that as agile and DevOps begin to predominate the new culture in IT will begin to show itself.
“Agile is, fundamentally, a culture change for people, and not a set of processes to follow, so understanding ‘what’s in it for me?’ is very important,” he said.
This does not mean that it can simply grow without any direction or input, however, he says.
“Agile is no longer a niche approach, or something that’s catching on. Agile, and by extension, DevOps, is now table stakes for the majority of enterprises to benefit from the level of complexity that exists today,” he said.
“In terms of moving away from that legacy project management model, in terms of how to do that, it’s not a simple incremental change; its more about mindset. Getting help from Agile coaches and experts in the field is a good first step.”
Corry said that demystification is an important role for IT: if you want to lead change in an organisation, you must be able to speak to it.
“In every organisation context is massively important; some people say it is the most important part. If you don’t understand the situation you are in [then] how can you improve it? In fact, some people even say that if you’re going to go about making an important declaration about something like an agile approach, you shouldn’t use the word ‘agile’ too much,” he said.
“One thing we are careful to do in the team at eShopWorld, is [to] not use too much jargon. Clean language is a real skill, and if you’re not bogged-down in jargon you’ll make things happen.”