The Scrum Sprint Commitment/Forecast as an Expectation

One of Spear’s key points was that there is no improvement without learning. There is no learning without surprises. There are no surprises without setting expectations. Specifically challenging expectations that will be missed occasionally. See a quote from one of his Harvard Business Review articles about how Toyota really learns:

We argued that Toyota’s much-noted commitment to standardization is not for the purpose of control or even for capturing a best practice, per se. Rather, standardization—or more precisely, the explicit specification of how work is going to be done before it is performed—is coupled with testing work as it is being done. The end result is that gaps between what is expected and what actually occurs become immediately evident. Not only are problems contained, prevented from propagating and compromising someone else’s work, but the gaps between expectations and reality are investigated; a deeper understanding of the product, process, and people is gained; and that understanding is incorporated into a new specification, which becomes a temporary “best practice” until a new problem is discovered.

I got a copy of Spear’s book the High Velocity Edge at LSSC12 and I intend to read it in the upcoming months to try and get more insights into this concept of Expectation-driven learning.

So one way to see the Sprint Forecast is as setting an expectation of how much work is going to be done before it is performed and committing to try working as effectively as we can to try and meet that forecast. Sometimes there will be a gap between our forecast and the real amount of work done, which is an invitation to learn about our real capabilities, our processes and our people and drive new experiments for how to deliver at a higher level. I see this as a healthy use of commitment.

This again explains why a team that meets its forecast each and every time might be a predictable team but not necessarily a hyper-productive team and for sure not a learning team. For learning you need hypothesize that you can stretch yourself a little beyond your current capabilities supported by an experiment for how to achieve that stretch. But hypothesis and experiments have this nature of sometimes succeeding and sometimes failing. So you would expect to sometimes miss your forecast and have to learn something from it. Again, no learning without surprises.

This frame of thinking by the way brings Scrum and Kanban even closer in my perspective. It re-emphasizes how working in a pull system driven by commitment to either WIP Limits or Sprint Forecast are very similar concepts of constraints and expectations - explicit process policies that drive learning. This learning is not less important than the ability to predict delivery outcomes that comes together with working in this pull system.

Scrum Team? Make sure you set challenging sprint forecast, supported by clear hypothesis and experiments of how  you will reach that forecast while still in sustainable pace. Commit to try. Even more importantly commit to learn if the experiment fails. Remember this is a safe-to-fail experiment.

Working with Kanban? Make sure you set challenging WIP limits, supported by clear hypothesis and experiments of how you will sustain this WIP limit while still delivering. Commit to trying. Even more importantly commit to learn if you need to exceed WIP limits. Remember this is a safe-to-fail experiment.

Note the similarity between the two environments! same phrases chosen on purpose.

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.