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 […]
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.
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.
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.
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.
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!