What would it be like to deploy an enhancement to a solution in production in less than a minute? Additionally, wouldn’t it be great if you were to deploy to production with confidence that nothing would break? Finally, what if all you had to do to make a major deployment was to push a button with no resulting interruption in service to your customers? It would be awesome to be honest. And, quite frankly, it would be a supreme example of agility. That’s the goal of DevOps, but honestly, that is one of the tenants of Agile principles.
From zero to hero
There are plenty of stories where software development teams went to an environment of chaos to something of order. Deployments went from an all manual process to something streamlined. Instead of a developer working on moving files from one server to the next over the course of four hours late at night, they went to a seamless push to production during business hours on low traffic times. I’ve seen it in different efforts that I’ve consulted on, and if you’ve been in software development for a good bit of time, you’ve probably seen it too.
This is what people are striving for when they mention the term DevOps. It is, essentially, making the deployment and operations considerations a part of the development effort of the solution. In DevOps, we take into account deployment, operations, and scalability concerns at the onset of development. Taking these concerns into consideration is what makes a difference between an IT shop that is a mess and an IT shop that brings value to the overall business.
Where the confusion sets in
Now, it is true that the Agile Manifesto was written in a time when work was still divided between development and operations/deployment efforts. Because of this fact, people say that including operation concerns in development was missed. To bolster that argument, people point to various “agile” IT shops that create a product then pass it off to the deployment team.
In those scenarios, the definition of done was taken to mean that user stories were coded, unit tested, and deployable. Solutions were packaged iteration by iteration and thrown “over the fence” to the deployment team where they had to figure out how to best run and deploy the solution in a live environment. Seeing these examples, people have made the conclusion that the agile frameworks were flawed.
The frameworks didn’t take into account the full life cycle of an application, which would include the operation and maintenance of a solution. Thus, eliminating this transfer was a primary objective to DevOps and fills the gap missed by “Agile”.
The scenarios are true, but the conclusion is wrong as well as the underlying assumption that creates the conclusion. The assumption that a development team is practicing agile as outlined above is wrong. Just because you are “following” a certain framework doesn’t mean that you are actually agile or that you are following a framework’s guidance correctly.
This shouldn’t be new
One of the key principles outlined by the founders of the agile manifesto was that teams should strive for early and continuous delivery of software. In fact, this is the first principle advocated by the writers of the manifesto. If you don’t believe me, read it here. It has been reported that the only order that matters in the agile principles was principle 1 and 12. Everything else can vary by company and it’s value to the team or business. Meaning, if nothing else, your priority should be the early and continuous delivery of valuable software. The deployment team is not your customer. If your customers aren’t seeing your software after it an iteration, you are missing the point of agile development.
An agilist’s take on DevOps
I have to admit, when I first heard of DevOps, I was a bit confused. The main reason for the confusion was that our development teams were responsible for development and release, maintenance, and support. Our team consisted of full cycle developers, as is advocated by tech titans like Netflix. Our backlog contained user stories as well as architecture stories meant to cover the building out of automation pipelines, server deployments and configurations, and application logging and measurements. Anything you need in a solution, from ideation to operation, exists as skill sets within the team.
So, when DevOps came into play, I failed to see the point. And, perhaps, some of the new agilists on the scene have had the same experience. Their education into what agile means encompasses the principles covered by DevOps. In my, and many other’s view, DevOps with agile development practices is the full realization of the original vision in the Agile Manifesto.
When you combine Agile and DevOps you get software’s Super Saiyan Form. So, take the principles learned in agile frameworks, apply the additional principles in DevOps, and you will find yourself with more opportunity, agility, and satisfaction.
What this means for you
The true development team has everything it needs to deliver a shippable product increment.
You can find that definition within the Scrum Guide. That means, that you should have someone that knows about servers, deployments, monitoring, and other operations concerns. If you don’t, you are not falling within the guidelines of a team. If you have that shortage, but have a deployment team, pull in someone from that team. Have that person work with you side by side. Break down those barriers and insist on a team that consists of breadth and depth over all the things. If you don’t have a deployment team, guess what? You get to educate yourself on DevOps tooling and practices. It’s your time to build that depth of knowledge and bring a greater breadth of skills to your team. It may be some upfront pain, but the payoff’s in business agility is worth it.
I hope this helps you better understand how agile frameworks and DevOps work together. Go forth and break down those barriers. Recruit a true team. Deliver results faster, better, and find value in the journey.
Thanks for reading.
Being > Doing
David Bjarnson
One Comment