In this blog post, I propose that it’s necessary to take a step back every 2-4 months and re-evaluate the backlog, because Scrum’s incrementalism is prone to missing macro business, competitive and/or technical changes endemic in software. To address this need, I introduce a framework for systematically overhauling the backlog, Scrum’s Outer Loop™ (see Figure 1).
CONTEXT: THE PRODUCT MANAGEMENT GAP BETWEEN SCRUM.ORG AND SAFE
Two of the most popular approaches to agile are both Scrum frameworks: one popularized by Scrum.org and the other by SAFe. Scrum.org is typically used for smaller projects or organizations, while SAFe (Scaled Agile Framework) is typically used in large organizations. Both are effective for engineering delivery, with good mechanisms to prioritize stories (requirements) and iteratively deliver value through software on a steady heartbeat (sprints).
But how is value defined? We define value unambiguously as “solving a critical problem for target users to achieve well-defined business goals (desired outcomes), as measured by specific success metrics”. For the purpose of this discussion, I define product management as the set of activities that uncover and define what is valuable. Furthermore, I propose that the product backlog is the yet-to-be realized articulation of this value. Therefore, an essential activity to delivering value in software is incorporating product management outputs as inputs into Scrum’s delivery engine.
For mid-sized firms, in particular, Scrum.org offers no systematic approach for integrating Product Management outputs into Scrum, while SAFe’s framework is overly complex (see Figure 2: SAFe 6.0 “Essentials” – this is the simplified version).
In a nutshell, Scrum is good at delivering quality software. But it’s not necessarily good at delivering value on its own.
INTRODUCING SCRUM’S OUTER LOOP™ BY FORTE
So, between these two extremes, Forte has developed a lightweight framework to systematically integrate product management into Scrum iterations. We call it Scrum’s Outer LoopTM. It’s necessarily straightforward and adaptable, and it’s fairly easily described: imagine a periodic discovery and planning sprint, and you’re in the right frame of mind.
Scrum’s Outer Loop TM is depicted in Figure 1.
Figure 1. Scrum’s Outer Loop™, by Forte
So what is Scrum’s Outer Loop? Well, Scrum is a series of engineering delivery activities to efficiently deliver software. Scrum’s Outer Loop is a complementary series of product management activities to efficiently and periodically scrutinize the product backlog, and update it as needed. Why does the product backlog need to be scrutinized periodically (and perhaps overhauled)? Because the value assumptions built into your Scrum team’s current product backlog change more significantly over time than the incrementalism of Scrum can handle. Consider the likelihood that any one of the following occurs over the course of, (let’s say) 2 to 4 months: significant market change, competitor move, significant technological change, new business opportunity, disruptive user feedback or a disruptive idea from within the team. The biggest Achilles heel of Scrum is not seeing changes in the forest because we’re focusing on one or two trees at a time.
.png?width=1110&height=612&name=image%20(1).png)
Figure 2. SAFe 6.0 “Essential” – this is the simplified version, which is overly complex for any but the largest organizations, in the author’s opinion (source: https://scaledagileframework.com/#)
PERIODIC BACKLOG OVERHAUL IS NEEDED TO AVOID SCRUM-FALL
One of the primary benefits of Scrum (vs. waterfall) is that valuable software is released in smaller increments, more often, to deliver value to the market quicker. When everything works as planned, the most important items are delivered first, and value is added incrementally along the way. When compared to waterfall, value is front-loaded, and the value-over-time curve is depicted in Figure 3. Scrum vs. Waterfall, value over time.
.png?width=533&height=300&name=image%20(2).png)
Figure 3. Scrum vs. Waterfall, value over time
What happens all too often is that the team does not adequately step back and evaluate the market feedback after software release. This leads to “Scrum-fall” (see Figure 4. Scrum-fall), where the team releases (presumably) valuable software, but does not explicitly re-evaluate the core value assumptions from the beginning of the project. So the team misses the feedback loop.
.png?width=533&height=300&name=image%20(3).png)
Figure 4. Scrum-fall is when value is delivered often, but the drivers of value (including market feedback) are not re-evaluated on a regular basis
In the ideal case, Scrum enables the team to capture the 80% value from the most important 20% of delivered software – solving the most important problems first, with the minimum viable software increment (MVI, if the world needs another “MVx”). It then moves on to solving the next most important problem, rather than keep solving the first problem. It is typically depicted as shown in Figure 5. Optimal value-capture with Scrum.
-1.png?width=532&height=300&name=image%20(4)-1.png)
Figure 5: Optimal value-capture with Scrum (vs. waterfall), where the drivers of value are re-evaluated and the product backlog is overhauled accordingly
THE PROBLEMS THAT SCRUM’S OUTER LOOP SOLVE INCLUDE:
- Not looking at the forest for the trees (i.e., focusing strictly on the next sprint, without systematically taking a step back)
- Poor mechanisms for integrating empirical evidence back into the product roadmap
- Or the opposite problem: long, drawn out planning processes that cause serious disruption to the Scrum team’s delivery momentum
Doesn’t SAFe solve this forest-for-the-trees problem? If executed well, perhaps. The challenge that we’ve seen with SAFe is that it requires a lot of overhead. Again, SAFe is for large enterprises. Rather than a kitchen sink approach like SAFe, we think of surgery: a host of product management tools at our disposal and we surgically use the appropriate one(s) for the situation.
So, Scrum’s Outer Loop serves as a mechanism to “operate” on the product backlog on a periodic basis, surgically focusing on defining the next big problem to solve. It’s also flexible enough to use on an ad hoc basis. When done well – and if resources are available (including product owner/ manager capacity) – the “product management” activities are happening in parallel with delivery.
Scrum’s Outer Loop is an efficient mechanism to inject into the Scrum team the output from these product management activities. These activities include evaluating sales and the market, looking at customer usage data, executing UX research, evaluating competitive moves and new technologies, input from customer advisory boards, and more.
The tricky part is that, unlike Scrum delivery, the specific product management activities (we call them our product management toolkit) can vary greatly, depending upon the primary driver of change over a given period of time. And the best part is that it’s lightweight and flexible enough to cause minimal “discovery and planning” impact on your Scrum team’s delivery, though there will be some.
This framework is best suited for mid-sized firms. It might not be appropriate for large enterprises, for which SAFe may work well. It also may not work for those super-nimble software firms who have your agile processes wired: you have Lean UX (or other) systems in place to deliver quickly, obtain systematic feedback and iterate quickly.
Agile is a proven best practice to deliver software. In an outsourced environment, the Scrum framework is effective. The problem is not building quality software efficiently, it’s identifying the most important problem(s) to solve, and overhauling the product backlog when the most important problem to solve changes significantly, as it is wont to do every 2-4 months or so.
