We pitch the Rock Crusher as a model for flow based backlog management. So what is flow, and why is it important? In other words, why should you care about the Rock Crusher model?
What is Flow?
Flow is one of the 5 Lean principles and means work moves through the value stream smoothly without interruptions, delays, or bottlenecks.
“Make the value-creating steps occur in tight sequence so that the product or service will flow smoothly toward the customer.” – Lean Institute.
Learn more about the Lean Principles here [What is Lean?]
Why is Flow Important?
The fundamental economic assumption of the Rock Crusher is that for an enterprise to succeed in the “age of software,” we must adopt a lean and agile mindset.
Lean – reduce the time from when we receive an order until we deliver value by relentlessly reducing waste.
Agile – sense and respond faster than the rate of change or our competitors.
Without flow, lead times increase, and economic outcomes decrease. The implication of increasing lead times is we are less competitive because our decision making speed is falling behind the rate of change. Decisions and choices are made on obsolete or invalid assumptions.
What problem is the Rock Crusher trying to solve?
The Rock Crusher restores the backlog to its original intended purpose, a tool for active value management. Today, for many enterprises, the backlog has devolved into a passive requirements reservoir with little clarity on what is valuable.
The backlog, as we know it, was introduced as a value management tool. It was the single source of work undertaken by the team. The Product Owner managed value by adding, removing, and re-prioritizing product backlog items. This worked well when the team had direct or near direct connections to their customer, where the value stream truly began and ended with the product owner.
This model was fine when Agile was just an umbrella term for a collection of lightweight team methodologies. However, this model is no longer powerful enough to capture modern agile software/product development reality. How did the Product Owner discover which product backlog items are valuable? What happened to the increment after the Product Owner accepted it?
Most agile methodologies offer little guidance for what happens upstream or downstream from the product owner. Enterprises, like nature, abhor a vacuum and usually cobble together a variety of different methodologies for each functional silo in their value stream. – often based on traditional waterfall methodologies. There is nothing wrong with using a variety of methodologies, however, for value to flow through silos, the backlog cannot become simply a buffering requirements reservoir between those silos.
Disconnected Learning Cycles
Our argument is that beyond a small team with a near direct link to the end customer, our traditional model of backlog management – what we call the stack of plates – breaks the value stream, impedes flow, and becomes not much more than a passive reservoir of requirements. The backlog only serves as a buffer between the different sense and response cycles between product discovery and product delivery.
The whole point of agility is economic gain through fast learning cycles. Many teams use a two-week sprint, which means they have multiple short learning cycles. But the benefit of those learning cycles often stops at the backlog. In many cases, even after a so-called “agile transformation,” we are not getting any more product learning cycles than we had in our former waterfall process because we are still essentially a waterfall organization with disconnected functional silos.
“Delivery Agile” versus Value Management
When the backlog becomes a passive reservoir like this, it disconnects the team from the customer and stakeholders. The team becomes code-centric and obsessed with what Felipe Castro has termed output or “delivery agile” [Felipe Castro OKRs and Agile: Stop Waterfall Goals]. They may have great velocity and even a high SAY/DO ratio. Yet all the customer sees are delays and products that do not satisfy their needs or are even fit for purpose. While each functional silo in this delivery system may satisfy and even improve their KPIs, delays, hand-offs, and slow feedback impede flow across the silos to the customer.
Despite their Lean engineering prowess, even vaunted Toyota suffered massive economic consequences from a broken value stream like this. You can read more about Toyota’s broken value stream in a blog post here [ An Overlooked Lesson from Toyota].
You can learn more about the problems with our traditional model of backlog management in Chapter 1 of The Rock Crusher: A Model for Flow Based Backlog Management.
How Does the Rock Crusher Solve this Problem?
Agile grew up, and now so does our model of backlog management. The Rock Crusher is an integration of patterns of practices we have observed where teams restored the backlog from a passive reservoir of requirements back to a tool for active value management. Value is created when we have flow across the functional silos. The backlog should not be a buffer between silos.
How does the Rock Crusher model enable this? The Rock Crusher is a model for flow based backlog management.
The traditional way we sketch our backlog shows what is essentially a container that is only opened at the top. There cannot be flow through what is essentially a closed pipe. So to create a visual metaphor emphasizing flow we open the backlog at both ends. New ideas pour in from the top and valuable work flows out through the bottom.
Next, we visually acknowledge an organization will have far more ideas and work than it can deliver on. So, we turn our pipe into a funnel.
If we have more ideas than the capacity to deliver, then we need to drain away or discard the excess; otherwise, our system will be overwhelmed and flooded. A flooded system becomes a reservoir again and indicates the inability to determine what is really valuable. The waste gate to paraphrase Michael Porter, highlights how value management is very much about “... deciding what not to do”
Many of us who are familiar with Lean often view flow through a value stream as the smooth transfer of work and knowledge from one step to another. While that may be true for manufacturing, it is certainly not the case for product development. Product development, be it a product for sale, or an internal IT system, is about innovation. Doing something different. If we are not doing something different, then why are we bothering at all? In his seminal book “Product Development Flow” Donald Reinertsen writes:
Value cannot be created without variation
Donald Reinertsen, Product Development Flow
The reality is product development flow is turbulent. We have numerous ideas for features, some big, and some small. They arrive at random times, sometimes in waves. However, our team needs a smooth flow of valuable work. Value management then becomes the process of throttling and stabilizing that turbulent flow. Throttling means evaluating and removing less valuable work. Stabilizing means ranking the remaining work such that the team can pull work with minimum coordination delays and be working on the right things.
Finally, to really shift our mental image away from the backlog as a reservoir of requirements for a team, we have to shift the backlog from the left of the team to the center of the team.
When we draw the backlog to the left of the team, it implies the team is merely a consumer of work from the backlog rather than actively involved in backlog management.
The result Rock Crusher helps restore the backlog as a tool for value management.
