The Three Inspect and Adapt Loops in Scrum

What’s Empirical Process Control and Why Do We Use It?

Defined process control (DPC) methods like waterfall (“plan the work, then work the plan”) are well suited to contexts where our understanding of objectives and methods are likely to remain stable throughout. If we’re building a bridge for cars to cross a river, our understanding of the need, the relevant material science, the geology/geography of the bridge’s endpoints, and even the definition of what ‘bridge’ means is not likely to be radically different at the end of the project from when we started.

But, what about when we’re trying to design a new technology that will disrupt a market or create a whole new one? Product vision, methods, and even definitions of value may shift on a day-by-day basis as we learn more about what’s possible. In situations where there’s potential for the problem domain to rapidly evolve, we are better suited to adopting empirical process control (EPC) methods, rather than DPC ones. What makes Agile frameworks ‘Agile’ is that they’re each rooted in assumptions of EPC.

So what is empirical process control (EPC)? It’s any time we bite off a small part of a plan, execute it, get feedback on the result, and then adapt the remainder of the plan based on what we learn. EPC rests on 3 pillars: transparency, inspection, and adaptation. However, we often shorten the whole mindset as “inspect and adapt” or “an inspect and adapt loop” (transparency being assumed). Agile frameworks differ in how they use and implement inspect and adapt loops, but they all rely on one or more of these loops at their core.

Scrum Formalizes EPC into Three Explicit Loops

One of the reasons that Scrum is my favorite Agile approach for teams that do creative work is because it embeds three different Inspect and adapt loops within the cycle of the framework, with each getting used at least once per sprint. The first loop has to do with our understanding of the current and future state of the product we’re building. The second loop has to do with our understanding of how we will achieve the goal(s) of the current sprint as a team. And the third loop has to do with our understanding of our team’s behavior and process of being a Scrum team.

The Product Inspect and Adapt Loop

At the start of each sprint, a Scrum team negotiates an overarching goal and identifies what items from their product backlog they’ll complete to achieve that goal. At the end of that sprint, they come together to view newly completed product features and reach a shared understanding of the newest production-ready state of the product. Based on that understanding, the team’s Product Owner might alter the future direction of the product by changing remaining items in the Product Backlog or changing their order. Facilitating an effective product inspect and adapt loop is primarily the responsibility of the team’s Product Owner.

The Sprint Inspect and Adapt Loop

At the beginning of each Sprint, the team gathers for a sprint planning meeting to negotiate an over-arching objective for the next iteration (called the “sprint goal”), decide which product backlog items will be built to meet that goal, and decide how they will build each product backlog item by breaking them down in small tasks. Collectively, these elements become the sprint backlog: a visualization of the team’s plan to meet the sprint goal. Throughout the sprint, the Developers self-manage to carry out and, if necessary, adjust the sprint backlog to meet their goal based on what happens throughout the sprint. Facilitating an effective sprint inspect and adapt loop is primarily the responsibility of the team’s Developers.

The Team Inspect and Adapt Loop

At the end of each sprint, before the next sprint planning meeting, the team convenes to hold a Retrospective meeting. This discussion is a formal pause from doing product development work during which we inspect and then experimentally adapt the practices we use to function as a Scrum team and deliver value. Facilitating an effective team inspect and adapt loop is primarily the responsibility of the team’s Scrum Master.
 

There you have it: three separate and distinct empirical process control cycles built in to the Scrum framework, each with its own focus and each the responsibility of a particular Scrum role. Embracing and understanding these cycles is how Scrum teams become high performing, value-creating powerhouses in a relatively short time!

If you want to learn more about how to coach these patterns in individual teams, check out our course offerings in the Scrum Alliance’s ScrumMaster track: Certified ScrumMaster (CSM), Advanced Certified ScrumMaster (A-CSM), and Certified Scrum Professional – ScrumMaster (CSP-SM). To learn more about how to create and sustain a culture where teams can embody EPC as a way of business, check out our Certified Agile Leadership (CAL-E ad CAL-T) training or ask about our enterprise coaching services.