Agile and DevOps: Why Are You Keeping Them Separate?
I first heard about agile many years ago. I learned then that the movement started in 2001 when a group of professionals met and created the Agile Manifesto. The manifesto describes a way of developing software faster by focusing more on how to provide value than anything else.
Personally, when I talk about agile, I like to share a video from Uncle Bob about demanding professionalism. Some of his aspirations include inexpensive adaptability and continuous improvement, and he believes we should always be ready to deploy or to deliver software changes. The first time I saw the video, I thought, “Wow, this all sounds great. But how do we achieve everything he expects?” I had an idea of how to pursue some of the goals he mentioned, but for the rest, I had no idea.
That’s because some of Bob’s aspirations require involvement from operations folks. When I was a developer with practically no knowledge about operations, I believed agile was only for development. At least, that’s what I thought until it hit home that my work didn’t stop when I finished my code. Although my definition of “done” was “have the software working in a production environment,” I had always simply focused on how to develop faster.
But what about the moment after? The operations team struggled every time developers were ready to deploy. Was it from a lack of communication between these two teams? Maybe, but that’s how the DevOps movement got started. It came from the desire to break down silos between developers and operations. Maybe we need something more now. Maybe we need to inject agile into this way of working, too.
So why keep DevOps separated from agile? Is it worth it? Wouldn’t there be a bigger benefit if they’re combined? Let’s find out.
DevOps Was Conceived as Agile Infrastructure
The moment developers start adopting agile, operations start receiving requests for deployments every two weeks or less. And we all know that the production environment becomes unhealthy right after we start making changes. It shouldn’t be the case, but it usually happens. I can’t imagine the reactions of the crowd when Flickr announced they were doing 10 deployments a day. But they were able to pull it off by identifying the real problem. When development and operations start to work together, both teams will be aware of all the steps needed to prepare the software for deployment. It’s mainly about communication issues, blockers, and lack of knowledge.
“Agile,” in its shortest definition, means to be able to move quickly and easily. As humans, one of our main problems is interacting with one another in a way that promotes understanding, and this prevents us from moving quickly and easily. The Agile Manifesto starts with individuals and interactions over processes and tools.
What if we added the concepts from agile to the operations world and called it “agile infrastructure”? Well, we might start by immediately applying some of the concepts that succeeded in agile for the software development industry: things like working in small batches and delivering more frequently — -or rather, deploying more frequently. This will help the operations team to pay, little by little, the interest they’ve accumulated through technical debt.
When you don’t do anything to reduce technical debt, you’ll keep feeling the pain of being paged and constantly interrupted during each release. This keeps you stuck in a perpetually stressful, overwhelmed mindset, enabling the excuse of “We don’t have time to implement agile or DevOps now.”
That’s a shame because, with the amount of APIs that have emerged for infrastructure, it’s easier to apply agile practices than ever. As you see, agile isn’t only for software developers.
“Working Software” Doesn’t Stop at Development
Agile was popularized in development organizations. Perhaps that’s why some people relate agile only to development, forgetting about operations. (Well, to be fair, that’s also probably because the Agile Manifesto starts by talking about uncovering new ways of developing software.)
The result is that when developers say they’re done, they’re not really done. They have to wait for operations to install and configure the latest changes in a server, with the chance of getting interrupted if something goes wrong. And most of the time, something does, in fact, go wrong. So one of the first things we need to do is define what “done” means in an organization. This will help to determine who’s involved in the process and what the outcome will be.
Customers will expect to have working software in their hands, not in any previous environment, including the developer’s machine. So we need to include operations in the workflow. And it’s not just that. We should also include security, compliance, databases, management, and everything else that’s involved in the process of getting the working software to customers.
But how can that be achieved? Glad you asked. You can make use of the practices that many of the agile frameworks created, and of course, you can use the practices under the DevOps umbrella.
The Practices, Not the Frameworks or Labels
When you take the approach of thinking about practices, you get the real benefit, because there are a lot of agile frameworks, and sometimes people tend to mix them up.
What about labels or definitions? Oh, you’ll find a dozen definitions of agile and DevOps. So don’t pay too much attention to that. Eventually, you’ll have your own too.
What if instead, we turn our focus to the practices? Practices like TDD, BDD, infrastructure as code (IaC), configuration management, continuous integration (CI), continuous delivery (CD) — -the list goes on. Knowing what they are and why they’re useful makes a remarkable difference in the way you deliver software to your customers.
With agile and DevOps practices, you can reduce lead time and get feedback more rapidly and more frequently. That will let you, as the Agile Manifesto states, respond to a change over following a plan. But it’s not just that. You can also run experiments once you’ve mastered the delivery process. So instead of trying to convince someone else (or even yourself) that agile and DevOps are the coolest, hippest things, focus on mastering the practices. I can’t recommend just one of them, but I can tell you that when I got the “aha” moment by practicing them, I couldn’t go back. It made me say, “If only I’d have known this before.”
In the end, it won’t matter too much which practice you choose. What matters is if your performance increases or not. And using practices of both worlds will definitely help you.
Combined, They’re Stronger
Are you still going to keep agile and DevOps separate? You could. But there’s a lot of synergy between these two. The IT industry started to change constantly after agile, for the good and the bad. Unfortunately, now we have a lot of frameworks, labels, and definitions around agile. But we also have a ton of practices with the spirit of being able to move quickly and easily. Customers expect value, and they don’t care what you did to provide it to them — -they only care when something goes wrong.
So, you start in development with good technical practices to get the software ready for delivery. Then, you continue with DevOps, which helps everyone to have a broader picture of what’s needed to take software from “ready” to “working software in the hands of your customers.” DevOps is about all the people that are immersed in the process of software development, not just developers and operations. And DevOps acts as the reminder that software development doesn’t stop when a developer has finished coding, even if all tests passed. All that learning development has acquired through the years about agile is valuable, and it’s applicable to infrastructure nowadays.
It’s important to focus more attention and effort on the practices of agile and DevOps. When you succeed in this, the name of the movement becomes less important.
Originally published at https://aspetraining.com/resources/blog/agile-and-devops-together.
