At this year’s Agile on the Beach conference, I spoke about outcomes – why they’re important, why they’re underrated, and how software developers can stop just focusing on “the thing”.
The “thing” I’m talking about is the software we build for our clients. It’s easy to get caught up in features and integrations and all that other technical stuff, when what we should really be thinking about first are the outcomes.
But what exactly is an outcome? According to Agile consultant Joshua Seiden, “an outcome is a change in behaviour that drives a result”. So, if we wanted to see improved literacy among children (the result), we’d want to put processes in place to get more children reading regularly (an outcome).
Structuring initiatives around specific deliverables limits the chances of success; instead of asking “what should we build?”, we should ask “how can we make this happen?” In our literacy example, that would mean getting more kids access to a library, rather than focusing heaps of resources on building a grand interactive learning tool.
Sometimes, the simplest outcome leads to the most impact – it’s all about understanding exactly what you’re setting out to achieve.
Ask yourself, “should we be doing this?”
Here’s another of my favourite quotes, from the legendary management expert Peter Drucker: “There is nothing so useless as doing efficiently that which should not be done at all”.
Like I said before, it’s easy to get carried away in the planning stages of a project – and it’s even easier to get swept up in consensus when everyone’s enthusiastic about getting started.
What we need at this point in the process are dissenters; people brave enough to speak up and point out the risks and potential pitfalls of a project. (Not just people who like to argue, though.)
You’ll often find that once one person gets up the courage to ask a question, others will too. And that’s how well-realised, outcome-focused projects get off the ground – through ideas being shared, picked apart, and put back together with new thoughts added.
If you do identify something as critical, consider having multiple teams working to solve it, trying different solutions with different risk profiles. The more brains on a project the better, but separating them can help give everyone more focus and accountability for their solutions.
Listen to your client – don’t talk at them
Many companies claim that they work closely with their clients to identify their needs – but many end up talking at their clients about what the developers think they need instead. They get caught up in “solutionising”, and thinking about how they can fix the problem, before they really know what it is.
Let your client do most of the talking at the interview stage. Go find the people who are going to be using your solution, and find out why the process currently works like it does. Why do all the different steps exist? What ugly workarounds have they had to use to get things done?
When solving a client’s issue, it’s always most useful to ask them about the last time they experienced it, rather than the problem in general. The specifics will be helpful for identifying the root cause of the issue – which then becomes the basis for your use case.
Measure everything – and know when to stop
Understanding what causes what is fundamental to successful development. You need to have metrics in place from the start of development, right through to launch (and beyond).
As you’re developing, put guardrails in place to ensure improving one metric doesn’t also make another worse. For example, implementing a system that gives online shoppers more product recommendations might increase average cart value, but could also damage your CSAT score if they find it annoying.
Once you’ve launched your new product, app, or tool, you need to measure whether it’s actually being used, and whether it’s effective. Gather heaps of user data, and map that against your expectations – is this how you thought your users would apply the tool? Are they seeing the planned outcome?
Iterate through the bad feedback, but know when to stop. If you’re getting good feedback and seeing the right outcomes, you don’t need to keep changing and adding things. You often don’t have to build every planned feature; requirements have a way of inventing themselves during the ideation process.
It’s often the case that around 20% of the software delivers 80% of the value – so focus on that first, and then you can worry about whether it’s worth building all the extras.
Watch the full talk
It’s difficult to fit 70 slides-worth of talk into a single article, so I’ve just collected some of the highlights here.
To get the full talk, you can watch the on-demand version here, where I explore more structures teams can follow for outcome- and behaviour-driven development, and examples from my career as an Agile facilitator.