Odd contradiction: Focusing only on delivery optimisation is sometimes enough
Outcome thinking gives big benefits. So much so it's easy to become dogmatic. It's important to acknowledge that sometimes a delivery focus can support fast learning, too.
In modern organisations, it is still common to find teams who are busy shipping software without a reliable feedback mechanism to determine if what they are delivering is valuable. I am often in a position to help them navigate a path to address that gap. With the rising expectations of users and the pace of technology change, in most organisations, such a team could soon find themselves in a compromised position with dissatisfied users and an ever-increasing set of needs they are failing to meet. More often, they are in that position already.
When a team lacks adequate feedback mechanisms relating to the value they deliver, they lack a mechanism to help them improve the value they deliver. The path to addressing this issue is not a straight line. While you might introduce them to concepts of value, outcome-thinking, user-centric thinking, measurement, and feedback loops, these are not all concepts we can expect to be adopted simultaneously. Each is a rich and deep topic in its own right, and even once you understand the why of these concepts, addressing the issue effectively requires learning an entirely new set of practices.
A lot is made of the dichotomy between waterfall and agile working. I am less interested in such tiresome debates - I believe the working approach is a function of your context. Waterfall vs agile is a redundant boogeyman. The more poignant issue was whether you used appropriate methods for your context. Simon Wardley’s idea of evolution as it relates to components is an excellent way to think about which way of working is most appropriate in which contexts.
Project Management approaches based on PMBOK or Prince 2 primarily understand progress through action. They, of course, also guide tracking value with concepts such as benefits realisation or benefits management. Still, these are ancillary to the primary progress method: tasks, milestones, and other activity-oriented elements.
Agile software development is more focused on value with concepts such as the Product Owner and focuses on engaging with the intended beneficiaries of the software. In practice, I’d argue that most teams practising agile software development are far more delivery-focused than value-focused. Product Owners often have become proxies, and most signals for progress again come from completed work. This is because that information is more available than actual validation that the software addresses the need it is meant to solve. It is also because there’s been far more competency and agile training in delivery-related practices and metrics than outcome-focused methods. The most effective element of agile software development that remains is the focus on working software. Unfortunately many organisations find ways to delay the availability of working software reaching the hands of its intended beneficiaries. A fast iterative delivery mechanism that reaches real users who will use it for real work provides a strong learning signal, even if the other sources of feedback are delivery focused.
I prefer to focus on whether the type of feedback available to a team is appropriate for the work, the effectiveness of the feedback, and how the team’s ability to respond to the feedback can be improved.
For instance, if we are undertaking a somewhat deterministic objective, the best signals of progress may be more action-oriented events, such as something arriving at a location or an action being completed. Most of the time in product software development, however, we are dealing with more complex objectives that must consider whether the software is successfully meeting its user’s needs, and for that, a more sophisticated set of signals is needed along with a team sensitive and responsive to those signals.
More interesting to me is the combination of outcome-oriented (you could also describe it as value-oriented, purposeful, or impact-oriented) thinking with delivery approaches. For instance, in a more commodified context where the problems are well known, and the solutions are well known, we might combine an outcome-based roadmap, some practical performance measurement and benefits realisation along with a sequential work that incorporates these elements along with contingencies based on responding to poor performance underachieving in terms of benefits realisation. Now, you might further improve on this by using some concepts from agile practices, but sometimes, this is unrealistic.
For instance, sometimes the contracts and management of multiple third parties, vendors, and suppliers mean the strength of practices most needed is established ways of managing these parties over completely adaptive delivery methods. What's most important is that you at least had mechanisms to ensure that all these parties were coming together and successfully solving the user needs.
In the scenario of more custom software creation in software product development, it’s also very relevant to incorporate a continuity between the development practices and the outcome-oriented thinking in a way that informs both directions. The value of combining outcome thinking with this agile, responsive way of working is fewfold:
Be used to help filter for what is relevant to the current goal and what is not.
Helps to identify relevant signals to monitor.
Know when we have done enough or are going too far.
Know that in addition to meeting a need, it is of adequate business impact, such as meeting more significant business goals or satisfying critical needs of the organisational strategy (such as gaining market share at the expense of your competitors on a critical battleground).
With these benefits, some of which can be considered strategic, it can be easy to get dogmatic about working this way. If given the option to work this way with marginal additional investment, why wouldn’t you?
It’s essential, however, to acknowledge that delivery-centric practices such as project management methodologies such as PMBOK, Prince 2, Scrum, XP, etc. can lead a team to meaningful and fast learning. I’ve seen traditional project plans geared around fast learning and determining whether something will work in short order. I’ve seen agile approaches achieve the same, too. The benefits can be a simple manner of planning that teams are familiar with and the experience of the individuals knowing what they are striving for and what to look for to know if they are making meaningful progress.
As you have gathered, given the focus of this publication, over the long term, working deliberately with outcome-oriented practices will, on average, help organisations be better off by investing time in the most impactful parts of their strategy more often. But it would be incorrect of me to say you cannot make meaningful progress by intense focus on delivery, especially iterative delivery.
It must be acknowledged that delivering something quickly into a circumstance where it will be tested and used can yield learning and allow for pivots and change towards what works and away from what doesn’t. Without the broader outcome focus, there are some risks, such as investing where there are diminishing returns or meeting user needs well but those which are less critical whilst leaving more important needs unattended. The challenge is that it can be tempting because we feel that there is a collection of practices that can make something even more perfect than anything less than failure.
It would be equally a failure to do excellent longer-term outcome-oriented planning but to fail to execute in a way that supports fast learning. I’ve seen this scenario play out in organisations that are very strong strategically but are maybe falling into the management consultant trap of crafting perfect strategies, which they assume succeed or fail on execution without attending to how the strategy translates into execution and how what is learned through execution informs the strategy. The ability to deliver and learn is essential. Without it, it can lead us to operate in a ‘Gap Thinking’ style where we start to assume if only we ticked a bunch of boxes, our strategy would then be realised and our success inevitable.
The ideal state to cultivate at an organisation is one where there is strong competency in how leaders provide the context to orient the organisation in a direction and also how effectively it can operate on knowledge of its current state, its situational awareness, and the learning mechanisms to navigate in the desired direction efficiently.
That state is not immediately attainable and takes sustained investment in building the organisational muscle and belief in these practices by experiencing the benefits of working this way. Only through experience do people begin to trust that additional effort in practices with longer-term pay-offs is worthwhile. There’s innate inertia from ingrained biases to overcome.
I don’t know which is the shorter path - to get great at thinking in outcomes or to get great at learning through delivering. To track an optimum path needs both elements. Most of us who champion the field of outcome-thinking today followed the path of getting great at delivery first. I also know that most people are geared towards understanding how to do over setting a direction and, therefore, may benefit from learning how to do it in a way that iterates more quickly to a learning event.
It can be unreasonable to have learnt something over a long path yourself and to expect people to arrive at the same collection of practices immediately.
This doesn’t mean don’t champion outcomes-thinking. There’s a shorter path when we learn from those who have been there before. It’s helpful to have practices used successfully before discovering a new challenge. We cannot presume the absence of a practice we arrived at over many years of working experience is a guaranteed failure pattern for a team earlier on the path. Invest in building muscle in thinking about the future to identify and communicate the direction and building up competency to deliver just enough value to validate it, solving the right problem in a way we can validate and learn. Celebrate when progress is made in either present-thinking or future-thinking. Highlight the valuable interplay between both and the risks of only attending to one or the other.
The absence of outcomes thinking can lead to the temptation to admonish teams for their delivery-centric practices. It can help to identify when it's happening and some consequences, but do so without judgment. It is better to focus on what is improving and how we can improve learning mechanisms in the present. To be confident, a team will attend to both responding to the present and thinking more about the outcomes they are trying to achieve over time. We must celebrate an improving learning loop however we reach it.
Should we have an effective learning loop in place and access to those with experience who can share options to try, we can trust that any group will, in time, uncover the value of the other practices. We will experience when we fail due to the absence of some context and, over time, value practices that help us the value of establishing that context. Cultivation of the learning loop focused on how the team attains the desired value is your best investment in helping them see what you see.
What proportion of feedback is focused on value versus delivery? How frequent and reliable is the feedback? What experiences have you had in a team navigating this type of improvement? Share your experiences in the comments.