DevOps consists of three different “ways” to implement. The first way focuses on flow, or system level optimization and overall efficiency. The second way prioritizes feedback loops, creating them where necessary, shortening them when possible, and amplifying them so that teams can react more quickly. Finally, the third way emphasizes experimentation and learning, allowing teams to explore different options, and accepting occasional setbacks for the greater good of finding the most ideal methods and processes. Each of these ways has their own benefits and shortcomings.

What is the Second Way?

In every development pipeline, information normally flows “downstream” left to right, from planning and development to operations. Returning information “upstream” right to left is valuable, but often difficult. The second way of DevOps encourages this upstream flow of information, in the form of feedback loops. By creating and improving feedback loops, the second way allows the pipeline and software product to be more reactive, and adjust to changes more quickly.

While it may seem that focusing on feedback loops instead of the product itself could reduce efficiency, the end result of improved processes allows the pipeline to operate more effectively and create features more quickly. In some cases, improving daily work yields more progress than doing the actual work. Optimizing the pipeline, and improving upstream communication, makes the pipeline more efficient and responsive.

Problems with the Second Way

While the Second Way does have many beneficial elements, there are some problems that teams must consider. The day to day process of prioritizing feedback loops could potentially reduce total velocity. Teams might be able to adjust quickly, but could output fewer features in a longer time. Feedback loops alone do not guarantee efficient development pipelines. The Second Way of DevOps risks its main benefit taking precedence over creating working products.

Inconsistencies between environments also stand to inhibit the Second Way DevOps. The freedom to explore options and methods allows teams to create their own unique configurations. Both member workstations and team procedures can vary significantly across a pipeline and organization. These inconsistencies mean that shifting resources and teams can be difficult to incorporate into existing pipelines. Workstations may have to be reconfigured, and team members may take some time to adapt to new procedures. Any given scenario may be best for that particular team, but it can prove difficult to reconcile when resources are redistributed.

The Second Way works better when adapting an existing development pipeline, rather that creating a new pipeline from nothing. Without definite, concrete steps of a pipeline, making some sort of valuable feedback loops is nearly impossible. Teams require some existing pipeline to effectively implement the Second Way methods. Without a logical flow between stages, teams fight an uphill battle in creating and optimizing feedback loops.

Detecting Potential Problems

With the high level of automation in DevOps, metrics are often the best way to find problems. Through the entire development pipeline, teams should search for values that can be measured and might reflect that the pipeline is running as it should, or if some problem has occurred. For each of these values, the teams should determine acceptable ranges. Outside these ranges, there could be problems.

Just because a metric falls outside of its determined range does not mean that there is necessarily a problem. However, when these values do fall outside the acceptable range, it should prompt investigation. A team member is more equipped to determine the reason that a metric is unusual, and if there is a problem. In the case that there is a problem, the team can work together to find a solution, and prevent similar problems in the future. If there is no problem associated with a deviation from the acceptable range, the team may need to adjust what the range is. With enough metrics across all steps of the pipeline, teams have a very granular way to see when problems arise. If problems do come up, the values should show exactly where issues are, and give some clue toward what has gone wrong.