Agility of businesses to transform and adjust to market conditions is perhaps the most important aspect of managing today’s enterprise. With digitization of almost all facets of running an enterprise, it is safe to say that IT agility translates to either the success or failure of such adaptation. Smaller and new-age businesses are better able to adapt, while large, established enterprises struggle or are too slow to adapt. Large enterprises have been executing in an established, traditional way for decades and have solidified their existing processes and decision-making.
New-age businesses don’t have a choice. They have to be agile because of the force to create something new. They either have cloud-native technology support or, even with traditional IT are able to embrace agile, automation and continuous delivery paradigms to stay nimble.
So, what constrains large enterprises? There are three main elements: organization structure, legacy technology stack and culture.
The good news is that there are proven industry approaches to embracing agility in delivering business outcomes. The bad news is that it is quite often a long, arduous journey. This long transformation is often riddled with compromises from “comfort zones,” is potentially career-redefining for executives and practitioners and, of course, requires a fair bit of time and dollar investment.
In my travels and working with many clients across multiple industries, I’ve found that executives do not like terms such as “transformation.” Somehow it is often interpreted as “cost cutting” or “resource realignment” or “outsourcing.” There is some merit in using terms that are appropriate to each enterprise. But, the intent is to transform the way solutions are being delivered today and to do it faster, cheaper and better. The techniques of Agile and DevOps have been successfully implemented in many large and small organizations to enable those outcomes.
To address the three areas of organization, technology and culture, let me present an approach that works quite well for most enterprises. There is always an element of customization of the approach to meet specific needs, but it should provide a basic framework of the activities and potential time frames necessary to implement the transformation program.
The Six-Step Approach
Step One: Initial Planning for Enterprise Readiness
Participants and Inputs, Existing Collateral, Design Thinking, High-Level Outputs
As stated earlier, these steps are customized to each organization, including the participants and inputs, among other factors. For example, the CEO may not be the program sponsor for a given enterprise as it could either come from the CIO or it could be business line-driven. Other enterprises may choose to launch the program at director levels. If possible, this should not be done. The highest chance of success is when the program is championed at the highest levels.
Participants should absolutely include all the towers that make up the solution delivery. Business participation is imperative, along with operations, security and development. I always recommend that the workshops conducted in this step be led by an external experienced consultant or a coach. The key here is to get executive buy-in and create common goals and understanding on what an Agile-DevOps program will look like.
Typically, there are several small DevOps programs already in place in silos that lack maturity to scale to the enterprise level. Design Thinking is a great method to use since it leverages the expertise of all stakeholders, enables them to come to a common understanding, and establishes the needed buy-in. The diagram below illustrates an initial plan for project readiness incorporating the components discussed. 
Step Two: Establish a DevOps Center of Excellence
Identify an Executive DevOps Lead with Enterprise Authority
Establishing a Center of Excellence (CoE) is not good enough if it’s not at the right organizational level and enterprise authority. It has to be led by an enterprise leader who has the support and buy-in from all the towers. Active participants of the CoE include representatives from all the delivery towers and also vendor organizations. These participants must be chosen wisely.
I highly recommend that initial phases of CoE be led by an external experienced partner and transitioned over time. The initial phases help cement the vision and strategies of the COE and setup the best practices to support it. Typically, the time to transition from the business partner to internal is 12 to 24 months.
Step Three: Establish Program Governance
Create Communications Plan, Enablement Program, Establish Program KPIs
This is the most important step to make an impact to the culture of the organization. With Agile and DevOps, practitioners’ roles and responsibilities will change. They’ll need awareness, enablement and empowerment to succeed. It is extremely important they understand collaboration between organizations that historically may have had animosity so they can break down these organizational walls. KPIs must shift from individual metrics to holistic customer business outcomes.
Step Four: Establish Project In-take Process
DevOps Subject Matter Experts (SMEs) Conduct Intake Workshops for Scrum Teams
Project intake really sets the tone for how successful each sprint that onboards the program will be. It is not so much about tools and process, but the right sizing of tools and process. There needs to be a fit for purpose in the selection of accelerators, tool chain and development methods. Once established, communication of the intake process needs to occur across the organization. Gather feedback and continually evolve and mature.
Step Five: Identify and Initiate Pilots
Applications Representative of Target Portfolio to Scale
This step has the best chance of success if applied to a specific portfolio of applications or a domain solution. I strongly recommend having some working sessions prior to this workshop to identify an area of development work that represents a portfolio to scale to the enterprise.
The purpose of this step is to conduct a value stream-mapping exercise of a specific application with participants from all towers. This needs to be conducted with the level of detail necessary to identify end to end as-is process, tooling, manual and automated processes, and skills and people involved.
The next part of the project intake is the collaboration of the subject matter experts (SMEs) from the CoE with the project team. The purpose is to advise on “to-be” process with necessary tooling, reusable assets, automation and SMEs needed from operations, security and other applicable areas. These SMEs will comprise the application scrum team. As the application goes through its development/test cycle, identified KPIs for the program are captured. This is absolutely necessary to compare with existing KPIs.
Step Six: Scale Out DevOps Program
Onboard Parallel Release Trains; Apply Intake Process; Support, Monitor and Manage
The final step is to take feedback from metrics of the pilots and scale them by running multiple release trains from different application portfolios. It’s not good enough to just do daily builds and automated deployments. The final piece of the DevOps puzzle is the continuous feedback and optimization.
Summary
The above is an approach that can be implemented in a flavor that best represents each organization’s needs and constraints. Be considerate of large gaps or excessive deviations that may be red flags to be corrected.
Now that you are equipped with the six steps for an enterprise DevOps transformation, you can look at each of them critically, see best fit, and start the journey!
I will be @ Interconnect this year for a session on Environment As A Service. Stop and say hello. Other articles to reference are: “Five things to understand about Enterprise DevOps Solutions,” “DevOps in a Hybrid Model,” and What is platform as a service (PaaS)?”
About The Author/Sunil Joshi
Sunil is an IBM Senior Certified and Open group certified Distinguished Architect. He is currently the Application Innovation Cloud Services Emerging Technology leader. His specialization is in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA). Sunil is a regular speaker in the industry on Cloud, DevOps, Microservices, Digital Transformation and related topics. Connect with him on LinkedIn | Twitter
