We eat sushi with chopsticks (traditionally by hand) and miso with a spoon (traditionally with chopsticks). Each tool works in some context. Specialized instruments are highly effective in just a few situations, while tools created to work everywhere are never the best at anything. Therefore, it’s good to know in which context a tool is most effective. There’s no reason to spoon up your sushi when you’ve learned to handle chopsticks.
In my opinion, the part of the Scrum framework that has the most important consequences for continuous innovation is the separation of concerns between a Product Owner and a Development Team.
“The Product Owner is the sole person responsible for managing the Product Backlog […] Those wanting to change a Product Backlog item’s priority must address the Product Owner.” (Scrum Guide)
Taking into account the Innovation Vortex, it appears that the Product Owner is responsible for contextualizing the problem space, empathizing with users, synthesizing the insights, and hypothesizing about product features. It is the Product Owner’s job to manage all that work together with customers, users, and other stakeholders and to act as their proxy, representative, and final decision-maker when handing over the work to the developers.
The Development Team then does all the work externalizing the product increments, sensitizing how users respond during product reviews, and systematizing their work in retrospectives. It is the Development Team’s job to build and deliver the things requested by the Product Owner. The team then needs to confirm with the Product Owner what is the next highest-priority work to be done when preparing for the next sprint and the next product increment.
Scrum is strong when we focus most of the work on the delivery of value. It assumes an entire team to be working in just three streams of the Innovation Vortex, while only one person carries responsibility for the other four streams! At the same time, this also means that Scrum is weak when most of the work that needs doing is around the discovery of value. The right context for Scrum is execution, not exploration. Continuous innovation requires both.
Scrum advocates will object and say that you can adapt the Scrum framework to include the discovery of value by observing user behaviors, making prototypes, and running lean experiments. That is true. It is also true that you can eat sushi with a spoon when that is the only tool you know how to use. I prefer to learn the use of more effective tools.
In the early stages of the Business Lifecycle, our focus should be on Why and What. We iterate like crazy across the entire Innovation Vortex, with prototypes and lean experiments, because our purpose is to discover value (exploration). In the later lifecycle stages of a new product, our focus steadily shifts to How and When. We iterate like crazy across the Innovation Vortex, with increments and product reviews, because our goal has gradually shifted to delivering value (execution).
First, we explore/discover and do the right thing. Then, we execute/deliver and do the right thing right.
In continuous innovation, there is no binary switch between exploration and execution. In the beginning, your cross-functional team may have researchers, experts, designers, marketers, salespeople, data analysts, and maybe one developer together creating one prototype after the other. Over time, more developers move in, and the non-developers move out until you end up with one “cross-functional” team of only developers, plus a Product Owner who represents everyone else because the others aren’t needed full-time anymore. Over the lifetime of a product, your focus will shift gradually. But the Innovation Vortex is always spinning.
You start with Design Thinking, and you end up with Scrum. In a great meal, you use both chopsticks and a spoon.
By reading this article, you made progress toward your Agility & Innovation Qualification. Report your evaluation here and collect your experience points!