I truly intended on finishing this post weeks ago as a continuation of my last post, Defining DevOps. Instead, I’ve rewritten it several times refining the mental model of how to implement DevOps. Let’s take an abstract journey together to discuss who should implement DevOps, how to organize for DevOps success, and how this shift impacts team members.
Who needs DevOps?
If you’re developing software in a professional setting, you need some form of DevOps. It improves process efficiency and reliability, creates a tighter feedback loop between team members and users, and deliver consistently and often. Ultimately, it translates to fewer bugs, better user experience, and delighted users.
How to organize?
In my opinion, “how” is the most confusing and challenging part of the DevOps movement. Most development organizations are doing DevOps in one form or another. The thing that makes DevOps noteworthy is it’s not just about process. It’s also about how we organize ourselves within a team and how organizations change the way they think about resource management.
Traditionally, software delivery teams are organized like an assembly line. Jane builds a widget then hands it off to Chris to check for defects who hands it off to Isabelle to deliver to the customer. When applied to software development people are sorted into three groups, development, quality assurance, and operations. Over time we’ve learned this separation is a hindrance, not an efficiency. I’d love to get into a philosophical debate on resource management in IT but it’s a topic better left for another time.
It’s time we blur the lines between these groups and view teams as a group of Engineers. This has been made possible by recent advancements in the industry. Infrastructure has moved to the cloud making hardware procurement trivial. We now have tools like AWS Cloud Formation and Terraform to create and manage infrastructure as code. Automation tools have become more consistent, reliable, and generic by utilizing common programming languages. And we can write automated tests side-by-side while developing the application which can run on our local development machines before committing changes to source control.
We can manage all aspects of software development as code and follow Software Engineering best practices in every aspect of development. The lines are already blurred. Combined with Agile Methodologies, the definition of a T shaped developer is broader than ever before. Many of us have spent years gaining a deep knowledge of our favorite platform, framework, or language but now we can share our knowledge with our teammates to build a stronger, faster, more resilient team.
What does it mean for …
You might think I’m completely wrong, full of it, and have no idea how software development works. You might be right, but before you make your final judgment lets address burning questions, “What does this mean for me?” and “How am I going to keep my job if everyone on my team can do everything I can do?”
SysAdmins, Infrastructure Engineers, Operations Engineers
You’ve been implementing infrastructure, monitoring systems, and resolving production bugs forever! You’re completely indispensable but it’s not fair you’re on the hook to resolve production outages. Most likely you don’t have enough context to effectively debug every outage, especially in the middle of the night. Most of all, you have amazing ideas to improve the application, server, and infrastructure resilience to prevent calls in the middle of the night. You’ve probably struggled to get the development team to buy into those changes since they don’t experience the pain. The shift toward DevOps Engineering is an opportunity to train your teammates on the skills needed to perform infrastructure or operations related activities. It’s also an opportunity to share the painful responsibilities of the role.
As an Engineer, indistinguishable from any other engineer, you’re going to have to learn new skills and programming languages so you can deliver product features like every engineer on your team. You will need to teach your team how to build infrastructure, what each piece does, why it’s important, and how to make it resilient. Embrace the opportunity, you will become more valuable than before.
Quality Engineers
You’re the unsung heroes of the entire development lifecycle. You exercise the application in search of inconsistent behavior and write code to automate repeatable tasks. Sadly, most people outside QE consider your skills easy to learn and trivial. This couldn’t be further from the truth. You’re talented software engineers and problem solvers who look at a problem from a different angle.
The shift to DevOps is an opportunity to become more valuable. You will also need to learn new skills and programming languages, build product features, and manage infrastructure. Most importantly, you need to teach your team how to effectively test the application and write automated tests.
Software Engineers/Developers
If you’re anything like me, you’re eager to learn something new. Automation testing, cloud infrastructure, and configuration management are just a few things to make you a well-rounded engineer. You are empowered to make changes to the server and write automated end-to-end tests. You will work closely with your quality and operation teammates to improve the feedback loop to find bugs, identify edge cases, deploy, and succeed faster.
C-Level Executives or Decision Makers
This is where the rubber hits the road! Decision Makers, remove artificial barriers between resources. A happy and delighted user is the most valuable outcome for your organization because it means they will advocate your product and lead to increased sales. Make your customers happy by delivering bug fixes and features faster. Deliver faster by removing barriers.
Lastly, shift your focus from utilization to delivery. Don’t worry about if a team is busy. Busy is not the same thing as delivery. Empower teams to do whatever they need to deliver what they have committed.
Final Thoughts
Alright, I said a lot of stuff here. DevOps is a huge buzzword in the industry today. Fortunately, it has a lot of merits. By removing artificial barriers between team members you can shift from a code factory to an efficient software delivery team. Each team member adds a deep technical skill necessary to deliver. Through cross training, the team will grow into T shape engineers capable of delivering in any situation. Waiting for Development, QE or Operations to make progress will be a memory of the past.
Related Posts
October 23, 2017
Defining DevOps
February 27, 2017
Backup Strategy
July 13, 2015
SlowCheetah In VS 2015 RC
May 11, 2015
A Letter to Young Developers
October 27, 2014
OAuth 2 Flows
August 25, 2014
TeamCity Dependencies
March 3, 2014
WordPress Theme Tips
February 5, 2014
Creating a TeamCity Project
November 23, 2013
Development Tools
November 20, 2013
TeamCity, Git, and Assembly Version Number
September 6, 2012