Moving from Outputs to Outcomes means changing how you understand progress.
Moving from Outputs to Outcomes means changing how you understand progress.
When teams try to shift to focusing on outcomes, they may struggle to exchange old practices for new. Here's a key concept that may help where to apply effort.
Whether you work using an agile software development approach or a project management approach, the core understanding of progress tends to be about completing work.
The achievement of milestones in a project management context is often represented by completing the relevant tasks. There may be other criteria, but the emphasis is usually on completing the work, and each item checked off represents progress towards the milestone.
In an agile software development context, it is also very common for the focus to be on completing work. The frame may be on a user’s needs as described in a user story, but the understanding of progress is still the completion of work towards working software. The understanding of progress falls short of the outcome.
In either approach, there is rarely a mechanism in place for understanding if completing tasks that contribute to working software is achieving the desired outcomes.
Project Management bodies of knowledge document benefits realisation and value management. It is common for organisations not to implement these practices or do so in a way mostly lip service. These practices are rarely established within the flow of work such that:
The review of information that may validate or invalidate benefits is being realised as early as possible.
The information reaches the team, allowing them to pivot to either ‘double-down’ or pivot based on the evidence about how well they were realising benefits.
Agile practices have many mechanisms focused on the progress of work, and the rate informs the majority of pivots of progress or elements affecting the rate of progress.
Organisations may commonly use these practices to track metrics and conduct research which may inform how successful a team may be in contributing to positive benefits for the intended beneficiaries. The common challenge is that with so much focus already devoted to completing work, it remains the dominant understanding of progress.
It takes deliberate effort to shift the focus to review progress through a new lens. There are many ways to try to do this. I recommend layering on various approaches progressively until adapting the plan is more often made due to what is seen in the data that represents evidence of progress towards the outcome. By progressively, this might be sprint by sprint.
Some examples may include:
Digital dashboards feature the measures relevant to the aspired outcome being focused on in addition to other key performance indicators that may need to be monitored to ensure there aren’t adverse effects.
Information radiators are stationed where the team works for easy use in regular rituals and for serendipitous discussions amongst the team or interested passers-by.
Embedding use of information in regular ceremonies such as daily stand-ups, weekly progress meetings, sprint reviews or demonstrations, quarterly reviews, etc.
Alerting setup to detect trends such as adverse effects, leading indicators moving positively or negatively, etc.
Conducting regular research such as bringing in relevant users for interviews, usability testing, ethnographic research, etc.
Just as important as monitoring for signals of progress is what the team does with this information. When the muscle memory for adaption is built around changing in response to obstacles preventing task completion, it’s not guaranteed that stimuli of a different nature will lead to the same sort of adjustments.
When the primary stimuli are indicators of real progress towards the desired outcome, the team can adapt the work they prioritise based on what is and isn’t working. It doesn’t mean that information such as delivery metrics or critical path progress the team is used to responding to isn’t important. Optimising your path remains useful.
The most important optimisation is working on the right thing, as I learnt in this painful life episode:
With this in mind, the shift of emphasis can still lead us to the course correction that helps us chart the optimum path. Dependency challenges that can be gnarly problems to solve in output-focused development are actually easier to resolve when the primary context is focused on progress towards an outcome. For instance, the evidence may also help resolve prioritisation calls across multiple teams in a way comparing tasks without that context may not.
It takes deliberate effort for the team to learn the new types of questions about the new sources of information and what to do in response to what it is telling them.
Have you been trying to shift towards a more outcome-focused way of working? What challenges have you faced? How did you try to overcome them? What did you have success with? What challenges do you still face? Share your experiences in the comments.