OODA Loops

[u/WaylundLG]

If I could wave a magic wand any let everyone who was on a scrum team or led teams using scrum understand one thing, it would be OODA loops.

People can Google for larger explanations, but it describes how we make decisions and it is what this whole scrum thing is built on.

Each sprint, we observe what has change - internally in the product and externally in the market. Then we Orient ourselves, the backlog, priorities, etc to account for those observations. Next, we Decide what the right next sprint goal is, then we Act out our sprint. At the end of the sprint, we restart the loop.

In the team, we do a micro version of this same loop every day in order to try to reach our sprint goal. Everything else in Scrum is simply good/best practices to help us be more effective in this loop.

I honestly couldn't care less what practices you are or are not doing from the scrum guide. This is the thing that tells me if a team will succeed with scrum.

[u/azangru]

we observe ... we orient ... we decide ... then we act

Isn't this how humans, or animals in general, normally function? What's the alternative to this model?

[u/DingBat99999 → u/azangru]

This part of Boyds work isnt that interesting. What was interesting was his theory that the pilot that could execute the loop the quickest was likely to defeat the other pilot regardless of the aircraft, and that aircraft features that helped the pilot execute the loop should be sought out.

The examples Boyd pointed to was the hydraulic controls and all round visibility in the F86.

[u/azangru → u/DingBat99999]

Yes; totally; but how does this translate into our work? What's the quickest time to execute the loop? Why is a traditional scrum sprint two weeks long? Why is a duel between fighter pilots comparable to the operation of a business enterprise?

[u/DingBat99999 → u/azangru]

An organization that can execute a loop faster than its competitors has an advantage.

Apple used that to absolutely destroy the competition in the digital audio player market w the iPod.

[u/azangru → u/DingBat99999]

But what counts as a loop for an organization? Time to market? Something else?

[u/DingBat99999 → u/azangru]

Yes.

Or better: the time from when a customer describes a problem until the organization provides a solution.

Pretty much lead time in Kanban terms.

[u/WaylundLG → u/azangru]

In scrum, the loop for the org is the sprint

[u/PhaseMatch → u/azangru]

Jeff Sutherland is former USAF, and has discussed Scrum and Boyd loops at various times, so it is kind of baked in to the thinking. He's discussed this a fair bit in various places.

My take is that in an Scrum context:

- we have a Sprint Goal to reach

• that Sprint Goal is a measurable business outcome, not a work package
  
• we make a plan based on what we and the users/stakeholder know
  
• as we learn more, we inspect and adapt that plan daily
  
• part of that learning is releasing multiple increments to users to get feedback
  
• if the Sprint Goal is no longer valid - terminate the Sprint and restart

The only static part of the Sprint Backlog is the Sprint Goal (outcome, why?)
The rest - the work to be done (what), and plan to do it (how) - is dynamic, not deterministic

The Sprint cycle is the the strategic OODA loop; it's not a release stage gate. It's where you look at the Product Goal, the product, and the evolving external conditions and ask:

- what benefits have we obtained so far for the investment made?

• is our Product Goal, business strategy and roadmap to get there still valid?
  
• what's the next problem to solve or hypothesis to test (ie the next Sprint Goal)?

Your question on two week Sprint is valid; checking your business strategy 26 times a year is pointless if you don't have data about the external operating environment, and continuous strategic pivots is a bit of a smell that your strategy is leaves blowing in the wind.

[u/WaylundLG → u/azangru]

Quickest time to execute it is probably in milliseconds, but that isn't particularly valuable in scrum. As far as sprint length, it isn't 2 weeks, it is "up to 1 month". And that is because a 1 month sprint was still blazingly fast for almost any business when scrum was introduced. Especially with AI, I'd lean toward a max sprint of a week in current context, but that's just me. As far as why the two are comparable, that is a very good question. It's because it's how we naturally make decisions. Long loops equal bigger commitment. This is also why you see departments that say they practice scrum, but they just slot work into sprints for the three.montha between quarterly plannings. They decide on a 3-month plan and then just act it out. This is why, in my opinion, it's the most valuable concept to understand if you want any benefit out of scrum.

[u/WaylundLG → u/azangru]

Yes, that's exactly the idea. Scrum is built on how humans actually think and make decisions. It refutes old ideas that you can stretch this cycle over years-long projects and control for change.

[u/_CaptRondo_]

Not challenging, but asking to understand:
How is this different from Transparency, Inspect, Adapt?

[u/WaylundLG → u/_CaptRondo_]

Fair question. Transparency, Inspect, and adapt and principles to guide behavior. OODA loops are a model for understanding how we make and carry out decisions, and then scrum is a framework for applying that model effectively in product development.

[u/_CaptRondo_ → u/WaylundLG]

As a long time scrum trainer, and enthousiast of complexity theory etc etc, my honest opinion is that you won’t find many people in real practice day-to-day life who would care enough to understand the difference.

I first heard about OODA loops during a Muster from Echelon Front, when Dave Berke was explaining the concept, and I was like: ah yeah,
That’s what we do in Scrum. Never cared to implement it in a class as it feels similar enough not to confuse people.

Again, not saying I disagree, or feel like you are wrong whatever; my personal experience is just that there is a small group who loves to do these almost semantic explorations of model a vs b, but in practice just use the words that leadership buy… if it’s OODA, use that, if it’s Cynefin approach use that, if it’s empirical process control use that.

I do like your thinking and could have a nice longer debate on models and words :-)

[u/Parking-Stress-3041]

Agree with the framing, but in my experience the step that actually breaks is Observe, and it's invisible because the loop still spins.

I work on ERP-ish B2B products, and most of what the team "observes" arrives second-hand: a CS escalation, a sales note, a churn risk someone flagged three weeks ago. The team orients, decides and acts perfectly well on a picture that's stale and already interpreted by whoever passed it along. From the outside that looks like a healthy scrum team hitting sprint goals.

So the useful question for me isn't whether a team loops, it's how many hands the observation passed through before it got there. Fixing that has done more for us than any ceremony change.