Top DevOps Challenges at DOES19


I recently attended the prestigious DevOps Enterprise Summit in London. During the three-day event, I asked people what their major DevOps transformation challenge is. I wanted to examine these at global events, asking the same question.

I recently attended the prestigious DevOps Enterprise Summit in London. During the three-day event, I asked people what their major DevOps transformation challenge is. I wanted to examine these at global events, asking the same question.

Recent Posts By Mark Smalley
The Third Way of DevOps: Stacking the Cards in Your Favor
More from Mark Smalley
Related Posts
Top Skills for Enterprise DevOps
DevOps Is About Serving The Customer: Q&A with Shridhar Mittal
Digital Business: Paving the Way for DevOps’ Second Act
Related Categories
DevOps Culture
DevOps Practice
Related Topics
devops challenges
DevOps enterprise summit
Show more
I was GamingWorks’ booth boy at the event, which gave me a chance to ask a lot of delegates visiting the stand.

Here is a summary of what they said, with my commentary based on what I have picked up on my travels as The IT Paradigmologist.

Business Value
Understanding the link between IT work and the business strategy.
Seeing the whole end-to-end picture (visibility, transparency).
Measuring the right things—team performance in terms of business outcomes.
Commentary: Not only do IT people have difficultly understanding the business value of their work, they often are poor at articulating it to business executives. My DASA white paper, “The Business Value of DevOps,” and accompanying webinar elaborate on the topic.

Finding the right balance in standardization across teams.
Commentary: Governance is such a tricky topic. What do people mean by it in the first place? How negotiable should the boundaries be? Particularly in complex and therefore unpredictable systems, professionals need to make judgment calls and act for the best. Regarding standardization, the question is always about value: Does standardization and centralization lead to significant improvements in results without introducing frustrating bureaucracy? Otherwise, you’re better off letting the individual teams decide for themselves what is most effective for their value streams. Yes, it might be more expensive than one-size-fits-all, but the benefits usually outweigh the costs.

Doing things quickly while maintaining quality.
Commentary: It’s a question of balance. Not only speed and quality (depending how you define it, of course), but also resilient operations, co-created value and assured conformance. I like the Deloitte #BVSSH way of putting it: Better, value, sooner, safer and happier.

Value Streams
Breaking down silos.
Collaborating better between silos.
Giving more autonomy.
Integrating DevOps parts in a predominantly non-DevOps value stream and vice versa.
Commentary: On the conference scene, almost everybody has an idea of what value streams are. Visit an average IT department though, and for most people it’s an alien concept. We live in a bubble. You have to take a few steps back and start from where they are. Take it step by step. Collaboration seems to be one of the top challenges as confirmed by the recent DOI skills survey, which had this as a top soft skill. It may be a soft skill but it is hard to achieve. The article “DevOps and Collaboration: Fraternizing with the Enemy” provides some guidance on collaboration.

Discovering a new way of doing ops.
Shifting from old ops to new ops.
Commentary: This is a very hot topic. Witness the promising changes in ITIL 4. Less process, more heuristics, more value-orientation (for instance, value streams and co-creation with the service consumer) and more human. It’s very encouraging to see how DevOps communities—some more enlightened than others—are developing their ops capabilities to restore the balance. But ops work differs fundamentally from dev work, and that has to be reflected in the way of working.

Organizational Change
After the initial enthusiasm, “what’s next and how?”
Overcoming resistance to change and inertia in general.
Accepting the consequences of doing DevOps.
Unlearning 30 years of doing the same thing.
Learning quickly.
Developing skills to transform.
Assessing the risk of transformation.
Sharing (and learning from others’) practices.
Commentary: There is too much lip service and too little commitment. There are notable exceptions, but too many people are looking for the quick fix and believing they’ll find it. Good luck. As Taiichi Ohno said, “You have to think for yourself and face your own difficulties instead of trying to borrow wisdom.” If you don’t know who Ohno-san is, that’s a good place to start. If you’re serious, take a look at Paul Wilkinson’s astute observations about challenges and enablers for DevOps success at DOES18 USA. You’ll notice many similarities with my findings at DOES19 UK.

Culture and Emotions
Getting enough diversity in the team.
Getting different personalities to work together.
Trusting and being trusted.
Feeling non-DevOps teams are worth less, but not worthless.
Commentary: More on culture and people can be had on the DOES18 blog, but it is encouraging that people are actually talking about this more often. It’s something that almost always crops up in The Phoenix Project business simulations that I facilitate for organizations. Topics such as psychological safety: whether you feel comfortable being and expressing who you are. So, do you? Dr. Christine Maslach referred to the toxicity of some workplaces with the analogy, “You want less toxic mines, not more resilient canaries.” Work-in-progress.

Understanding which tools are around (tool confusion).
Integrating and then orchestrating tools.

Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x