Sweeping aside slow movers with DevOps and agile


Organisations that eschew DevOps as part of a broader shift to more agile ways of working risk being overtaken by faster-moving, more flexible rivals warns David Njogu, CTO at QA Consulting. David Njogu likened the coming revolution to the military revolution of the 1790s, which saw Napoleon's armies sweep aside the Prussian army - the largest in Europe - and the industrial revolution, which saw most cottage industries put out of business by factories and the efficiencies of mass production.

However, even in organisations that have shifted to agile and DevOps methodologies, not all have fully comprehended what they need to do to make the most of them.

"What I've found with most organisations that we've worked with is that they are very good at continuous delivery, but what they lack is a sense of enhancing the continuous improvement, because that's not only about delivering software quickly and frequently, but it's also about the culture of the company," says Njogu.

DevOps has also coincided with the rise of onshoring, notes Njogu, as organisations bring development, in particular, back in-house and back closer to the centre of the action.

The reasons for this are two-fold: with IT development shifting from long-winded waterfall methodologies to agile, organisations are expecting IT to work more closely with the business to develop what they want, and this means iterative development and deliveries of incremental features and functions in weeks, not months.

Furthermore, with IT more central than ever to the success or failure of the organisation, it needs more control over development to improve the organisation's business responsiveness.

"A lot of organisations that we have worked with [at QA Consulting] are now bringing back software development. A lot of them had it offshore, but there were lots of difficulties.

"I worked with an organisation whose developers were in Brazil and the testing team was in India. It was quite a big challenge to get the different units to work together and, in the end, we weren't able to do that because the organisational culture was not ready for that kind of involvement of having DevOps teams - or any team for that matter - in different geographic locations and time zones," says Njogu.

"High-performing organisations are also less likely to run their software on mainframes... We've always had a big problem [at QA] implementing DevOps in an environment where a lot of the applications are running on mainframes. We have to do a lot of work to make the services more loosely coupled in order to move forwards with a DevOps environment."

The trouble is, he adds, that many organisations will adopt DevOps in a similar way to the post-war Cargo Cult movement of the South Pacific Islands after the Second World War.

"During the Second World War, the Americans used many of these islands as their bases. The indigenous people didn't see the full force of the American military - they saw planes landing and supplies coming off: jeeps, washing machines, radios, motor cycles, canned meat. They associated the landing of planes with the 'age of plenty'.

"So when the Second World War came to an end and the American troops left, what the indigenous people thought was that if they built their own structures, their own 'aeroplanes', their own airstrips and control towers, then all of sudden those supplies would start to come in again," says Njogu.

However, mimicking DevOps practices like the Cargo Cult won't bring in the benefits, he stresses.

"It's very similar to what we've seen in some organisations. They think having the tools, having automated configuration management, having monitoring tools, continuous integration tools automatically qualifies them as a DevOps organisation. But you find that what they are implementing is not DevOps, it's not agile development, it's not anything: it's just a hybrid of waterfall and other things," says Njogu.

Is your organisation thinking about investing in take a look at our DevOps 101 blog?

Article taken from Computing.com.

From this thread

1 related stories

See all of them

take me back to

qa blog