Maximizing Value
Road to Mastery — Season 2 — Episode 5
Scrum exists to help delivering products of the highest possible value. In this episode, which can be read on its own, I’ll share my thoughts on how to turn value all the way up to eleven.
“The Product Owner is responsible for maximizing the value of the product” “The Scrum Master helps everyone […] maximize the value created” - The Scrum Guide
In Scrum, the Product Owner is synonym to Value Maximizer. And let’s be honest, the latter is a far more epic title. But what exactly defines ‘value’?! First we need to establish a shared understanding over the concept ‘value’. I’m guided by the definitions of value as defined in the Evidence Based Management Guide by Scrum.org:
The definition of value is naturally contextual. A Product Owner should establish a Product Vision and transparency over what indicates value. A good way to approach this is to define Key Value Indicators (KVI) for your product.
Now, once you are able to distinct value-that-is from value-to-be, and the ability, time and effort it takes for value-to-be to be, it should be straightforward to create a roadmap on how to get from A to B, right? (are you still with me?)
“But, Mousie, thou art no thy-lane, In proving foresight may be vain; The best-laid schemes o’ mice an’ men Gang aft agley, An’ lea’e us nought but grief an’ pain, For promis’d joy!” - from ‘To a Mouse’, a Scots poem written by Robert Burns in 1785
In this poem, the poet compares the fate of the mouse with that of man: the mouse does not know what is hanging over him. Both are prey to fate.
Maximizing Value in a complex adaptive environment can be a nightmare. In a world with complex adaptive problems… the best-conceived plans, “for promis’d joy!”, often go wrong. While value is added, waste is also introduced into the system…
Value Discovery
Curiosity sparks the motivation to discover. When we dare travel off the beaten track, we can find hidden treasures and lost paradise… but … we can also get lost in the woods fairly quickly. So what exactly is needed for curiosity to triumph over the fear of getting lost?
“Anything that just costs money is cheap.” ― John Steinbeck
A scrumundrum: often teams consider it the sole responsibility of the Product Owner to perform all this discovery. The Development Teams surely only need to develop and deliver… right?! Well…. no, actually.
“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.” — The Scrum Guide.
So, who are the treasure hunters in your team? If the answer isn’t “all of us” you better get to it! One of the most effective ways to maximize value is to utilize the creativity of a cross-functional, self-organizing Development Team!
To quantify value in this environment requires learning loops. Shorter loops equal less risky bets and through it validated learning is established. We can learn what triggers and what doesn’t.
It is a good idea to have discovery and learning activities inclusive in each Sprint. These activities should preferably not be performed external to the Development Team. It should be all-inclusive. Teams can inject evidence-based decisions based on customer and user data into development. This enables the team to journey from doubt to certainty during a Sprint. In complex environments, it can help us sense and probe dangers ahead.
But where in Scrum should all this exploratory work be managed and made transparent?
“The Product Backlog is an ordered list of everything that is known to be needed in the product” — The Scrum Guide [emphasis added]
What about all the work and stuff we don’t yet really know if it is needed or not? It is generally NOT a good idea to maintain a separate backlog as this would be a sure way to reduce transparency. Most Product Backlogs contain items that are pretty much all value assumptions. Just like a definition of complexity can be considered an estimation, so can the definition of value be considered an estimation.
So what exactly qualifies as ‘known to be needed’? For something to be known, it must include, to a degree, a validation of the assumption that it is in fact needed. Collecting evidence can surely be considered an exercise that is part of refining the Product Backlog. It can be processed through the Sprint Backlog if the Development Team is indeed performing discovery activities! The Sprint Review also offers a perfect opportunity to inspect and adapt value assumptions with stakeholders. What’s more, the mission to validate value assumptions can make for great Sprint Goals. Great Sprint Goals spark an active inner search process and the drive discovery in a self-organized way.
Ability to Innovate
In order to maximize value we need to minimize time-to-evidence. Which requires us to address our ability to innovate (A2I).
Through these opportunities offered by Scrum and the inclusion of refining unrealized value with the Development Team, we learn quickly what is impeding the organization from delivering new value and thus preventing customers or users from benefiting from yet unrealized value…
Technical Debt is the nemesis of a team's ability to innovate. It obscures the product and impedes the Product Owner's ability to make the right decisions that maximize value! So, Product Owner, to counter this you need to battle this monstrosity, not ignore it! Learn what is slowing down the ability to make customers happy.
Unrealized Value
With potentially valuable items, it falls upon the Product Owner to determine their arrangement in the Product Backlog. It also falls upon the Scrum Master to ensure the Product Owner knows how to arrange the Product Backlog to maximize value.
One sure way the Scrum Master can help is to make sure the Product Backlog is in a ‘transparent state’.
“Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.” — The Scrum Guide
Time to Market
Focussing on Flow Efficiency is a great way to improve the time-to-market. Teams should focus on minimizing wait times between hand-offs and reduce setup-times/context switching between items. Scrum already improves flow efficiency by reducing batch sizes of work in short sprints which provides various opportunities for group collaboration (swarming). Sprint Reviews for example shorten the time between collecting feedback from stakeholders, instantly processing it into the Product Backlog, and putting it into practice the imminent Sprint. Promoting teams to co-create whilst shortening the feedback loops between the Development Team and Stakeholders, are sure ways to increase flow efficiency.
Current Value
How happy are the customers and users about that which has already been delivered?
Many (Scrum) teams exhibit a ‘Deliver & Forget’ habit.
When it’s “done” it is done after all, one could argue. But are we ever quite “done” in incremental development? “done” perhaps means we can start learning: inspect and adapt. So, in order to get the most out of the value that has currently been delivered, is to learn exactly how this is satisfying the customers/users over time.
If users are already struggling in benefiting from the current value that exists in the product, there is little value to Development Teams dumping more.
The key to breaking this pattern of Deliver & Forget is to start focussing on validating outcomes over producing output. Spending time and energy in learning how the current value impacts customer behavior and happiness, can be a far more valuable exercise than rushing even more code out the door.
With these ‘best-laid schemes’ we can “for promis’d joy!” beat the mice at this game.
Maximize it all the way up at Portfolio Level
If you, like me, are also on the road to distinguished product ownership, it involves learning strategies that generally work best at portfolio level when (for example) key value metrics indicate value is declining on a certain product in relation to others.
Now it wasn’t until very recently I came across this gem: An Introduction to Evidence-Based Portfolio Management.
I have yet lots to learn on this subject and therefore yet little to share. I hope you will head over to our home in Slack to either guide me on this journey or embark on it together with me. Value… let’s turn it all the way up.
The Road to PSM III is being reformatted to The Road to Mastery! Part I: Down the Rabbit Hole is now available.
If you like to explore how Lean UX supports the Product Owner in maximizing value:
Continue the road to mastery:
