Consider Payoff
How do you choose what to work on next?
Sometimes, there will be multiple actions you could take on a project and you have to choose the best one:
- There's the risk you'll decide wrongly.
- And, making a decision takes time, which could add risk to your schedule.
- And what's the risk if the decision doesn't get made?
We can't know in advance how well any action we take will work out. Therefore, Taking Action is a lot like placing a bet.
Payoff then is our judgement about whether we expect an action to be worthwhile: are the risks we escape worth the attendant risks we will encounter? We should be able to weigh these separate risks in our hands and judge whether the Payoff makes a given Action worthwhile.
The fruits of this gambling are revealed when we meet reality and we can see whether our bets were worthwhile.
Very occasionally, you'll be in a place where your hand is forced and you have to take one of only a handful of actions, or there is a binary decision. A so called "rock and a hard place". But as we'll see in the third example below, even here you can usually change the action (and therefore the payoff) in your favour.
Considering Payoff: Examples
Example 1: YAGNI
As a flavour of what's to come, let's look at YAGNI, an acronym for "You Aren't Gonna Need It":
YAGNI originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it". - YAGNI, Martin Fowler
The idea makes sense: if you take on extra work that you don't need, of course you'll be accreting risk - you're taking time away from sorting out the real problems! You'll also have a greater body of code to manage, which is also a risk.
But, there is always the opposite opinion: You Are Gonna Need It. As a simple example, we often add log statements in our code as we write it (so we can trace what happened when things go wrong), though following YAGNI strictly says we shouldn't.
So which is right? We should conclude that we do the work if there is a worthwhile Payoff.
- Logging statements are good, because otherwise, you're increasing the risk that in production, no one will be able to understand how the software went wrong.
- However, adding them takes time, which might risk us not hitting our schedule.
- Also, we have to manage larger log files on our production systems. Too much logging is just noise, and makes it harder to figure out what went wrong. This increases the risk that our software is less transparent in how it works.
So, it's a trade-off: continue adding logging statements so long as you feel that overall, the activity pays off reducing overall risk.
Example 2: Do The Simplest Thing That Could Possibly Work
Another mantra from Kent Beck (originator of the Extreme Programming methodology), is "Do The Simplest Thing That Could Possibly Work", which is closely related to YAGNI and is an excellent razor for avoiding over-engineering.
At the same time, by adding "Could Possibly", Beck is encouraging us to go beyond straightforward iteration and use our brains to pick apart the simple solutions, avoiding them if we can logically determine when they would fail.
Our risk-centric view of this strategy would be:
- Every action you take on a project has its own Attendant Risks.
- The bigger or more complex the action, the more Attendant Risk it'll have.
- The reason you're taking action at all is because you're trying to reduce risk elsewhere on the project.
- Therefore, the biggest Payoff is likely to be the one with the least Attendant Risk.
- So, usually this is going to be the simplest thing.
So, "Do The Simplest Thing That Could Possibly Work" is really a helpful guideline for Navigating the Risk Landscape, but this analysis shows clearly where it's left wanting:
- Don't do the simplest thing if there are other things with a better Payoff available.
An example of where this might be the case, think about how you might write a big, complex function (I'm thinking of a function to process interest accrual), but pick your own example). The simplest thing might be to just write a single function and a few unit tests for it. However, a slightly less simple thing that would work might be to decompose the function into multiple steps, each with its own unit tests. Perhaps you might have a step which calculates the number of days where interest is due (working days, avoiding bank holidays), another step that considers repayments, a step that works out different interest rates and so on.
Functional decomposition and extra testing might not be the simplest thing, but it might reduce risks in other ways - making the code easier to understand, easier to test and easier to modify in the future. So deciding up-front to accept this extra complexity and effort in exchange for the other benefits might seem like a better Payoff than the simplest thing.
Example 3: Continue Testing or Release?
You're on a project and you're faced with the decision - release now or do more User Acceptance Testing (UAT)?
Obviously, in the ideal world, we want to get to the place on the Risk Landscape where we have a tested, bug-free system in production. But we're not there yet, and we have funding pressure to get the software into the hands of some paying customers. But what if we disappoint the customers and create bad feeling? The table below shows an example:
| Risk Managed | Action | Attendant Risk | Payoff |
|---|---|---|---|
| Funding Risk | Go Live | Reputational Risk, Operational Risk | MEDIUM |
| Implementation Risk | Another Round of UAT | Worse Funding Risk, Operational Risk | LOW |
This is (a simplification of) the dilemma of lots of software projects - test further, to reduce the risk of users discovering bugs (Implementation Risk) which would cause us reputational damage, or get the release done and reduce our Funding Risk by getting paying clients sooner.
Lots of software projects end up in a phase of "release paralysis" - wanting things to be perfect before you show them to customers. But sometimes this places too much emphasis on preserving reputation over getting paying customers. Also, getting real customers is meeting reality and will probably surface new hidden risks that are missing from the analysis.
The important take-away here is that you don't have to accept the dilemma as stated. You can change the actions to improve the payoff, and meet reality more gradually:
- Start a closed beta test with a group of friendly customers
- Use feature toggles to release only some components of the software
- Dog-food the software internally so you can find out whether it's useful in its current state.
The diagram above shows our decision as moves on the Risk Landscape. Whether you "Go Live" first, or "UAT" first makes a difference to where you will end up. Is there a further action you can take to get you from the "Dead End" to the "Goal"? Perhaps.
Parting Ways With Agile
In reality, payoff is made more tricky because often the actions you take might depend on each other, the payoff might not be immediate and (unlike making a bet in the real world) you can't be certain what the payoff will be in advance. Nevertheless, this is a really useful concept in software engineering because it clarifies the decision you're making.
Many Agile frameworks such as Scrum place a lot of emphasis on estimating and time-boxing work: trying to work out when you're going to deliver something and sticking to it. But Risk-First is suggesting a totally different focus: factors like time taken to deliver and coordinating the completion of work are just risks to consider along with all the others.
The most valuable project management skill is being able to chart a course which minimises risk. Sometimes, that will mean hitting a deadline, but equally it could be reducing codebase complexity, making a feature more accessible or removing problematic dependencies.
The most important skill is to be able to weigh up the risks and decide which course of action gives you the greatest payoff.
And in order to make the most of payoff, first you need to make sure you're tracking those risks in the first place.