JAXenter: Who is leading the DevOps show? Developers or operators?

Greg Bledsoe: Here’s a DevOps secret:  Mandates from one person or group to another don’t work.  When you hand down an edict you automatically engender at best indifference and at worst passive-aggressive resistance (and sometime macro-aggressive resistance!)  In this case, the only entity that cares about whether the new processor tool works is the person or group that handed down the edict, and everyone else is checked out.  

One of the two core ideas that started DevOps is Collaboration.  Collaboration means negotiation, compromise, and diplomacy leading to all the stakeholders feeling like owners of the entire process and toolset, and the outcome achieved.  In this case, everyone is motivated to solve resulting implementation problems.  This is the genius of Deming’s point:  turn everyone into agents of transformation.

To bring this back to the answer to the question:  If any one person or group is pushing DevOps onto others, it isn’t DevOps.

JAXenter: The focus is slowly shifting from “What is DevOps?” Where do we start?”. How do we answer the second question?

Greg Bledsoe: Every organization is a special onion.  The reasons or pathologies that have resulted in the current process don’t suddenly go away because you want to do DevOps.  Customarily organizations want to look at examples of what everyone else is doing and copy that.  This is exactly backward, what Deming called “managing for result” instead of managing the cause.  Results are side effects of effectively managing the cause, and this requires two things.  A deep understanding of the operating principles of DevOps, and a deep analysis of the causes and misaligned incentives that prevent these solutions from emerging.  

An organization often needs outside help to do this.  It is tough to see your own forest for the trees, and both Deming and Drucker, whose principles form the foundations of DevOps, were big believers in introducing someone new into the scenario to diagnose what’s in the soup your swimming in.  This comes down to the power of the invisible bonds of culture.

JAXenter: How important is it to incorporate security into DevOps (DevSecOps)? What are the benefits? Should it be a priority or an afterthought?

Greg Bledsoe: DevOps maturity is plotted along two Axis:  Depth of Automation and Width of Collaboration.  DevOps that doesn’t include security into the “shift-left” mentality is immature DevOps.  Similarly, DevOps that doesn’t bring monitoring and invite the business into the process is immature DevOps.  DevOps means continually improving and maturing our process to produce predictability, reliability, and quality while removing obstacles to flowing value to market – once you have basic automation and collaboration, you have to look at bringing in more partners and stakeholders.  The easiest way to get there from scratch is to bring them in from the start.  

The short answer is that it is critically important and whether this is overlooked is a good indicator of the organization’s DevOps maturity.

.

JAXenter: How important is automation in a DevOps context and what are the areas where automation is really needed?

Greg Bledsoe: Again, collaboration and automation are the two foundational elements of DevOps.  Without automation, what you are doing isn’t DevOps.   Everything that can be automated should be automated, and everything can be automated.  Collaboration is necessary to achieve effective automation that meets the organizational goals, so there is a synergy between these two axes.  

JAXenter: Should testing become an essential component of the CI/CD pipeline? Are we underestimating its importance?

Greg Bledsoe: Testing should definitely be automated into the pipeline – every manual action is friction and delay in the flow of value from idea to market where you can begin gathering feedback on whether what you did is actually what you should have done.  The faster that feedback loop, the quicker you can pivot towards maximum value.  This is also where most are struggling to get from manual process to automation, and there are many and varied reasons for that, all of which have solutions.  

JAXenter: Some companies are still struggling with DevOps metrics. What are the key metrics that matter and how can they enhance DevOps success?

Greg Bledsoe: There is no “one true metric.”  This depends on the organizational context and finding it is a result of exploring an organization’s DNA, history, and context.  Many people find that “change velocity” is the best indicator of performance, but that certainly isn’t always true, and adopting a metric without due consideration can pull your focus away from things that might actually be more important for your particular organization.  

JAXenter: How important is it to not skip steps in the DevOps transformation cycle? What are the steps that companies and/or teams usually ignore or underestimate?

Greg Bledsoe: This question is very difficult to answer without knowing what the transformation methodology you are referring to actually is.  In the methodology I subscribe to and have successfully applied many times, every stage is critical, but these focus primarily on the human system and drive change from there to the technical system.  There is a reason we say in DevOps that we go through 1. People 2. Process 3. Tools.  You can think of the process as the intersection of culture and technology – the guide rails around its use, and this is where reform is first needed.  In general, organizations want to implement technical solutions instead of human solutions because human solutions are much more difficult to implement, and we aren’t generally attuned to how to manage the human system in this new way. Trying to skip to the end of implementing examples instead of principles is a sure route to underachievement.

JAXenter: Do you think the abundance of DevOps tools has helped or slowed down DevOps adoption?

Greg Bledsoe: Honestly I don’t think this matters to success or failure very much.  There are many tools that can achieve the same ends, and it is a poor craftsman that blames his tools.  DevOps adoption is a function of the absorption of the underlying principles into the organization overall.  A DevOps architect is an architect of principles more than toolchains, and once you understand that you’ve made a quantum leap towards DevOps effectiveness.

JAXenter: There’s a huge demand for DevOps professionals. What skills do you need to have in order to tap into the perks that accompany the job description?

Greg Bledsoe: I look for a strong understanding of the fundamental principles of DevOps.  The technical skills can be learned and must be continually learned and unlearned.  The only constant is the underlying principles that account for why DevOps works or fails.  If someone understands this then decisions are made with the correct end in mind instead of the momentary urgency.

Thank you very much!