If you have been in the software development space for any amount of time recently, you may have heard the term “DevOps”. There are a ton of new videos, articles, blogs, certificates, training, etc. surrounding this “new” concept. The goal of this post is to explain the different DevOps principles that are out there and solidify these into something you can implement in your teams and businesses today.
What Development Should Be
The first principle supporting the Agile Manifesto was the idea that you should be continuously delivering valuable software to your customer early and often. Delivering your software to a QA environment or staging doesn’t count. The software needs to reach your customers. Why? Because this is how you get feedback to further iterate on your product. If it isn’t in the hands of your customers, then you are blowing it. You are not agile. It doesn’t matter how quickly your development team can turn a set of work items. It is all for naught if you can’t actually deliver your work product.
Now, when the Agile Manifesto was first produced, it was to overcome the silos that were inherent in various organizations. The prevailing paradigm at the time was that the software was designed by one group, developed by another, tested by yet another, and then released by a final group. Overcoming these hand-offs wasn’t easy. In fact, many businesses failed at this primary endeavor. The reasons for the failure is varied, but it ultimately comes down to lack of cultural change (you can see a good example of this with ING featured in this article). People that did development may have adopted an agile framework, but the rest of the business did not. Thus, conflicts, waste, and failure ensued.
Where DevOps Comes into Play
Of the companies that were able to eliminate silos, there was one that still persisted: the wall between development and operations. Typically people developing software create, test, and deploy their software to a Development and QA environment. At some point, the build deploys to production by a different team (generally an operations group). That is where things go off the rails. The hand off between development and operations teams created a break in the feedback loop. The operations team would get feedback from the customer that typically didn’t get back to the development team. Or the deployment of valuable software was delayed or had to be slot in with their operations/release calendar. Moreover, considerations necessary for the production environment known, by the operations team, wasn’t necessarily in the design that was implemented by the development team. This would lead to broken, delayed, or unreleased software.
Any agilist would point out the ridiculousness of the deployment process as it stands within their organization. A core idea of a proper agile team is that you have all the people necessary to deliver a product to a customer. In many “agile” teams, this idea wasn’t extended as far as it could have been taken. The development team only consisted of developers and analysts supporting their work. At no point was an organizational change made so that the development team had control of the build and release pipeline. The idea “you build it, you run it” didn’t get taken to its logical conclusion (or if it was even a consideration). That’s where DevOps comes in to play.
The tough thing about DevOps is that there isn’t a set agreement on what this is or what principles comprise DevOps. Consulting firms, or businesses have their own flavor of what DevOps should be (and typically charge a lot of money for you to implement their version of DevOps). Below are a number of examples from various places regarding DevOps:
They have what is known as the CALMS framework for DevOps. Basically they address Culture, Automation, Lean, Measurement, and Sharing (CALMS). I’m not going to get into each of these principles, but just wanted to highlight a few points. Atlassian, like other companies, know that a key component of business agility is that it must permeate the culture. This is why it is one of the key components of their framework.
Another key component in this framework is the idea of Sharing. Ideally, sharing and collaboration should happen between operations and development teams. This isn’t anything new, but puts less of a burden on hierarchy and more of a burden on the overall culture. Teams need to get away from the turf wars and work more towards a holistic product view.
Like what is outlined by Atlassian, DZone, in their overview, provides the following: Culture, Automation, Monitoring, and Sharing. These core principles are an echo from John Willis, co author of the DevOps Handbook. If you do enough searches, these core principles, with some minor differences, make up DevOps.
In addition to outlining the principles, DevOps also contains the following model:
If you do enough searches, this model comes up quite frequently.
Outside of the principles above, it is important to note that DevOps focuses on Continuous Integration (CI) and Continuous Delivery (CD). DevOps teams leverage software tools and containers to accomplish this.
Shift Left, Leverage Automation, Monitor Quality Metrics Frequently, React to Feedback, Learn From Failures, and Strive for a T-Shaped DevOps Team. These principles, bear a lot of similarity to principles in other agile frameworks and are mainly common-sense to agile practitioners. To get more details on each of principles from this particular firm, go here.
While not actually DevOps, Google implements their framework entitled Site Reliability Engineering (SRE). This practice, developed in the early 2000’s, encompasses many of the principles of DevOps, but is more prescriptive in its work. While I won’t get into all the details, you can read more of it here.
For a definitive study of DevOps and how it improves businesses, you can read a long article from the Harvard Business Review here.
DevOps Simply Stated
So, to simplify things, I’ve developed one principle to rule them all: QUICKLY DELIVER VALUE (QDV).
Lets break this principle down shall we?
Find ways to automate everything you possibly can. Your builds should be automated, your testing should be automated, your source code should be automated and accessible to everyone on the team. If a computer can do it, then let a computer do it. You shouldn’t be manually moving or managing files ever. Let the robots run things. Your organization should be built for efficiency. Meaning, it should be product based, not project based.
Get things in your customers hands. Staging isn’t your customer. If the product owner, or a few key stakeholders only have access to the thing you have built, you haven’t delivered. Delivering isn’t resolving a work item on a Kanban board. Your individual teams should have all the talents, skill, and knowledge to get something of value to the customer.
Your customer determines value. Your customers should be excited to read through your release notes. Or, they should jump at the notification you have that there are new things delivered. They are anxiously waiting for you to make their lives better. This is value. Broken, untested software, isn’t valuable. If your software breaks something in production it’s the antithesis of value. So, change so that you can always release value. This means that you should be talking to your customer continuously. You should have metrics in code, in production, to gauge the value of the feature you are releasing.
For Business Leaders
Quickly Deliver Value is your vision statement. You should be working to support your teams to be centrally focused on your customer and with the intent of delivering something of value. Your industry doesn’t change this objective. Define what you do for your customers, and then iterate on those things. If you consult, your product is your team of people that work for your customers. If you do brick and mortar retail, your product is your store and the experience your customers have interacting with everything inside of it. Your focus shouldn’t be on the bottom-line, but on your customers. As you engage and excite more of your customer base, your bottom-line will take care of itself. You should have metrics in place to gauge the value you are delivering and work to improve that value, and deliver more of it quickly.
Squaring DevOps with Agile
I hinted that the principles and objectives of DevOps isn’t different from what is in the Agile Manifesto. You can read more of my thoughts on DevOps and Agile here. Suffice it to say, that DevOps is another way of ensuring that your business has agility to it from end to end. Just know, going forward, that this particular framework will soon have its own cottage industry of specialists, certifications, and designations associated with it much like Scrum, XP, or any of the other frameworks that implement agile ideas. Does that make it less useful? No, but it tends to sell people less on the idea of talking with one another and more on the idea of tools and process (which will kill your agility). You will be better off just finding better ways to Quickly Deliver Value rather than ensuring you have all the right certifications.