.png)
In my prior blog post about the different types of teams within DevOps, I identified a significant difference between Operators and Enablers. Operators are those whose day-to-day revolves around resolving tickets without thinking about the why, and their major success metric is the number of tickets they resolve each month.
On the other hand, Enablers are those whose sole objective is to think about how to simplify the lives of development teams by providing security, quality, and speed to the process. Read my related post, "DevOps 2.0: From Operators to Enablers."
Evaluating Kanban vs. Scrum
Given this distinction between Operators and Enablers, I found a significant difference in the types of methodologies each group uses. While this is a discussion related to DevOps, we'll be facing two agile methodologies here: Kanban vs Scrum.
I'm not going to turn this blog post into a comparison of which is better or worse, nor will I delve into what one offers that the other doesn't. This is because I have a fairly structured and well-formed opinion on the matter, based on my experience working in both. Once you decide to be an Enabler, Kanban should not be used as a strategy or methodology.
Let's briefly analyze this. While using Kanban doesn't turn you into an operator, it also doesn't place you into the world of Enablers. Because when using Kanban, you're not constantly thinking about how to improve the lives of development teams.
Instead, over time and as the teams grow, it becomes a bag of things you need to do at some point. The famous "Why?" is often asked, and there are priorities, but two things you really don't have are a solid plan and speed, two fundamental pillars of Enablers.
Now, having made that clarification, how can Scrum help me improve my DevOps practice? This is a very common question, not only from the clients I work with but also during the DevOps interviews I lead.
Transitioning to Scrum in DevOps
When you've been working as an Operator or the upgraded version of Operators with Kanban for many years, transitioning to a Scrum methodology is a significant cultural shift. In my experience, an average engineer takes one to two months to adapt.
Suddenly, you find yourself immersed in a bunch of meetings that are part of the ceremony, such as planning, daily calls, retrospectives, and sprint reviews. The first concern that arises is, "I spend the week in meetings," and that's true. Welcome to the world of Enablers!
A crucial part of an Enabler's work is being consistent in creating a well-structured plan that is open to changes because that's what it means to be Agile!
We're iterating sprint by sprint, and changing direction should be in our DNA because Scrum allows for something wonderful: making changes and getting quick feedback to understand if we're heading in the right direction. Additionally, we add something extremely valuable for our clients, whether internal or external: we add value in a short amount of time!
Years ago, a product was developed for two years, and presented to the client, and if they didn't like it, the team lost two years of work, and the client had spent a lot of money. This doesn't happen anymore, allowing us to provide value repeatedly. This is where one of the myths I deal with comes up: "DevOps doesn't add value in the same way as developing a product."
How DevOps Creates Business Value (Hint: An Agile Approach)
While to some extent it's true that we can't completely compare with creating something visible and tangible for the business in a sprint, it's a myth to say that we can't provide value to the business repeatedly and in short periods.
Let me explain this last point. If a client wants to migrate their entire on-premise platform to the cloud, 90% of DevOps engineers will think of a big-bang vision like this: "I generate all the infrastructure in the cloud, create the pipelines so that this infrastructure is automated, migrate all the services, test them, and decommission the on-premise data center, right?"
Now, let's consider this from an Enabler's point of view. How can I add value to my client every two weeks so that we mitigate the risks of migration, minimize the client's costs for maintaining the on-premise data center and the new cloud infrastructure, and make their new development team more effective?
I can think of several options, but the first thing I would do is ask my client, of all the services you run in your data center, which one gives you the most headaches?
Once I have identified the service, I would create a roadmap for X number of sprints, making sure that in each sprint, I am providing value to my client. For example, perhaps my first service doesn't need a database, so I wouldn't include that in my planning because it wouldn't add value.
But this service does need to be containerized, so in my first sprint, I would have a User Story that says something like, "Containerization of Service X" with an Acceptance Criteria similar to the following: "As an Engineer, I want to containerize Service X, so I can deploy it in multiple environments, including local machines." I would add the following Goal: "The application can run in the local environment and be tested by a developer."
So, within two weeks, I can provide business value to my client: the time savings to a developer for testing their application on the machine or environment they prefer by providing a container for it. Then, the planning could continue with setting up the pipelines to upload this image to a container registry so that it can be consumed by developers from a central location, ending with the set-up of the infrastructure and components that this service needs to function.
Being An Enabler Requires An Understanding of Clients' Needs
As you can see, we go from a big bang mindset to understanding our client's pain points. Based on the pain point that the X service was causing them, we were able to create a short process that would add value to our client from the first weeks of the project.
Being an Enabler requires discipline and planning, but above all, understanding what my clients want, why they want it, and what value I can provide to them quickly and effectively. Without a doubt, in this set of needs, Scrum is our best ally.
I hope you enjoyed the post and stay tuned for the next one! I hope you're having success using Scrum in DevOps teams!
«Being an Enabler requires discipline and planning, but above all, understanding what my clients want, why they want it, and what value I can provide to them quickly and effectively»
