Do You Need DevOps in Your Organization?

The practice of DevOps has been with us for over ten years, and since inception has been surrounded by that exciting mysticism accompanying many agile software development terms and ideas. However, with this fame have come many misconceptions of what to expect when implementing DevOps in software development teams.

In its simplest definition, DevOps offers us the ability to unify software development and software operations. The division of these activities is much more evident in large companies, where there are large workgroups, each with a strict definition of tasks. Collaboration is limited to passing the baton of work from one team to another, many times in a linear way.

These companies leverage a work model based on the concepts where the highly-specialized role of each worker adds value, and the work chain is clearly defined. However, forcing the application of such a model onto software development teams has proven over the years to not work well. A clear example is the reliance on separate departments for analysis and requirements, a single large QA team, and a support area.

Many other practices and ideas that derived from agile software development advocate for a re-integration of the participants in software creation to work with multi-disciplinary teams. DevOps in particular comes to the rescue to resolve the separation that many companies have between software development teams and software operation teams—trying to specialize between those who make the software and those who manage the software.

The Unnecessary Separation Between “Dev” and “Ops”

In a company that separates work between development and operations, development teams are typically responsible for three main objectives:

  • Understanding the business requirements that can be solved through a software application.
  • Programing these software applications using various tools and technologies.
  • Making sure the application that is developed and any subsequent changes meet the requirements and add value to the business.

On the other hand, the operations team is typically in charge of these tasks:

  • Setting up the various development, test and production environments and making sure they operate properly.
  • Providing resources to troubleshoot environments at any time.
  • Releasing different software versions in the corresponding environments, with special attention to versions released to production.
  • Monitoring the performance and operation of released applications and environments.

The operations team also reviews logs and records. This enables them to find risks and prevent or solve problems.

The Challenges of Two Separate Teams

At first glance, this separation of Dev and Ops seems to make sense; it allows both teams to focus on their main activities and not be distracted by the other’s work. Ideally, the development team could increase their productivity—by not having to invest time in the operation of the application and quickly solving the business requirements, one after another.
However, the reality of this situation is that the dynamics of the situation cause both teams to soon develop vices that are derived from the lack of communication and interaction:

  • The development team does not find out about the problems the operations team faces and is therefore unable to provide valuable assistance in solving them.
  • The operations team is not aware of the business value that the software adds and the problems it solves.
  • Release decisions often don’t consider customer needs; the classic example is the operations team releasing software only on a scheduled basis rather than adjusting the schedule according to what customers require.
  • Each team plans in isolation, with its own goals, which may even be contrary; this leads to work being released in larger intervals in order to tie all these goals together.

Beyond all this, the separation of Dev and Ops creates a false separation of responsibilities and even a rivalry between the teams. They don’t collaborate dynamically and quickly to solve problems or to create an agile process that works for both of them.

These challenges led Yhens Wasna and Patrick Debois in 2008 to develop the idea of a more intense collaboration between teams and even eliminate the existing separation. By the following year, the term “DevOps” had gained traction in the community, and their ideas began to permeate the agile software development community around the world.

So… Do You Need DevOps?

In general, if your organization is small—with your development team taking care of everything related to software, and the problems described above are not present—you may already be applying many DevOps concepts. In this case, following a true Agile spirit, you would not seek to complicate something with processes or practices that are not necessary.

But…if your organization is facing the problems mentioned previously, looking at the dynamics that DevOps offers is a great idea. Also consider that DevOps requires an Agile ecosystem at various levels of your organization. The most successful implementations are based on the use of tools that automate much of the work that must be done.

If you have any comments about DevOps, I welcome the opportunity to hear about your experiences. I’m also glad to answer any questions you have about implementing or fine-tuning a DevOps process for your software development team. Feel free to contact me at fponce@tiempodevelopment.com.