Discovering Value
How Project-thinking can limit value delivery
When working with a Scrum Team you will be aware that there is an emphasis on delivering value. This idea is a differentiator for Agile delivery. We deliver valuable outcomes. We deliver increments of valuable software. We deliver the most valuable thing first.
In my experience, conversations about value are harder for people in Project-orientated organisations. Product Owners working on Projects may end up prioritising a Project business case. That’s a different thing to ‘maximising the value of the product’.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. — The Principles Behind the Agile Manifesto
Practitioners of Scrum will be aware that Scrum defines itself as:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. — The Scrum Guide 2017
The Scrum Guide is clear that:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. — The Scrum Guide 2017
Like Marc Loeffler, speaker, author and Agile coach says: ‘Scrum is not magic’. It will help make a software delivery process transparent but then it’s up to us to fix the problems.
I’d like to share a definition of value that helps us understand how Project-thinking can inhibit value discovery. This may help us expand how we consider value.
A Definition of Value
I like the iiSM definition of value:
‘Value exists in four states: potential (needs deficits), discovered (new recipes, solutions, or other creative works), replicated (reproduced products, goods, shows, or services), and liquid (cash or cash equivalents). Examples of “things of value” by the value state include:
- Potential Value — unmet needs or desires, need deficits, unmet demand, or outstanding orders
- Discovered Value — recipes, manuscripts, drawings, patents, formulas, code or other descriptions of a solution or creative work that is discovered to reliably meet a need
- Replicated Value — finished goods, orders, plates of food, delivered products or other solutions, productions, or services that are reproduced through a known means
- Liquid Value — cash or cash equivalents such as stocks, bonds, or checks, or other easily exchangeable things of worth that have a stable value
Value in any of these four states can be recognized as being valuable due to its potential to fulfil an actual unmet need. In the presence of unmet need, outstanding orders are valuable, new recipes that meet a need are valuable, created goods using a known recipe are valuable, and cash or cash equivalents for the sales of replicated goods or services are valuable.’ — iiSM
I like this definition because it is accessible to people immediately. It does not need translation of technical jargon and is not limited to software. At the same time, it is not a simple dictionary definition and is helpful for considering software development.
The Value Fulfilment Cycle
The value fulfilment cycle can be thought of as the process by which potential value is discovered, replicated and then results in revenue.
In order for an organisation to realise or fulfil value, the parts of the value fulfilment cycle must work together.
In discussing value through software delivery with Scrum I’d introduce this as:
- Financial management — initial investment and return on investment.
- Value discovery — understanding user needs and creatively producing increments of met needs.
- Value replication — delivery and scaling of the working increment. This may be by delivery of smaller value increments which each satisfy customer needs.
Financial management (liquidation management) is well understood in modern organisations. There will often be a separate Finance Department dedicated to this.
Value discovery is the process of identifying an unmet need (potential value) and then converting it into replicated value. This requires new learning and is also likely to involve failure (and more learning!). A learning environment that fosters creativity and diversity of thought is required for organisations to achieve this.
Value replication (business management) is also well established in most business contexts. Replicated value involves known solutions, known equipment and known work practices. Typically the people doing the work are familiar with it and have been trained in the work practices. This type of work lends itself well to long-term planning: Gannt charts and predictive plans.
For a deeper look at the origins of these elements of the value fulfilment cycle I’d recommend Gene Bond’s great article Why Are CEOs Failing Software Engineers?
Value discovery may be new territory for many traditional organisations. If we want to be able to maximise the value of our work we need to understand what it takes.
Agile Project
Projects work well for certain types of activities but can have limitations when applied to software development. In my opinion a typical Project is unlikely to consider value discovery.
In a Project-centric organisation business management is used to determine up-front which Projects align with the strategic aims and what each Project needs to do (for brevity lets include regulatory change and exposure/risk reduction with strategy). Projects are prioritised and funded based on strategic alignment (with funding based on high level estimates that may not have been provided by the team that will do the work). Projects are then allocated to temporary Project teams. These teams may then produce a more detailed business case to define the Project budget and deliverables. When completed they will hand-over to a separate support function.
Where does value discovery sit in a context where feature scope and total cost are defined up-front? If Project teams are held to up-front definitions of scope then there is no flexibility for discovering higher value outcomes or for adapting to feedback.
There are viable work-arounds for dealing with the problem of being unable to discover value during a Project.
Project-orientated organisations may fund a distinct ‘discovery’ phase that has the sole purpose of discovering or establishing a need. Once established further funding may then be released to deliver against that need.
Feedback may be sought per increment with funding re-evaluated at a distinct Project lifecycle stage. For example, the DSDM framework helps with this. Feedback is sought per increment and funding is re-evaluated at the Foundations stage.
Contrast Project-workarounds with the idea of funding stable Product teams. These teams use their budget, determined by strategic importance, to discover the value that will enable them to achieve their strategic aims (e.g. more customers, market entry, etc.). They can make decisions about benefits which make sense for the Product and can deliver value for current and future funding cycles. Acknowledging value discovery and seeking to benefit from it encourages feedback loops. These teams have the flexibility to address value discovered via these feedback channels. There is no hand-over or end point — these teams will make decisions that consider the Product lifecycle.
Whether you are in a context that is at one of these extremes, or somewhere in between, factoring in value discovery is essential to maximise value.
Opportunities to Discover Value
Articles about how to deliver value will often have a list of activities that one should consider to deliver value. I’ve created a diagram which shows opportunities for value discovery instead.
The yellow arrows show value discovery via feedback routes. This feedback can then influence the work.
Activities like technical debt resolution or technical automation, which many Project-orientated teams have to fight to prioritise, actually assist value realisation across the cycle. These activities will reduce time to develop software and will also make replication of value easier (by speeding up this process and/or improving operability). But if we stick to a Project plan based on feature delivery how do we discover and then realise this value?
Feature delivery will result in something that can be replicated but if user needs are not met and user outcomes not supported then a delivery is unlikely to result in ROI or actually achieve business goals.
By understanding value fulfilment as a cycle we can look for opportunities to put in place feedback loops and use the feedback to enhance the value we deliver.
Closing
Failing to consider the value fulfilment cycle can lead to missing value discovery activities. It can also mean that feedback loops, that will enhance financial return or simplify value replication, are absent. Dogged insistence on traditional business management reduces the effectiveness, and the value, of software delivery outcomes.
By understanding value fulfilment as a cycle we can look for opportunities to put feedback loops in place. We can then use the feedback to enhance the value we deliver per increment.
As Scrum Masters we want to encourage an organisation toward empirical Product development. The benefits for inspection and adaptation that value discovery activities provide are too significant to be overlooked.
Product Owners may find themselves trying to maximise value for a Project that has a one dimensional view of value. Worse yet, they may be unable to capitalise on discovered value because it wasn’t on the Project plan.
An organisation that struggles with innovation is likely to have overlooked the importance of value discovery. Failure to consider the whole cycle of value fulfilment will limit our definition of value. This will limit the value of the work we deliver to end-users and customers.
References
Bond, Gene: Why Are CEOs Failing Software Engineers?
Loeffler, Marc: ‘Five Things Nobody Tells You About Scrum’ from ‘97 Things Every Scrum Practitioner Should Know: Collective Wisdom from the Experts’, 2020
