Why Do We Do DevOps?

A few year ago, when I started leading my first teams as a TPM, I noticed a trend where I often got major pushback from my team when asked to implement some of the DevOps best practices. 

 “I am a developer - I will not do a tester’s job!” 

“There has always been an IT team to manage the deployments, why must I do it now?  

“Do I have carry a pager?!!” 

Does this scenario seem familiar to you? This was a persistent challenge I face often across all projects. The frequency of this pushback has put me in a place where I feel it is time to have a deeper discussion around DevOps - why do we do it and the importance it brings to our team and our customers.   

 DevOps is about understanding that we can treat creating software just as any other industry. It’s about being able to take some of the innovations in Lean Manufacturing and applying them to software delivery. The principals of DevOps help us visualise the flow of work, commoditise feedback and learn as a team and organization. In fact, the principles of Flow, Feedback and Learning are the 3 Ways of DevOps as expounded in The DevOps Handbook. I've also found The Phoenix Project extremely helpful in understanding how the principles of Lean Manufacturing can be applied to the software development.

To start us off, let us consider why do we have a Sprint Board? 

Wait a minute, a Sprint Board is Agile not DevOps, right? As it turns out, having a Sprint Board helps us implement one of the absolute fundamental principle in DevOps – “making our WORK VISIBLE”.  Technology work is more or less invisible, there isn’t a car to show at the end of the assembly line! This can often be a cause of friction between engineers and non-engineers – who wonder why something take so long if it’s just a few lines of code! Or at times, after a few sprints of hard graft, most developers feel like they have nothing to demo!! 

Putting our work on a Sprint Board, helps us see where work is flowing well and where work is queued or stalled. We can manage our work so that it flows from left to right, i.e., from Dev to Ops or from Business Requirements to Customer, as quickly as possible. When we have a predictable flow of work, we establish a VALUE STREAM that delivers value to the customer. 

 Have you considered why we do automated testing as we check in our code? 

DevOps tells us that to create a SAFER and MORE RESILIENT value stream, we must SEE THE PROBLEMS AS THEY OCCUR. This gives us a short feedback loop, and PUSHES QUALITY CLOSER TO SOURCE. Imagine if we were building a car. If there weren’t any procedures in place to detect problems during the assembly process, and, if we only tested if a car worked when it was fully built, a lot of cars would have to be towed off the assembly line!  

I hope that as we start asking these questions and exploring the principles behind DevOps, we understand the ‘why’ along with the ‘how’ and it makes us better at implementing the day to day processes we have come to hold dear. 

 How have you dealt with a situation where you received pushback from your team for adopting DevOps practices? I'd love to hear how you addressed that situation and motivated your team to use DevOps?