Micro Focus is now part of OpenText. Learn more >

You are here

You are here

A seat at the table: 5 things holding DevOps leaders back

public://pictures/mark_schwartz.png
Mark Schwartz Enterprise Strategist, Amazon Web Services
 

DevOps represents a new way of organizing and performing the work of IT. To make the most of it, though, enterprises need to change how they think about IT leadership and how IT fits into the business organization.

It's true that the fast feedback and agility of DevOps to enable them to learn and adjust. But if companies are still making IT investment and governance decisions based on grouping a large set of requirements into a fixed project scope, they will not be able to take advantage of that learning and adjustment. Or if the fast release of small and low-risk changes into production runs up against the organization's traditional processes of drawn-out end-user testing, training, and change management, the fast-feedback cycle will be compromised.

We often lump these issues into a vague need for cultural change to support DevOps adoption, but they are more than that. The underlying barrier to DevOps—or at least to realizing the full value of DevOps practices—is that we have traditionally defined the role of IT in the enterprise and the role of the CIO at the leadership table in a way that limits the value IT can deliver.

 

Outdated ideas

Some of the traditional ideas about IT that no longer fit are: 

  • Investing in and making governance decisions should be based on a fixed set of requirements. Traditionally, we pinned down a set of requirements, made assumptions about the impact they would have, built a business case based on that impact, and greenlighted the project based on the business case. But this causes a tension with the way agile and DevOps approaches actually execute, with continuous learning and fluid requirements.
  • Progress and success should be measured against a project plan. Even in Scrum, where the plan is fluid, we still orient around a burn-up or burn-down chart that assumes a particular scope, a "backlog" of requirements that are assumed to need doing. In truth, some of those backlog items might be less vital to the company than redirecting resources to a different project.
  • The business knows what it needs and will communicate those needs to the technical team. It's outdated to believe that—whether through a requirements document, a product owner, onsite customers, or any other model—the business has more than a hypothesis about what might be effective, and that the technical folks are not part of the business and have no say in what the needs are.
  • IT systems or applications are discrete products with one or two integration points. Except where we are buying a commercial product—which is truly a "product"—our IT capabilities now come as microservices delivered through a variety of user interfaces and touch points. The idea of separate systems with separate lifecycles, separate investment streams, and separate governance processes is causing technical debt and reducing the efficiency of our investments.
  • Users are technically naive and technical people are not business-focused. These stereotypes have carried over from the early days of IT (and were probably not true even then). 

These are just a few examples of traditional ideas that are holding back our ability to drive transformation or to realize the full benefit of transformation when it occurs. And at a fundamental level, they all come back to one bad idea: IT and the business are two separate things, with IT being a service provider to the business, something like an independent contractor that happens to draw a salary from the company.

[ Special coverage: DevOps Enterprise Summit 2017 ]

And this contractor relationship has been governed, like other contractor relationships, by breaking work into fixed, well-defined chunks, agreeing on the scope and terms for each chunk, and then asking the contractor to hand over finished product to the business.

How old ideas diverge from DevOps

These old notions do not fit comfortably with a DevOps model based on flow, fast feedback, and empowered teams. Instead, a DevOps organization must be flexible enough to make governance decisions at a smaller granularity, and then adjust those decisions as it learns more through fast feedback cycles.

It must organize its initiatives in terms of desired business outcomes rather than sets of requirements, passing those desired outcomes to empowered teams and allowing those teams to decide the best way to accomplish them. Then it must gauge success by the extent to which those outcomes are achieved.

In my latest book, A Seat at the Table: IT Leadership in the Age of Agility, as in my previous book, The Art of Business Value, I discuss these and other issues that impact IT leadership and the relationship between IT and the rest of the enterprise. I will be speaking further on what it means to lead IT at DevOps Enterprise Summit 2017 and look forward to discussing it with you there.

 

Keep learning

Read more articles about: App Dev & TestingDevOps