Being able to make changes, fix bugs and respond fast is also a key measurement to ensure you are on the right track in a transformation. “A good question to ask yourselves is: How fast can a critical error be fixed in production given you already have a fix ready?” said JetBrains’ Naumov. “This is a good measure of whether you are moving in a right direction with your efforts in Continuous Delivery and DevOps.”
Other key indicators to gauge the overall health of your IT delivery system include production deployment frequency, time from commit to production deployment, and production deployment quality, according to XebiaLabs’ Phillips.
“At the end of the day, adopting DevOps is about speeding and improving the delivery of software updates, and driving toward Continuous Delivery is one of the related goals,” said Ravichandran.
With the definitions and ideas of DevOps and Continuous Delivery becoming more stable, 2016 will be the year these practices cross the chasm and become more mainstream. According to Sage, within the next year we will start to see Fortune 500 companies adopt these practices, and we will see new tools, new solutions and new company ideas.
“If teams aren’t there already, they are sleeping or waiting for their company to fold or they are on their way to getting there. And once they are there, we will start to see communities of practice building on these ideas,” he said.
Approaching a transformation
The benefits of Continuous Delivery and DevOps have already been proven by early adopters; now companies and development teams need to convince the rest of the business to head down this path. BlazeMeter’s Sage believes the transformation starts from the bottom.
According to him, developers hear about the benefits from talking to other developers and can’t necessarily wait for management to get on board. Instead, they will start implementing the practices themselves so they can prove the benefits, making it harder for management to say no.
“If you want to do it on purpose from the top-down, you still have to start it at the bottom,” said Sage.
But without the executive support from the top, you are going to stumble over people who are resistant to change. “Stressing the value of Continuous Delivery to increase the flow of value is great, but means nothing if existing and rigid change-management processes become a major bottleneck,” said CA’s Ravichandran. To avoid this, she says the business should demonstrate the value of every change and reduce its risk.
“DevOps and Continuous Delivery support this by ensuring quality is established early through automated testing and monitoring in the delivery cycle, and that teams are always working on the most valuable elements based on constant feedback from stakeholders,” she said.
XebiaLabs’ Phillips adds that while a bottom-down approach may be beneficial in theory, the lack of control makes it difficult to see the benefits.
“Technical teams that do the bottom-up stuff don’t really care too much about the auditing, traceability, insight, reporting and visibility,” he said. “They want to do it because it is cool, fun and it gives them a level of freedom they didn’t have before. The last thing they want to spend their time [on] is thinking about constraints and audit requirements.”
Microsoft’s Guckenheimer believes a truly successful DevOps/CD transformation needs to be both from the top-down and bottom-up. “You have to have the engineers on the ground, hands-on driving this 24 by 7 by 365, and you have to have the top-down values that are supporting them,” he said. The top-down approach will be able to communicate why this is important and how it is going to make lives better. At the bottom-up, you have to have the continual desire to improve and a continual curiosity and drive to make the business better, he explained.
“If you are missing the top-down piece, then the guys working so hard bottom-up are going to feel unsupportive,” said Guckenheimer. “If you drive it top-down without the bottom-up engineering practice, you are going to stumble all over the silos, play the blame game, and entrench habits and the fear of change.”
Lessons from Microsoft
When Microsoft moved from a traditional software environment to a cloud cadence, the company picked up a few habits they believe are essential for a successful DevOps transformation. According to Microsoft’s Guckenheimer, there are seven habits that form the building blocks of a transformation, and should be looked at even after a transformation to help a business continuously improve.
Seven essentials for a DevOps transformation:
- Team autonomy and enterprise alignment
- Continual, ruthless managing of technical debt
- Focusing on the delivery of value to the customer and the flow of that value
- Hypothesis-driven development
- Being able to gather evidence in production through telemetry
- Life-cycle culture or a product-first mindset
- Treating infrastructure as a flexible resource
