DevOps is not merely about achieving a faster release process. Eventually, DevOps should be about improving the user’s life. Yes, velocity is important. Equally important is utility. What is most important is finding a balance between velocity and utility.
DevOps is largely understood as the mechanism to shorten and speed up software releases. Companies seek quick and stable software releases. They seek rapid release cycles encapsulating the latest code changes. The DevOps approach keeps both the software dev and the IT ops function in congruence and sync.
Ultimately, DevOps must be about the application itself. There is almost an obsession with shortening the release cycle and with automating the process. And sometimes the obsession takes away the focus from the core agenda – The Application. While the DevOps approach allows for better integration between the dev and ops functions and allows for tighter release schedules, it fosters an extremely aggressive schedule of change. And the associated agility and change, while positive for business, can impact customers.
Yes, one of the greatest advantages of DevOps is faster release times. And the high levels of agility and the ability to cope with an aggressive change schedule are reasons organisations adopt DevOps. But there is such a thing as TOO fast when it comes to release schedules, and it is imperative that organisations know where the line must be drawn.
Often, owing to the excessive focus on shortening release cycles and on automating, DevOps teams end up losing focus on the application.
Where must the DevOps team focus?
Your users must remain top of mind when setting the right speed on your DevOps ‘cruise control’.
Does your customer need to test and validate the application before they are deployed into production? If so – be careful of the unnecessary pressure you are placing on the business with your releases. Balance the benefits of quick releases with the customer adoption process.
Organisations must also be wary of making frequent changes and updates that have little to no effect for the customer, as doing so may end up costing your customer valuable resources in the form of time and money. Yes, it is in line with the quick release mantra, but it does very little from a customer adoption point of view.
Communicate. Communicate. Communicate.
Organisations today run on software. They run on software that works well. Customers have protocol in place for software updates since they are such a critical part of the business. Every minor change matters. DevOps teams must consider how a change could impact their customers.They must operate with a user-centric mindset at their core. The key to a user-centric DevOps mindset is communication. Communication is imperative for users to understand the change cycle process. The change cycle must be defined and standardised, not randomised, and anything the business has insufficient time to plan for, may cause them unhelpful pressure.
Creating an update release schedule, that is clearly communicated with the user could be the difference in visualising the balance, or imbalance, of the frequency of updates and changes being provided to the user by the DevOps organisation. Insights can be drawn as to whether the release cycle is too fast to keep up with, or just right.
The Bottom Line
DevOps must be about balance. And the focus of DevOps must be on the customer. Yes, the release cycles are important. And yes, automation of processes is important. But the primary focus must be on the application and ultimately the user.
DevOps is about the business operation first, and the technology operation second.
The user must be first in mind, and the DevOps speed should match the speed of the user, where there is a balance between speed and adoption.
Selena Johnson
Well explained. Thanks