As a movement, DevOps has quickly captured the attention of IT organizations over the last few years. DevOps has evolved to address the growing complexity of delivering technology-driven solutions under increasing customer and business demands, with shortened business cycles. There are many examples of companies practicing DevOps with significant benefits, a vibrant technology ecosystem (and the cloud!) making DevOps easier, and ample published evidence backing up vendor claims. All of this makes it seem like DevOps has “crossed the chasm” – safe for all organizations to adopt. However, while many organizations are having success with DevOps, some are now becoming stuck, unable to realize the benefits they hoped were possible. These organizations are unsure whether the hype around DevOps has led to inflated expectations or wondering if there might be something wrong in their approach or lack of experience in their team. If you are in one of those organizations who’s stuck, it might be useful to start with a reminder about how the DevOps got its start and its initial focus.
DevOps, a term first coined in 2009, was initially used to describe improvements in development and operations practices to reach “seamlessness, transparency, and full integration.” The need for this sort of advance was becoming evident across a variety of companies in the early 2000s as the organizational walls between development and operations, combined with a need to deliver more things quickly, resulted in increasing tensions, conflicts, and finger-pointing between development and ops teams. Early DevOps practitioners used techniques that relied on making boundary-crossing improvements using agile methods, crossing the traditional borders between development and operations, across the entire development lifecycle.
“The collaboration among disciplines involved in delivering and operating technical solutions is DevOps’ real breakthrough.”
While DevOps has evolved beyond its roots into an expansive set of concepts, practices, technologies, and tools, the initial realization of across-boundary collaboration among disciplines involved in delivering and operating technical solutions is DevOps’ real breakthrough. The point of DevOps becomes “Optimizing the Whole,” in terms of teams, teams-of-teams, practices, technologies, business, tools, and culture. DevOps fundamentally embraces the concept of “The Learning Organization” with its emphasis on the components of Systems Thinking, Personal Mastery, Mental Models, Building a Shared Vision, and Team Learning (1990, Peter Senge, “The Fifth Discipline”).
We’ve found the concept of the learning organization is the critical foundation on which successful DevOps adoption occurs.
If your organization’s DevOps adoption isn’t achieving the results you intended, here are some questions to consider:
- Does my organization have a simple vision and inspiring mission that resonates with both technical teams and their business counterparts?
- Do I understand my current system in terms of development value streams, teams, practices, skills, and culture?
- Can I describe the key ways I want to measure progress and improvements?
- Do teams have the authority and time to understand and improve their part of the system?
- Is there a distinct understanding of how supporting teams — QA, Service Management, Infrastructure, Security, Enterprise Architecture — play in the system optimized for DevOps?
- As a leader, do I trust my teams to be “self-organizing” and “self-managing?”
Here are some reasons that you might be stuck:
- Your organization didn’t “start with a strong WHY” to align teams on a shared mission.
- You have a DevOps team, separate from delivery teams, that implements tools and steps of the process, like automation. (Note: DevOps teams that focus on knowledge collection and radiating best practices are a virtuous thing).
- Your first DevOps pilot focused solely on building a toolchain.
- Your first DevOps initiative focused solely on getting to the cloud.
- Leadership declared the organization would do DevOps, but did not explicitly empower teams to make changes to their systems, processes, tools, teams, or cultural norms.
- An XYZ team (insert Security, Infrastructure, DBA, QA, here) does not feel that they need to participate in DevOps or they want to but have been excluded by accident or oversight or because of turf wars.
If you’re stuck, need answers to some of the questions we’ve asked you to consider, or have tried to implement DevOps without getting the outcomes you expected, then we’re here to help.
We’ve developed a diagnostic to help you quickly pinpoint your DevOps capabilities, compare those to best practices, and identify and help you prioritize DevOps improvements. More than that, we can support your journey towards better business outcomes through DevOps, based on our years of experience transforming many organizations, large and small.
A Feld Group Institute affiliate organization, Arrowhead Labs, was founded with the belief that every organization can achieve radical and sustained improvements in IT performance and business impact. We possess deep expertise in disciplines like DevOps, scaling agile practices, enterprise architecture, software development, service management, and cybersecurity. As change catalysts, we work with clients in applying the transformation framework of the Feld Group Institute. We act as advisors, guides, and embedded coaches, helping our clients organically and sustainably transform into breakaway organizations.
Author: J.R. Jesson, Affiliate, The Feld Group Institute and Founder, Arrowhead Labs – a Feld Group Institute partner
Connect with J.R. Jesson on LinkedIn 
