There is an old saying, “A bird in the hand is worth two in the bush.” The idea is the bird in your hand you actually possess, whereas the birds “in the bush” are mere possibilities. This could well be the slogan for most Scrum teams: “A solution in the hand is worth five in the bush! Build! Build! Build! There is no value created without software DELIVERED!”
There is, however, a problem with this aphorism, even as applied to birds. Applied to software, it’s worse. After all, most software isn’t all that value-adding. In fact, much of it has negative value—it costs money to build and implement while failing to achieve intended outcomes. It adds technical debt and complexity without real justification. As I like to put it, building faster than you can learn is waste. Back to our aphorism, it’s as though it wasn’t a real bird at all. You were making shadow puppets.
Even if the “bird” is value-adding, there’s a larger problem with the saying—it assumes the birds are all the same. What if you’re starving and the bird in your hand is a goldfinch? And what if the birds in the bush are ducks, quail, and turkeys?
Consider the opportunity cost of accelerating your “builds” of goldfinches, while failing to discover those quail, just sitting there, in that bush. That’s the power of discovery. Increasing your velocity of goldfinch delivery will NEVER compensate for missing the ducks and quail. We can then add to the aphorism:
Building Diving Boards
Your goal isn’t to create more software. It’s to create VALUE. Never let anyone tell you otherwise. The work you do is just work. To get to value, you must connect some dots. You must build a bridge to the intended value. It’s like completing a circuit. Most orgs don’t build the whole bridge. They build diving boards.
Think of “Ye Olde Waterfall” or even “Scrum at the Bottom,” which is as far as most orgs get into agile. Both are diving boards, not bridges. (“Scrum at the Bottom,” a phrase I got from Allen Holub, describes the typical practice of imposing Scrum on dev teams, ignoring the rest of the org, and thinking you’ve increased agility.) Both are self-deception.
At a level above “the solution” come the designers and their double diamonds. They improve the dismal situation by introducing Norman’s notion that you must explore the best problems to solve before diving off the board into solution space. This extends the diving board but still doesn’t get you there. What concrete behavior changes will produce value? How is the work to be done tied to the overall strategy? You still haven’t connected all the dots for the business.
The Importance of Chunking Up
A relevant concept throughout this post is “chunking up,” as sometimes discussed in coaching (e.g., Dilts, 1999). If you “chunk up” to a higher level, this helps generate more alternatives on the lower level. You create options. Chunking up from problems to outcomes helps you explore better problems to solve, just as chunking up from outcomes to target value helps you explore alternative outcomes you might achieve to create value.
In Lean Startup and DevOps, you see this notion expressed as “focusing on outcomes over output” (see Kim, Humble, Debois, & Willis, 2016; Gothelf & Seiden, 2013). This is similar to the idea of the “ZOPA” from negotiation, the “Zone of Possible Agreement.” Instead of focusing on people’s separate positions, the idea is to chunk up and focus on their shared interests, creating a space to discover new mutually-agreeable options (Fisher & Ury, 1981).
In design, this has been described as dictating vs. exploring the HOW (Dorst, 2015). For example, if a team is tasked with, “Providing someone energy in the morning by designing a new coffee maker” (dictating the HOW), there are fewer degrees of freedom than if just tasked with, “Providing someone energy in the morning” (not dictating the HOW). With the latter, the HOW can be explored, and a kale smoothie or morning workout become viable options (image adapted from Dorst, 2015).
From Diving Boards to Bridges
Problems are really OPPORTUNITIES to achieve outcomes, which is why I prefer the term. There are other reasons to prefer the word “opportunities.” Focusing on “problems” suggests an “away from” orientation. They’re something negative you’re trying to escape. Opportunities and outcomes, on the other hand, are both a “towards” orientation. They are positive things to pursue (Tompkins & Lawley, 2006).
Further, you don’t need to solve a “problem” to find opportunities. Focus on problems then can limit your thinking. The “solution” metaphor can also imply an assigned problem, as in a math test. It’s unfortunate baggage that can result in fixedness. So let’s drop it and collapse “solution/problem” into “opportunity.”
Let’s also drop the term “output.” You’re really betting on opportunities, after all, so let’s just call a spade a spade: Your work are the “bets” you’re placing. Above your bets and opportunities, you also need to explore what outcomes—what behavior changes—you’re trying to achieve to create target value. This helps you discover more viable paths to value. And now you’ve connected the dots. The bridge to value is complete.
This requires research, by the way, actual design research—qualitative interviews of stakeholders, users, executives, and subject matter experts. Just building stuff won’t get you there. The more viable paths to value you discover, the greater your optionality and the bigger your likely impact.
Building the bridge from your bets to value can be described as “vertical thinking.” Broadening your perspective and increasing optionality and paths requires “lateral thinking” (de Bono, 1970). You need both.
There are models out there to help you both connect the dots vertically and broaden your focus laterally. One is Teresa Torres’ (2016) Opportunity Tree. Another is the North Star Framework, as discussed in Cutler and Scherschligt’s forthcoming book on the topic. Both can help you visualize your vision and strategy in a concrete and measurable way. Mapping this out helps you do two vitally important things.
First, it helps you laterally explore options at ALL LEVELS, discovering not only new paths to target value but also bigger value YOU COULD BE GOING AFTER (which helps minimize cost of delay).
Second, by crisping up your strategy and knowing what needles you’re trying to move, you create unambiguous “pivot signals.” When you place your bets, you then can clearly see whether target metrics moved in the right directions. If they don’t, try something else. The “definition of done” is irrelevant.
Do both these things and you’ll have a bridge to value and not a diving board into busywork. To close, remember our improved aphorism: You don’t know the value of the bird in hand if you don’t know what options were in the bush, so plan vertically, but in a way that allows for the discovery of lateral options.
References
de Bono, E. (1970). Lateral thinking: creativity step by step. NY: Harper & Row, Publishers.
Dilts, R. (1999). Sleight of mouth: The magic of conversational belief change. Scotts Valley, CA: Dilts Strategy Group.
Dorst, K. (2015). Frame innovation: Create new thinking by design. MIT Press.
Fisher, R. & Ury, W. (1981). Getting to yes: Negotiating agreement without giving in. Boston: Houghton Mifflin Company.
Gothelf, J. & Seiden, J. (2013). Lean UX: Applying Lean principles to improve UX. Sebastopol, CA: O’Reilly Media, Inc.
Kim, G., Humble, J., Debois, P. & Willis, J. (2016). The DevOps handbook: How to create world-class agility, reliability, & security in technology organizations. Portland, OR: IT Revolution Press, LLC.
Tompkins, P. & Lawley, J. (2006). Coaching for P.R.O.s. Clean Language UK. Retrieved on October 28, 2018 from: https://www.cleanlanguage.co.uk/PRO.html.
Torres, T. (2016). Why this opportunity solution tree is changing the way product teams work. Product Talk. Retrieved on February 25, 2018 from: https://www.producttalk.org/2016/08/opportunity-solution-tree/.
Charles Lambdin 