With agile development teams delivering potentially shippable software every few weeks, organizations struggle with the need to efficiently transition requirements, source code, and deployment steps from the development team to the operations team.

Traditional documentation-oriented mechanisms cannot be efficiently kept up to date due to the ever-shifting nature of continuously evolving software. Enter the DevOps movement! This movement recognized that we need to start breaking down the walls between feature development teams and IT operations teams so that we can all work together to continuously deliver this software. Unfortunately, recognizing this was the easy part. It turns out, DevOps is hard.

What we can all agree on

At a high level, everybody will agree on a few things:

1. Knowledge needs to be shared across teams
2. Everybody needs to be involved in the process
3. We should try to use consistent methods for source control, deployment, and issue tracking
4. We need to make sure the existing functionality is not impacted by new functionality or bug fixes

Unfortunately, accomplishing the above is not a simple task. There are tools and processes that can be put into place to track work items, source code, and automate deployments. Test-driven development (TDD), unit tests, test automation, and other testing processes can help ensure quality is kept high. Still, we struggle.

The Hard Part is Perspective

The simple fact is that Development teams and Operations teams are not the same.

The goals and priorities of these teams are different. Often, they are seeing different stages of the application lifecycle. The development team needs to meet client requirements and deliver stable, maintainable, extensible features. Operations needs to get things fixed quickly, answer questions, and keep the lights on. This means that when these teams implement processes and tools, the implementation is biased based on their own needs.

For example, the Development team might set up some great deployment automation to push everything to the development and test environments, but will not have tuned it for Operations’ use in production environments where there may be high availability needs, or backup requirements.

Alternatively, Operations might set up some issue tracking software that helps track production tickets very well but isn’t very useful for tracking and prioritizing user stories and tasks used in a development sprint.

Tough nut to crack

When I speak to a team about how they can improve their DevOps practices to more efficiently deliver and maintain software, I always start with the same mantra: deploy less code more often.

This reduces the risk of each deployment and allows your Development and Operations teams to work in tandem on the same process. If your Development team is deploying to production on the same cycle as the Operations team, you can implement the same work tracking, review, and deployment processes for everyone. It also means the changes are smaller and easier to digest by the Operations team who will need to learn new features and support them. Now, make your Operations team actual members of your Sprint Team and you have a completely embedded DevOps crew working together to keep the software continuously deploying!

This is not a one-size-fits-all solution, however, and each organization needs to look at their own situation. More traditional organizations may have very specific restrictions around the flow of new functionality to production which differs from priority operational fixes to the production environment. Also, development budgets may be project-based and therefore have a different schedule than the operational delivery schedule.

In each case, the challenge is to find a way that works for you to bring everyone together! These steps can help any organization get better right away:

1. Shared Execution: Make the Operations team a part of each Development Sprint in some way (deployments, bug fixes, sprint planning, documentation).
2. Inclusive Planning: Don’t allow Development teams to make decisions that will affect production operation without including the Operations team in the discussion.
3. Audit Trail: Track your release details! (Source code branching, user stories, deployment steps)