When you build a house, you want to hire specialists. Those specialists have the advantage of focus, specialized tooling, and reduced complexity in order to be great at what they do and build a high quality home. Home building companies then leverage project managers, architects, and designers to coordinate the efforts of those specialists.
When I was finishing my basement, I forgot to design and include HVAC routes for heating and cooling. Now, I was lucky because my basement has in-floor heating so no additional HVAC was really required by zoning. But you can see how not accounting for that critical step would make the space unlivable!
And this kind of gap isn’t uncommon in software development cycles and other infrastructure and operations functions. Development teams get excited about a new feature, invest significant effort into perfecting the code, but then leave documentation, quality assurance, communication and support as afterthoughts. The result is a beautifully crafted piece of software that’s nearly impossible to maintain or support; useless.
In the world of DevOps, this isn’t a theoretical problem but a common pitfall. To truly harness the power of DevOps, developers must embed an operations mindset throughout the entire product development lifecycle.
This article explores how to infuse an operational perspective into development teams – or, in other words, how to put the Ops into DevOps.
Understanding DevOps and the product development lifecycle
Before diving into the specifics, let's clarify what DevOps is and what the product development lifecycle entails.
DevOps is a philosophy and cultural shift to get teams working their best, together. It is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver high-quality software continuously.
The product development lifecycle, on the other hand, encompasses all stages from initial idea conception through design, development, testing, deployment, and maintenance.
The current scenario: gaps in the development process
Let's face it: the typical development process in many organizations is a bit of a rollercoaster ride. It starts with a surge of excitement and ends with a series of jolts and bumps that nobody anticipated. Here's how it usually goes down:
-
Excitement for new features: The team gets a brilliant idea for a new feature. Spirits are high, everyone’s buzzing with enthusiasm, and the creative juices are flowing. The devs dive in headfirst, eager to bring this shiny new feature to life.
-
Perfect development: The developers pour their hearts into the code, obsessing over every detail to ensure the feature is built to perfection. They craft elegant solutions, optimize performance, and polish the UI until it gleams.
-
Neglected documentation: But then, reality kicks in. As the launch deadline looms, documentation starts to feel like an afterthought. The devs figure they’ll “get to it later,” and what you end up with is a smattering of incomplete, rushed, or downright missing documentation.
-
Overlooked QA: Quality assurance often gets the short end of the stick too. With the focus squarely on building the feature, testing sometimes doesn’t get the attention it deserves. Bugs slip through the cracks, and the product’s stability is compromised.
-
Support challenges: Finally, the feature goes live. But what’s supposed to be a triumphant moment quickly turns into a headache for support and operations teams. They’re left scrambling to figure out how this new feature works, dealing with user complaints, and grappling with insufficient documentation.
This scenario underscores a critical issue: development teams need to treat all aspects of their output with the same passion, quality, and investment they give to the initial development phase. It’s not enough to just build something cool; it needs to be sustainable, supportable, and robust.
So, how do we bridge this gap? By embedding an operations mindset into the development process right from the start. Putting the ops into DevOps. This means getting everyone – developers, operations, QA, and support – on the same page, working together seamlessly to ensure that every new feature is not only brilliantly conceived but also flawlessly executed, thoroughly documented, rigorously tested, and easily supported.
Putting the Ops into DevOps: How to embed the operations mindset into development teams
To address this challenge, it is essential to embed the operations mindset into developers. Here are some practical recommendations to achieve this:
1. Involve operations early in the process
Agile teams have demonstrated the benefits of involving operations (support) personnel early in the feature design sessions. By including operations team members in the planning and design phases, developers gain valuable insights into potential operational challenges and can address them proactively.
This collaborative approach ensures that operational considerations are factored into the design from the outset. It’s about having operations (support) people in the feature design sessions, being part of the programming, creating the documentation, talking to their team, and preparing for a smooth and easy service transition.
2. Foster cross-functional teams
Creating cross-functional teams that include members from development, operations, QA, and support can significantly improve the overall process. These teams work together throughout the entire product development lifecycle, ensuring that all perspectives are considered. This approach promotes a shared sense of responsibility and accountability for the product's success.
Don’t forget that including the customer or end-user at this point is also a good idea!
3. Emphasize comprehensive documentation
Documentation should never be an afterthought. Encourage development teams to document their work thoroughly, covering everything from code comments to user manuals.
Comprehensive documentation ensures that support and operations teams have the necessary information to handle any issues that arise post-deployment.
4. Implement continuous integration and continuous deployment (CI/CD) practices
CI/CD practices automate the testing and deployment processes, reducing the likelihood of errors and ensuring that code changes are thoroughly tested before reaching production.
This helps development teams catch issues early and address them promptly, resulting in smoother deployments and fewer operational headaches.
5. Promote a culture of quality assurance
Quality assurance should be an integral part of the development process, not an afterthought. Encourage developers to write and execute automated tests, conduct code reviews, and perform regular testing.
A culture of quality assurance ensures that potential issues are identified and resolved early, reducing the burden on support and operations teams.
Bridging the gap between development and operations
From my years working in the field, I've gathered a few key insights on how to successfully embed the operations mindset into development teams.
At InvGate, we realized early on that involving operations personnel from the start could dramatically improve our outcomes. Here's how it typically played out: when we had a new feature on the drawing board, we'd bring in folks from the operations and support teams right from the get-go. This wasn't just a token gesture; these team members were actively engaged in the design sessions, providing their unique perspectives on potential challenges and requirements.
For example, during the design phase of a major new feature, our operations team pointed out several potential bottlenecks and maintenance issues that we hadn't considered. By addressing these issues early, we were able to refine the design and implementation plans. This made for a smoother transition from development to production. It also meant fewer surprises down the line and a huge reduction in support issues post-launch.
Another critical area where we've made strides is in our approach to documentation. I can't stress enough how often documentation gets relegated to the back burner, seen as a chore rather than an integral part of the development process. We turned this around by integrating documentation into our development workflow.
Every aspect of the feature, from code comments to user manuals, was meticulously documented. We even had a dedicated role in our Agile teams to oversee documentation quality.
This thorough approach paid off enormously. When the feature went live, the support team had all the information they needed to assist users effectively, drastically reducing the turnaround time for resolving issues. This practice improved support efficiency and empowered our operations team to maintain and optimize the feature with ease.
Conclusion
When operations folks are brought in early, when documentation is seen as part of the craft, when QA is treated as essential, we create something greater than the sum of its parts.
Every feature, every line of code, every deployment is a piece of a larger puzzle. By fostering cross-functional teams, prioritizing comprehensive documentation, implementing CI/CD practices, and promoting a culture of quality assurance, we’re doing more than building software; we’re fostering reliability and excellence. This helps everyone.
A holistic approach to software development is a commitment to creating robust, user-friendly products that stand the test of time. So let's keep pushing, keep collaborating, and keep caring about every aspect of our work. Because when we do, we don't just deliver software – we deliver value, stability, and a better experience for all.