A few months ago, I was having a coffee with a fellow Agile Coach talking about DevOps when he suddenly says “what is DevOps anyway?”. To which I replied, “You’re right!”. Sounds like a joke? It’s not! In IT projects DevOps is nothing more than pure Agile implemented properly.
While Agile popularity is at its height, DevOps is still very fresh for many.
While it looks like there are some similarities between Agile and DevOps many are wondering what are the differences if there are any. Those we already have some experience with Agile usually recognise some Agile practices and techniques used in DevOps. Not to mention the philosophy which is the same.
Let’s look at some of the terms and concepts from the two approaches which are different. Or maybe they’re not. That’s up to you to judge that.
In terms of benefits, not much of a difference. Both make the same promises: more value for customers, process efficiency (faster time to deliver, reduced costs) and increased team morale.
Agile advocates “early and continuous delivery” (see Agile Manifesto) which means delivery in short iterations and small increments. Scrum uses sprints, Kanban the idea of flow In DevOps, it’s all about continuous…anything.
Continuous development, so functionalities are built without interruptions.
Continuous testing so no waiting time between development and testing.
Continuous integration, so every functionality becomes available for other teams.
Continuous deployment, so all features are made available as soon as possible to the end user. Both will deliver results as soon as possible and then continuously in short cycles and flow. So, in both approaches, you deliver faster, but there’s another benefit. By making functionalities available to your customers faster, you can also be more aware of what you’re building and make some adjustment in time.
Agile approach to requirements is User Stories which means always look at functionalities from the end user perspective and try to uncover value and benefits for those who will ultimately use them.
DevOps is all about optimising flows and cycles, so the value is delivered faster without adding any non-value-adding activities.
The A in CAMS (Culture-Automation-Measure-Share) is how the optimisation is achieved. By automating you deliver faster and because of low or no human intervention also cheaper and more reliable. Both operate on the basis of the value versus waste philosophy so full alignment here.
Agile preaches a mindset-first approach rather than a process-driven one. That’s why the Agile Manifesto is held at high regard and referenced as often as possible.
The Manifesto is a set of values and principles which are meant to create what we call an Agile mindset. Once the team shares the right mindset, then you can talk about methodologies or frameworks. Which in themselves are very lightweight and offer more of a framework than a prescriptive methodology.
The assumption is if you already have an Agile mindset you don’t need a whole lot of processes and rules to able to do your job.
DevOps on the other side insists on the Culture element (part of CAMS). DevOps is just a set of practices and some technologies that need to support a culture of fast delivery, efficiency, and improvements or, as we put it: people over processes over tools.
In Agile, feedback is almost the reason for doing Agile.
Every short iteration of cycle aims at delivering some product increment based on which end user can provide some feedback. This feedback is incorporated and later used to improve the product and deliver more value to customers. This is based on the idea that today it is harder and harder to describe and document at the beginning of the project what end users want.
The other reason is that even if you can describe the product at the beginning, by constantly reviewing the deliverables and the increments you can always come up with ideas of improvement.
Agile is not just about product discovery and improvement. It is also about process improvement. This is the role of retrospectives once the iteration is over. Feedback here is provided about what worked well and what can be maybe done differently in the next iterations.
DevOps add a few things to this.
One thing might be blameless post-mortems where the team looks back and tries to improve. Or continuous monitoring which in addition to making sure the application performs as expected is also used to identify areas of potential improvements. Nothing teaches you about your product quite like watching customers using it.
Agile works best with cross-functional teams where you have all competencies and skills in one team, so you get the commitment, accountability and limit external dependencies. As much as possible the team controls the deliverable end-to-end. Generalising specialists is another attribute which makes the team extremely efficient. It means team members are able and willing to perform other tasks in addition to their day to day job. It becomes very handy when, for some reason, somebody cannot work (or is over-utilised) and a colleague takes over and keeps the delivery flowing with no or very short interruptions.
DevOps used the concept of embedded teams.
In a development team, you have somebody from operations which can contribute to the building of the product. Equally, an operations team has somebody from development for short developments and feedback for sharing some development practices which can be useful in operations (ex. version control, infrastructure as code, etc.).
The S in CAMS (Culture-Automation-Measure-Share) is all about sharing everything with everybody.
It is more a cultural approach to team communications where information becomes available easily for everybody. The information should “radiate” (put it on the walls) and everybody is informed.
Can we even talk about control? Wasn’t Agile supposed to be a no-control environment? Well, no!
If you want to do something right, you’re going to have to keep an eye on evolution and progress. It is not management control but more like peer control or even self-control. In Agile we track velocity which is an indication of how much we can achieve in an iteration.
Moreover, during the iteration, we try to control progress by looking at short term achievements made visible through daily stand-up or a burn-down chart. Lots of other indicators are also available for tracking: cycle time, throughput, WIP limit, number of blockages, bugs, etc.
DevOps looks at measurements (the M in CAMS – Culture-Automation-Measure-Share) very closely because it is only through clear metrics you can control and improve a process. Here we typically look at things like deployment frequency, change lead time or MTTR (Mean time to Realize, Recover, Repair, Remediate).
Obviously, the list can go on and we can identify lots of other concepts or terms which might have different nuances but essentially mean the same thing. And now getting back to the question from the title.
Can we really talk about DevOps without Agile?
Regardless of the name you give it, Agile or DevOps is all about getting better results faster.
By using short cycles, positive mindset, constructive feedback and automation, the results should be relevant for our customers without too much time wasted of activities that do not add value. Hence faster and cheaper.
A rose by any other name…