It is one of the common beliefs in the IT industry that the ultimate goal is to release software as often as you can. Now, that maybe the ultimate goal for some companies, like Amazon or Netflix, but there are companies for whom this is not the desired goal. In fact the truth is that there is no one criterion that fits all. The success criteria for your DevOps implementation is unique to you. DevOps is all about continuous improvement realized through changes, both big and small. But the ultimate goal is to continuously facilitate the flow of work through the value stream in order to improve how we deliver value to our customers. Therefore, the core tenet of DevOps is to have a strong organizational culture that allows us to enact change as required and evaluate outcomes.
1. Visibility of Work
The first consideration to ensure DevOps success is making the work visible. The mission of every company in the software development sphere is to deliver value to customers and get better at ensuring customer satisfaction with time. However, this actually continues to be challenging. The reason for this is that the work and progress is not visible. This makes the work process lengthier and also, causes misalignment within the company. As a consequence, there are longer development cycles and sometimes the need for re-work. In order to make the work visible, all the teams involved must convene and agree on the development process that is going to be followed, from the idea stage to delivery. Once the value stream has been mapped, we must visualize the work that is going through it. This helps drive DevOps success. It will provide not only alignment, but also a common understanding of the process.
2. Using a Common Metric for Value across the Organization
Different teams in the organization use different metrics to measure the work that is being delivered to the end user. For example, business teams may use portfolio items or features as metrics to measure value while development and operations may use releases, versions, and packages to measure the value delivered to end users. Here lies the difference in considerations. The most effective unit of business value that can be considered for DevOps implementation is work items. This is a common metric that can be shared by both the business as well as development teams, considering how portfolio items get fragmented all the way into work items in development. So, when we are actually performing code commits we can affiliate them to those work items, which is basically the business value. This way the enterprise can use a common metric to track and measure progress. Enabling code to inform the progress and movement of business value as it flows through the value stream not only empowers the business stakeholders but also members of the development and operations team to obtain that code driven information for business objectives.
Over the last couple of years, lot of companies are buying tools, changing processes and spending a lot on their DevOps initiatives. However, they aren’t measuring the value. Now, this is something that should be given due importance at the start of our DevOps implementation. We really need to measure the entire flow of the value across the value stream. It should not only be measured in one phase or in one area but should be done end-to-end. Measuring the process in the different phase of the value stream will allow us to identify areas of opportunity and bottlenecks. One of the metrics to measure would be cycle time, i.e. how long it takes for the value to complete a full trip across the value stream. The other common metric to measure would be efficiency. This would measure the time the software packages are actually being worked on versus the time they are simply there in an environment waiting for someone to interact with it. Another metric to measure would be batch size, i.e. how many work items and defects can be found in any given software release.
4. Configuration as Code
Configuration becomes essential as we get into DevOps engagements. We need to leverage the investment we put in, in terms of developers and time, across the entire DevOps infrastructure. This is an important aspect in managing changes to functionality and performance of deployable components. The ultimate goal is to version everything that is touched during the software development process. Proper versioning of all the configuration changes allows for faster and more frequent deployments, simple roll backs and you are able to have fully isolated environments.
This is the process of ensuring that the deliverable elements of the software development process are in compliance. Teams should embed the compliance aspect of software development into their value stream. This allows them to avoid re-work and waste. Compliance activities should go on in parallel with the development and testing work as opposed to when the release is marked done or code is completed.
At the end of the day, for a full-fledged DevOps success, we must ensure that every software release that comes out of our value stream should be fully compliant and we can deploy it into production at any time with the confidence that all the checks and balances have taken place.
Check out our whitepaper on building a DevOps organization and culture.
Shuvro Shankha Sarkar
Senior Consultant Marketing