My team and I regularly meet with customers who ask the same question over and over, “how do we become successful with DevOps-at-scale?” This question is normally followed with a laundry list of “here is what we are doing around…” infrastructure automation, container pilots, continuous integration, test automation, cloud platforms, etc. The brief summary is concluded with comments about how difficult acceptance and adoption of these new tools and practices are. So why is DevOps so difficult to scale?
First off, DevOps is extremely pervasive. Success with DevOps will change or influence nearly every aspect of IT and even many parts of the business. Even setting a simple goal, like “deploy into production every 30 days”, touches software development, testing, operations, infrastructure management, databases, security, compliance, architecture, release management, project management, and more. I believe that everyone “knows” that DevOps is big but until you can map out the end-to-end process and rationalize the associated stakeholder and SME community, getting acceptance and/or adoption of DevOps and Continuous Delivery will be impossible. Success will require the input, expertise, and support of this community. Don’t underestimate the complexity and size of your enterprise value stream; you will need their support to implement tools, set standards, and drive adoption at-scale. Tackle it iteratively and use early wins to generate momentum.
For those just starting DevOps, many will attest to how difficult it is to “get moving” or “continue moving”. The second impediment to DevOps-at-Scale is organizational inertia, or the tendency of an object to keep moving in a straight line at a constant velocity. Human systems naturally gravitate towards stasis, or steady state, because it take less energy and requires less thinking – this is the inertia. DevOps confronts both the status quo and this natural tendency by constantly challenging how you budget, plan, manage, execute, and organize around work. It does this by regularly introducing new tools, practices, and processes design to continuously improve and optimize the deployment value stream. This new “norm” is especially difficult for team members that are comfortable-enough with status-quo and even more difficult for those that feel threatened by change. This is commonly referred to as “changing culture”. Be realistic about pace and be ready to act knowing that more than 80% of your organization is skeptical of success and 10% of those skeptics will outwardly defy change. Use coaches, collaborative design sessions, internal champions, and executive support to encourage participation and ownership in the end state. This will help built momentum.
Lastly, have a vision. It is much easier to build momentum when there is a common, shared vision of where you are going. Too many customers substitute a tactical list of to do items for vision. This makes it extremely difficult to connect the parts, define shared expectations, and understand the value. All “to do” items should be mapped to a targeted near-term objective; each objective should be mapped to one or more organizational processes; each process is linked to annual IT goals that are then connected to enterprise strategy. Without this enterprise lens, it is difficult to map and measure impact to enterprise success or to prioritize tactical projects based on impact. If you cannot demonstrate the relevance of DevOps to the bottom line, it will be difficult if not impossible to get funding and support.
Scaling DevOps, like all organizational change, is a difficult and often slow process. By acknowledging the common challenges outlined above and creating a unified vision of success, you will be well on your way to unlocking the potential of DevOps in your Enterprise.
