Digital Transformation
Showing results for 
Search instead for 
Did you mean: 

Why DevOps is much more than Dev and Ops


When dev and ops teams use agile dev and DevOps, what they are trying to get to is to be agile and, if possible, continuously innovation.

Why do people get “stuck” when trying to do DevOps?

But research tells us that when people get “stuck” in their efforts to implement DevOps, it has little to do with tools. When they get “stuck”, it’s due to “those other people” (50% of the time) and to processes that don’t match with agile and continuous innovation (37% of the time). Tools and technology blocks only 13% of efforts, between them. (These stats are from a Gartner Feb 2016 DevOps survey).
For example, I talked to a customer recently. She said was “stuck” in her agility and continuous delivery efforts because of ..

  • A product owner, who is 55, and has, all his professional life, been writing requirements specs and external specifications, and then going away for a year while the lab “creates the product”. He’s in another group to the deve team and is not measured on agility or continuous innovation
  • A management team who keep asking “when will it be out?”,  “what functionality will it have?”,  “how many story points have you implemented?”,  “what’s your story point velocity (number of story points per sprint)?” These are all “waterfall-based measurements” that simply don’t apply to agile development, and even less, to continuous deployment and continuous innovation
    The Gartner research I mentioned above fits exactly with what I’ve seen. All I’ve ever come across is people who need help with organization, with goals, with attitudes, with management expectations, with how to form the work unit, with how to do ongoing coaching.  

Business Management, and especially product owners, need to take part in agile and continuous delivery

I believe that business management, business owners, and product owners need to think about first is “how are we going to run our product development lifecycle?” That, for me, is the “uber-decision” that drives all other decisions. 

And this decision can’t be made by poor old application dev team in isolation. It can’t be made by the dev and the ops team together, either. It’s a business level decision which must, of course, include dev and ops, but must also include the business owner and their product management team. 



So, the uber decision is of the form …

1: Are we prepared to start with an Minimum Viable Products?

Are we prepared to start with a minimum viable product, knowing that we’ll quickly get to something that is richer in functionality?

(Note to business management - your first release could be somewhat embarrassing. As the saying goes, “if you are proud of your first product release, you released WAY too late”. “The Innovator’s Dilemma” by Clayton Christensen talks about how first versions of products that later go on to kill an existing market leader are often seen as very limited).

2: Are we prepared to experiment?

Are we OK with putting out a “canary release” (a limited released) and maybe having to quickly withdraw it? What about A/B testing where we put out parallel products in different demographics, taking the best parts of each?

(Note to business management : you won’t be able to use “number of releases” or “number of tested story points” as a measure of progress, because a whole sprint (i.e. experiment) could be trashed)

3: Are we prepared to do “continuous innovation”?

Are we going to put something out, see how people like it (typically, using advanced data science techniques - see my previous blog post on this), and then quickly adjust.

(Note to business management - you may get a little bit of bad press for one of your releases. But, because your dev team is using continuous delivery, it will be fixed very quickly. I was at the wonderful Picasso museum in Barcelona recently. The museum shows the route that Picasso took to his first cubism picture. To him, some of his efforts were terrible and he quickly retraced his steps. The eventual result, of course, changed art for ever. In other words, on the road of innovation, not every step is a “forwards” one.)

What do you do if business management won’t play their part?

What do you do if you can’t get business managers and product owners to agree to help with agility and continuous delivery, and to measure and reward in the right way?

A customer I talked to recently gave me this advice, “if your management and/or the business owners and product owners aren’t prepared to take part in this [“this” being continuous innovation, experimentation and MVP], THEN DON’T BOTHER WITH AGILE AND DEVOPS. Just use waterfall – agile without business and management playing their part is worse than waterfall”.

This is a somewhat extreme view from someone who was asked to “do agile” without any management support, but certainly agility and continuous delivery without business management support is like bashing your head against a brick wall for the poor development team.

HP DevOps.png

(The phtoograph above shows HP's very first DevOps project. HP's CIO planned to attend the effort for the first day. He stayed for the whole of the first week. Management commitment.)


Mike Shaw
Director Strategic Marketing

linkedin.gifMike Shaw

0 Kudos
About the Author


Mike has been with HPE for 30 years. Half of that time was in research and development, mainly as an architect. The other 15 years has been spent in product management, product marketing, and now, strategic marketing. .

See posts for dates
See posts for locations
HPE at 2018 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2018.
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all