How the OODA Loop Decision-Making Model Drives DevOps Success

DevOps is an infinite cycle of improvement. You gather feedback through frequent testing, continuous monitoring, and user (or QA) bug reports. The goal is to take action based on that feedback to fix problems and improve a product with each iteration and release. The OODA loop decision-making model provides a systematic approach to applying feedback toward continuous improvement in a DevOps environment.

What is the OODA Loop Decision-Making Model?

The OODA loop is a military combat strategy adapted for many other stressful, fast-paced situations, including software development. The OODA loop decision-making model consists of four stages: Observe, Orient, Decide, and Act. The concept aims to break down the decision-making process into small, highly focused steps you can move through quickly and thoughtfully.

Observe. Collect and prioritize information about an incident, such as bug reports, monitoring data, or test results.

Orient. Analyze the observation data without biases to obtain an objective view of the problem and potential solutions.

Decide. Choose and flesh out a course of action that’s flexible, testable, and well-documented.

Act. Act upon the decision you’ve made and collect feedback on the results.

As the name suggests, the OODA loop is a recursive process that you’ll cycle through multiple times until the issue is resolved. You can also use the feedback from one OODA loop to improve the execution of a future OODA loop when a similar issue occurs.

How the OODA Loop Decision-Making Model Drives DevOps Success

DevOps is based on the Agile methodology, which encourages breaking down the software development pipeline into small, iterative steps. This process facilitates easy pivots when requirements change or issues arise, creating a more flexible (and agile) development process. 

The key to this kind of DevOps/Agile approach is shifting left, which means testing code as early and often as possible, often using automation for greater efficiency. This continuous testing increases the feedback frequency, determining what pivots are necessary to improve the next iteration.

The feedback collected from continuous testing typically kicks off the OODA loop decision-making model (see example below). However, as indicated above, feedback may come from monitoring alerts, user bug reports, and other sources.

Let’s look at an example of how one might use the OODA loop decision-making model within a DevOps pipeline.

Stage 1: Observation

A developer attempts to merge changes into the code base, but automated integration tests detect a defect. An incident is created and assigned back to the developer so they can review the test results. The developer may need to collect additional data, such as monitoring logs, but also must find a way to prioritize this information and weed out anything irrelevant.

Stage 2: Orientation

Rather than making a knee-jerk decision based on past experiences with similar problems, the developer attempts to discard their biases to view the issue with an open mind. They may conduct independent research or confer with their team. However, they should do so thoughtfully and without letting strong opinions sway their decision-making process.

Stage 3: Decision

The developer must now decide the best course of action. The ideal solution should be flexible so it can be altered as the situation evolves. It also needs to be testable, so the developer can immediately gather feedback on its efficacy (and potentially kick off another iteration of the OODA loop). Finally, it must be well-documented. That way, they know their actions, how those actions impacted the problem, and how to implement the solution.

Stage 4: Action

The developer puts their plan into action and observes the results. The observation may involve reviewing integration test results, monitoring and testing code as it moves through the pipeline, and collecting user feedback in production. By now, it should be obvious that this observation process is essentially the same as in stage one, meaning the developer is starting a new OODA loop. If all the feedback is positive, then stages 2-4 will progress fairly rapidly until the incident is closed.

DevOps and the OODA loop break down a larger process into small, iterative steps. In a DevOps environment, continuous testing and real-time monitoring ensure a constant flow of feedback, which means issues are caught as fast as possible. The OODA loop decision-making model uses continuous feedback to help teams quickly arrive at and implement an informed, methodical, and iterative action plan. The OODA loop drives DevOps success by providing a decision-making framework that facilitates development agility and constant improvement.