Does Your Backlog Break the Value Stream?
Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.
Receive free IIBA updates and exclusive content!
The backlog is a powerful, compelling, and delightfully simple tool for managing work in modern agile organizations because it is the single repository from which a team pulls the next most valuable work item.
But is it “breaking” your value stream, impeding flow, and creating wasteful delay?
If your business thinks of “business” and “technology” as separate terms, then the answer is probably yes—and it has severe economic consequences.
First, let’s start with the basics: the value stream. A key lean tool, the value stream represents the series of steps taken from some trigger event to the delivery of value (or “concept to cash”). Materials and information flow through each value-adding step, enabling us to see bottlenecks impeding flow and creating a delay.
Value stream thinking encourages us to take a systems view and optimize for delivery of outcomes, rather than taking a siloed view and optimizing for perceived local efficiency.
A Simplified Example
A broken value stream occurs when the flow of value is interrupted and delayed due to organizational silos or practices that artificially segment the value stream.This often happens when organizations adopt hybrid waterfall-agile approaches, wherein work is transferred as a large batch of requirements between the business and technology. The backlog becomes a reservoir of requirements for the technology organization, which exploit the rapid learning cycles of agile.
Yet despite the technical teams being agile, the business itself is not. And because the value stream is broken, the business has a long learning cycle and is unresponsive to its customer.
How Backlogs Break the Value Stream
Most agilists love to praise Toyota as an example of a lean enterprise but, up until the mid-1980s, the company was hampered by a broken value stream.In their book Competing Against Time and in a Harvard Business Review article titled “Time—The Next Source of Competitive Advantage,” George Stalk and Thomas Hout tell the story of Toyota’s broken value stream and how it effectively squandered their manufacturing gains.
Until the 1980s, Toyota was organized as both the Toyota Motor Manufacturing Company, which built cars, and the Toyota Motor Sales Company, which sold and distributed cars—i.e., technology and business.
In the late 1970s, the Toyota Motor Manufacturing Company could manufacture a car in less than two days. The Toyota Motor Sales Company’s entrenched bureaucracy, however, squandered this gain, taking nearly a month to process a sales order and deliver a vehicle.
According to Stalk and Hout: “Twenty to thirty percent of the cost of the car – more than it cost to actually manufacture the car – and more than 90% of the time the customer had to wait was consumed by the sales and distribution function” (2003, 68).
We can imagine the frustration this created for Toyota Motor Manufacturing Company industrial engineer Taiichi Ohno, as the whole point of the Toyota Production System he pioneered was to “…reduce the timeline from when the customer gives us an order to the point, we can collect the cash.”
In 1982, frustration finally boiled over and the two companies were merged. Toyota Motor Sales executives and directors were replaced with those trained in lean thinking, while new processes and management information systems supporting those processes were developed.
By 1987, the sales cycle, from order to delivery of the vehicle, was reduced from a month to six days.
The benefit of this time compression was far more than just a cost-saving exercise, as Toyota was now able to exploit fast learning cycles. The company went from selling whatever was on the lot to selling whatever the customer wanted, gaining a massive competitive advantage in the process.
By reducing timelines and embracing change, not only could they turn over units more quickly but they could also command higher margins on sales.
Now, consider how a backlog is usually represented and understood. A typical diagram of the Scrum process contains the “stack of plates” model, often located to the left of the team. It leads us to think of the backlog as a reservoir of requirements for feeding the team, one that serves as a buffer between two disparate processes.
Aligned with this visual representation, many agile methodologies actually encourage us to break the value stream because they assume it begins and ends with the product owner. There is little to no guidance on how the product owner created and prepared the stories in the backlog.
In its worst form, the development team is nothing more than an iterative coding team.
Given this guidance vacuum, is it any wonder that many organizations resort to hybrid agile models?
Conclusion
To tackle this issue, we need to take a page from Toyota and repair our value stream by merging business and technology.We can no longer be satisfied with fast learning cycles in the technology silo—to survive in the digital age, the whole business must exploit fast learning cycles.
We must visualize and manage the turbulent flow of ideas and initiatives within our organization, envisioning the backlog as something more than just a requirements reservoir that feeds a coding team.
If you’re interested in more from Steve Adolph, The Rock Crusher: A Model for Flow-Based Backlog Management, by Steve Adolph, Shane Hastie, and Ryland Leyton, is now available for purchase in the IIBA Bookstore.
About the Author:
Steve Adolph started his career in engineering and building telephone switches and railway signaling systems. Around the late 1990s, he moved into management, where he became interested in the outsized influence that ways of working and organizational culture have on enterprise outcomes.
Steve became interested in agile when he started collaborating with Pattern Language aficionados at the PLoP conferences. Today, he works as an agile coach with cprime, (Canada). Steve has a Ph.D. in electrical and computer engineering and numerous publication credits, including The Rock Crusher, which he co-authored with Shane Hastie and Ryland Leyton, and Patterns for Effective Use Cases. He was also a member of the core team that developed the Agile Extension to the BABOK® Guide, Version 2.
