Three Elements of DevOps Transformation

Original Publication at DevOn Blogs

First element: Customer Obsession Over Tools Obsession

Most organizations, when starting their DevOps journey, build audacious goals to automate current painful processes like build and deployment using CI/CD tools. These tools provide a quick win in seeing features and defects moving faster, mostly for product owner review in staging and sometimes to production. Beyond these brownies, it becomes difficult in DevOps Transformation to showcase the value to the business.

We have also seen organizations recruit talent in tool stack and claim to be unicorns of DevOps. This DevOps team of Unicorns helps in automating the processes, but don’t have the opportunity to understand the end-to-end value stream. Ultimately organizations suffer from creating a siloed team between dev and ops.

DevOps is seen as a methodology for Automation and not from a value-driven initiative to its customers. By pushing features to the customers, we don’t know if they are getting benefitted by it.

The first step in DevOps transformation is gaining a deep understanding of what works for the customers, which will directly help to stop burning your IT budgets that don’t add value.

Second element: DevOps Culture

The next step in DevOps transformation is understanding how IT teams collaborate in delivering value to your customers. DevOps Research and Assessment (DORA) report provides an empirical evidence in seeing organizations leaping in its DevOps journey when friction between business, development, and operation teams are removed. Organizations should work towards building high-performance teams – one that encourages curiosity, experimentation, and an environment to fail and learn from failure fast.

J Curve of Transformation

Third element: Managing Technical Debt

Many organizations struggle to balance the speed with the stability of the system. Measuring and working towards what slows you down to deliver value to your customer is vital in DevOps transformation.

“Technical debt is a term that describes the future penalty that you incur today by making easy or quick choices in software development practices.” As per the State of DevOps 2018 report, Automation will add more impediments, and teams need to slow down its velocity.

At the enterprise level, technical debt gets accumulated in two ways; supporting redundant platforms and solutions, and having multiple vendors in a value stream. Gartner TIME Model (Tolerate, Invest, Migrate, and Eliminate) helps to systematically assess platforms and take the right path in technical debt reduction.

At the application level, we see technical debt in the form of Non-functional requirements like performance, security, scalability, deployability, and testability. Integrating with quality tools earlier in the development cycle reduces the impact.

Gartner Use time to Engage the business for application