DevOps/Agile Is Being Applied Incorrectly
When I talk to people about how I’ve adapted DevOps, Agile, and Lean Principles to networking, it’s common to get a negative reaction. Usually the negative response is about how they’ve tried it before and it was either stupid or they generally have a negative opinion of it.
When I ask what they don’t like about it, it usually boils down to one of two things:
- They’ve applied a practice exactly by the book, without making adjustments for their own situation
- They’ve applied a practice, but have adapted it so much that it’s basically their previous practice with a DevOps badge.
Why Does This Happen?
There’s a wide variety of reasons, but the short of it is that Agile isn’t just a set of rules. At its core, Agile is a mindset. The idea that your team isn’t going to get it right the first time. The only plan set in stone is to learn quickly and adapt as you go.
To properly adopt and implement Agile, you and your company needs to adopt the Agile principles and mindset.
This is a lot harder to teach and enforce, so when a company decides they want to be Agile, the quickest and shortest path is to look at Agile companies and copy them. The problem with copying the practices of successful companies, is you can sometimes do everything right and miss the point entirely. If you’ve ever heard of a Cargo Cult, a lot of implementations of Agile are exactly like them. Businesses often adopt these practices EXACTLY by the book, without any consideration for why these practices are done and how it can help in their situation. When imitating others, it’s easy to be in a situation where you don’t receive any benefits from adopting those Agile principles.
What Can Be Done About This?
I really wish there was an easy solution that I could give you guys. The reason why there isn’t one already is because it takes a lot of work to do it right.
We need to pause when things aren’t working, we’re not seeing the benefit, or it seems like a waste of time. It’s important to step back and consider what benefits we should be seeing and why other companies do these things in the first place.
There’s a lot of hidden wisdom behind these practices, otherwise no one would do them in the first place. Once you understand the principles of why these things were done, everything should orient itself naturally. If it doesn’t, it could be that you’re applying a practice that solves a problem that you don’t have.
What A Bad Implementation Looks Like
I’m sure a lot of you are already familiar with what a bad implementation looks like. If you’re not, a common one that gets abused is the daily standup.
By the book, a daily standup is 15 minutes long. Each engineer takes their turn explaining what they’ve done previously, what they plan on doing, and what issues they’re having.
I’ve seen standups run over often, regularly taking 30+ minutes and sometimes being as long as an hour and a half. These daily meetings dragging long can be a drain on both the team’s time and energy. This can happen because the manager wants to go into too much detail, or the team feels like they need to talk longer to prove that they’ve accomplished something.
The worst part of these standups dragging on is that as the engineers get bored of listening to each other and they start to check out and begin working on other things. They lose the benefit of being in the standup altogether.
What A Good Implementation Looks Like
With our team’s standup, 15 minutes is the ceiling for how long they take. We shoot to finish as quickly as possible, and we’re usually done between 4-8 minutes.
Even though the team isn’t always working on something that’s worth letting the rest of the team know about, we just give everyone a high level overview just in case there’s an opportunity for collaboration there.
Sometimes the engineers say it can be a waste of time, but because it’s so quick, there’s hardly an issue. Every now and then, there is an opportunity for collaboration created by the standup and it makes losing those ~5 minutes a day worth it.
How We Got There
We got the standups to this point by keeping in mind what they’re their for in the first place. They’re there just to give the team an opportunity to share what they’re doing and give others a chance to collaborate with them. It’s also a great opportunity for myself as a manager to get a pulse on how my team is doing. There’s times when individuals will seem stressed or bored without them realizing it themselves and that gives me a chance to help them before they realize they need it by either adjusting workload or reassigning resources as needed.
With those focuses in mind, we don’t always run those meetings by the book. A lot of times, we’ll forget to say what we’ve done so far, or we’ll end up doing things that we had not planned or said we would do. It’s not really an issue though, because we usually remember to talk about what’s important and we still get a lot of the benefit of the standup while still saving time from “traditional” standups.
Thank you for checking this out. I hope you learned something new or enjoyed reading this. If you had any comments, questions, or just wanted to share your thoughts on this article, you can contact me at email@example.com
e-Mayhem helps companies successfully deliver business projects. We also help companies avoid losses associated with IT disruptions and security threats. You can learn more about our services at e-mayhem.com or by emailing firstname.lastname@example.org