DevOps is a mashup of “development” and “operations”, but it has become shorthand for a significant culture shift that, if done right, can drive meaningful organizational change.
For as long as developers have been coding software, development and operations teams have worked separately. “Siloed” is the polite term; jealously defended petty fiefdoms describes the structure in at least some organizations. Things started to change when teams began adopting Agile Software Development principles, focussing on collaboration, iteration, and small releases on short timeframes.
Development teams that successfully implemented Agile principles saw the development window for quality software shrink dramatically as code was written, tested, and packaged for release at a previously unheard-of tempo. It wasn’t long before development teams realized they had a problem; caches of new code were piling up instead of being released to customers because the focus had been on enhancing software development processes without corresponding improvement in release or deployment processes.
Operations teams saw the quantum leap in coordination, quality, and velocity within the development teams and realised their own processes were creating a bottleneck. For the organization to thrive, operations teams needed to emulate this collaborative, coordinated approach. While this culture shift did not happen overnight, that which eventually became known as DevOps started to take hold. Development teams began educating operations teams on development processes and the intricacies of producing code, while operations teams educated the development team on release processes and the minutiae of maintaining the infrastructure they were all a part of.
What is DevOps really?
At its heart, DevOps is a suite of practices that seeks to automate and integrate processes and practices from software development and operations for infrastructure teams to build, test, and release software faster and more consistently. While there is no silver bullet when it comes to DevOps, it is a cultural transformation above all else; and that requires people to change. But the good news is that implementing DevOps does not have to be a top-down initiative rolled out by management; teams can start implementing small incremental changes immediately.
Is your company ready for DevOps?
If you want to move your team towards a DevOps culture, you’re in luck; the CALMS framework helps assess an organization’s ability to develop DevOps processes and provides a series of waypoints as a way of measuring progress during a DevOps transformation. Coined by Jez Humble, co-author of The DevOps Handbook, the acronym stands for: Culture, Automation, Lean, Measurement, Sharing.
Culture
Many people who have heard about DevOps think it is all about the tools. It is not. First and foremost, implementing DevOps processes is a culture shift because DevOps is about solving human problems, not technical problems. You can have the worst tools ever, but if you have a great culture, you can still do the work; but if you’ve got a poor culture, you’ll have trouble getting the job done even with the best tools around.
Perhaps the best way to think of DevOps is as a logical extension of agile teams with operations/infrastructure teams included. If building project-based teams is a bridge too far, take baby steps. Invite operations teams to join daily stand-ups, sprint demos, and planning sessions, while key development team members sit in on operations team meetings.
Automation
While tools do not make a culture, automation is a huge part of Agile and DevOps. Automation reduces or eliminates repetitive grunt work, produces replicable processes, and builds reliable systems. To put it another way, if you do not have automation, everything takes too long and there are too many errors because we are all human.
Implementing build/test/deploy/provision automation tools is a great place to start because developers, testers, and operators get to work together building systems that benefit everyone.
Lean
Lean is often shorthand for cutting out low-value activities and moving fast, but when it comes to DevOps, Lean means embracing continuous improvement, embracing failure, and adopting an experimental mindset. Lean sees opportunities for continuous improvement everywhere and accepts that failure is inevitable; if you are not failing occasionally, you are not pushing the envelope hard enough.
Applying this approach can reap huge dividends for SMEs where the founders are still working day-to-day in the business; they’re very invested in the product - there is a culture of, ‘I built this and I don’t want anyone to touch it because I know how it works.’ Those people are very smart, and they do a lot of research, but they often indulge in confirmation bias and are reluctant to change. Implementing a DevOps culture can drive change that is needed because organizations that do not change get left behind.
Measurement
You cannot manage what you cannot measure. It is a cliché with whiskers on it, but it is also true. It is well-nigh impossible to drive continuous improvement without hard data.
Start with the basics:
- Development to deployment time
- Average/median time to failure/recurring bug
- Average/median time from system failure to recovery
- Number of users right now
- Number of users gained/lost this week
Once you have captured this data, it will help you determine else you need to capture.
Sharing
A big part of breaking down the siloes between development and operations teams can be as simple as creating a ‘developer on support’ function - a rotating role where a developer supports the operations team by responding to urgent user-reported issues, creating patches if necessary, and working through the inevitable backlog of customer-reported glitches. Developers learn a great deal about how their application is used ‘in the wild’, and it helps build bonds with the operations team.
Final thoughts
DevOps is not a silver bullet; there is no way to magically change your team into a high performing DevOps team overnight. Making that transformation requires a blend of culture shift plus changes in practices and tools. But after reading this, I’m hoping you can see the change may be worth it. If you do, the CALMS framework is a great start.
