I was recently asked by an IIBA® chapter to give a presentation, and when it came to topics, I suggested “The Rock Crusher,” the organization’s latest publication that focuses on a flow-based approach to product backlog management. I knew that choosing this topic would force me to read the book. Now that I have read it, digested it, and extracted the essence for my presentation, I want to reflect on what I learned and share it with you.
As anyone who knows me knows, I am a huge proponent of agile ways of working, and Scrum is (of course) my favorite of all the flavors. That said, there are a few problems and gaps that I (and others) have struggled with over the years, and the IIBA®‘s new process is intriguing to me, as it seems to address some of these issues.
Here are the problems that (I think) The Rock Crusher does a great job of dealing with:
- The overwhelming (and unrealistic) role and expectations of a single Product Owner
- Broken value chains
- The inability to see the “big picture” of a product
- How work enters and exits the product backlog (aka the intake process)
- Hidden work by way of the business analysis work that necessarily precedes “ready” stories landing in a Sprint Backlog
There are probably a few other issues, but these are the first ones that jumped into my mind.
While I don’t necessarily buy every aspect of The Rock Crusher analogy, which is a metaphor for mining, I think it tackles some of these problems pretty well.
Let’s see how.
The overwhelming (and unrealistic) role and expectations of a single Product Owner
This first one immediately challenges one of the key roles on any agile team: The Product Owner (or equivalent title for other agile frameworks). The expectation is that this is one single person who is responsible for all things related to the product, including:
- Knowing the competitive landscape
- Being a Subject Matter Expert (SME) on the product
- Understanding the industry and market
- Being the voice of the customer
- Working with stakeholders and customers to determine how to grow the product
- Making decisions about the value and priorities of product requests
- Maximizing the value and return on investment of the product
- Etc., etc., etc.
I could literally go on for hours, but that’s not the point of this blog. The point is that being a Product Owner is a next-to-impossible set of responsibilities for any one single person to perform. And while most frameworks don’t expect this person to do all the work themselves (they can delegate), the accountability for all these things falls square on the P.O.’s lap. It’s a BIG and stressful job.
The Rock Crusher acknowledges these assertions as facts and recommends that the role be split to better balance the work among more than one person. The way they suggest breaking this out is into two positions:
- Backlog Owner – this person is accountable for the management and prioritization of the product backlog. They are responsible for collaborating and negotiating with the Solution Owners, Stakeholders, and Customers. Only this person can decide the order of the product backlog.
- Solution Owner(s) – for any given product, there may be one or more solution owners. I like to think about this as a product that has multiple modules, and a different person could be the keeper of each module. Their job is to represent the interests of their portion of the product and to advocate to get their solution built. The backlog owner negotiates with the various solutions owners to determine what should be built first.
Personally, I like this idea, and it aligns with reality (as I have experienced it). In my most recent Product Owner role, I acted more in the role of backlog owner than solution owner. In fact, I worked with and represented the interests of multiple different business groups, all of whom had their own unique interests and requirements. I still had to balance the needs based on organizational strategic goals, but this aligns well with the concept of separate backlog and solution owners.
Broken value chains
I’ll be the first person to tell you that I’m no expert when it comes to value chains, but I do understand what they represent. The Rock Crusher posits that most value chains are broken by the current way of working, suggesting that product owners are missing pieces of the chain (mostly before or after their interaction with it). Thus, the P.O. is hobbled because they don’t have a complete picture of what is truly needed by the organization.
The Rock Crusher addresses this by ensuring that every item is brought into the backlog via an intake process and that all parts of the value chain are represented. Another idea it posits is that all items that go into the backlog must also come out, whether as a solution, solution component, or as waste. I like this because it ensures that items aren’t able to hang around eternally, wasting time, and energy, and becoming stale.
The funnel represents the full value chain from concept to cash, thereby solving this issue.
The inability to see the “big picture”
The flat, stack-ranked backlog has never been very good at helping people visualize their products. The Rock Crusher agrees and introduces another concept called planning horizons. These horizons help people properly “bucket” the rocks (requirements) coming into the funnel into logical groupings by relative time and size. It uses the mining analogy to suggest that rocks need to be sifted and sorted and that the larger items must be tumbled and decomposed until they’re smaller and closer to the time when they’ll be considered for development. That, or they’ll get [r]ejected via the waste gate.
I was also happy to see that the authors are also a fan of Jeff Patton‘s “User Story Map,” which is a technique that agile teams can use to lay their product out in multiple dimensions. I am a HUGE fan of this technique, especially for greenfield (brand new) efforts. This method allows you to identify your MVP (walking skeleton) and then flesh it out by following the user’s journey over time. It’s a very powerful tool to help you identify gaps and prioritize what should go in your MVP.
How work enters and exits the product backlog (aka the intake process)
How items get added to the product backlog sometimes seems like a mystery to me, even when I’m the Product Owner. I hold myself responsible for managing this artifact, but I’m often surprised by things I’m totally unaware of that somehow make their way into not just the product backlog, but sometimes even directly into a sprint backlog. This is both alarming and frustrating to me as a product owner.
Another problem is that with so many stakeholders and avenues for getting things added to the backlog, it’s hard to keep up, let alone manage the inward flow. Don’t forget that in this model, it’s easy to clog up the funnel and block items from getting through the smallest part (the thin pipe).
The Rock Crusher acknowledges that everything coming into the backlog should enter via the funnel, and again, what comes in, must also go out. It also accepts the reality that there may be some “back-door” ways that things get added, and rather than deny this fact, it recognizes it and makes these items visible like anything else in the backlog. This supports the empirical process in that all the work is visible and transparent.
Hidden work by way of the business analysis work that necessarily precedes “ready” stories landing in a Sprint Backlog
As an agilist, one of my biggest pet peeves is “hidden” work, or work that is not clearly visible and recognized as work the team is doing, whether it’s development work or analysis in preparation for upcoming iterations.
In The Rock Crusher, this work is handled by a new concept called “crushers,” which are special types of rocks that bridge the gap between stories that require further analysis and when they’re “ready,” or suitable for development. In my experience, this type of work is usually unaccounted for, even though it requires time and effort by team members. The outcome of a crusher is additional information or details that are needed before a story can be developed. It’s similar to a spike, in a sense, but the outcome is not options, but the verified requirements of what should be built.
This concept also helps us to avoid falling into the trap of phased development or big design up-front. This could still be a slippery slope, so I like that it’s totally visible and transparent.
Final Thoughts
Agile has been a huge step forward in terms of successful software delivery, but it hasn’t been without some challenges and issues. The Rock Crusher does a good job of addressing some of these gaps, and provides a logical model for improving the way work flows into and out of a product backlog.
I just had my team start using “crushers” in our latest Sprint, and we’ll see how it works out. Right now, it’s an experiment, but if it works well, I definitely think I’ll be adopting more aspects of The Rock Crusher on future teams.
What do you think of these ideas? Are they too radical? Do they diverge too much from the existing frameworks and their defined roles and events? I’d love to hear what you think, so please share your opinion with me in the comments below!