Why Is Proving and Scaling DevOps So Hard?

Bart Driscoll By Bart Driscoll Director, DevOps Services April 19, 2016

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.

Bart Driscoll

About Bart Driscoll

Director, DevOps Services

Bart Driscoll is the Director for the Application Modernization discipline within the Americas. Application Modernization services deliver a full spectrum of assessment, planning, implementation, and transformational services to enable customers to drive down cost and accelerate time to value in application delivery. This group specializes in Mainframe Transformation, Legacy Application Modernization, and DevOps.

Prior to his current role, Bart was the Application Architecture, Design, and Development Managing Principal for the Northeast/Canada division. Here Bart managed a portfolio of programs and projects focused on application development and software delivery optimization. While his primary responsibility was delivery oversight, Bart also played an active role in presales and helped grow bookings in region by over 100% in two years.

Bart has broad experience in IT ranging from networking engineering to help desk to application development. He has spent the last 15 years honing application development and delivery skills in roles such as Information Architect, Release Manager, Test Manager, Agile Coach, Business Architect, and Project/Program Manager. Bart holds certifications from PMI, Agile Alliance, Pegasystems, and Six Sigma.

Bart earned a bachelor’s degree from the College of the Holy Cross and a master’s degree from the University of Virginia.

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *

3 thoughts on “Why Is Proving and Scaling DevOps So Hard?

  1. Great article on DevOps as it discusses the challenges in rolling it out. I’m also interested to understand how pricing for DevOps services is done.

  2. interesting article on devops services.DevOps practices permeates all of application life-cycle to reduce the time to market. The most important principles of devops are to reduce isolated development environment, eliminate tasks which are not adding value to the business