Iâ€™ve seen a number of common patterns over the years in relation to assumptions. Sometimes using assumptions can be useful, you can proceed with an initiative and begin to make progress and check in on points as they are discovered, since we canâ€™t know everything up front. Other times, assumptions can be downright dangerous and many of those times itâ€™s because we havenâ€™t realised that they are assumptions that need to be validated or invalidated. By validating assumptions, we have a solid information on which to base decisions â€“ without such a foundation our initiatives are destined to crumble and fall.
One of the common patterns Iâ€™ve seen is the use of a â€œBusiness Requirements Documentâ€. This kind of pattern has other manifestations, but essentially it comes at the outset of the imitative and the underlying assumption is that all this work will achieve the outcome. Often there is a lot of complexity in the underlying initiative and itâ€™s too hard to predict exactly what will occur. Indeed, perhaps this is a good general rule â€“ thereâ€™s no way to predict with absolute certainty exactly how your customers / users will react to a change. Thus, our path becomes set with a series of assumptions.
Iâ€™d rather see the word â€œRequirementsâ€ replaced with assumptions that will need to be validated somewhere along the lifecycle. Which leads me to my next point â€“ the lifecycle or the knowledge discovery steps donâ€™t take into account validating those assumptions in the real world. Often, I see Kanban boards like this:
When really, if the team were to add an additional knowledge discovery step along the lines of the following, the team would be prompted that theyâ€™re working with assumptions and they have to think about how theyâ€™re going to validate them:
What often results is that people focus on purely â€œgetting stuff doneâ€ rather than ensuring â€œsomeoneâ€™s need was fulfilledâ€ (I like this â€œDefinition of Doneâ€ from Mike Burrows) â€“ and by that, I mean we know through validation that the need was actually fulfilled. Thatâ€™s being fit for your customers purpose. Thatâ€™s really what we need to be focusing on.
Instead what results is that either we donâ€™t validate that weâ€™ve solved the problem and move on to the next shiny thing, or we have to go back for one or more swings at it. If youâ€™ve got stakeholders that are counting on your promises that youâ€™ll solve their problem the first-time round, then youâ€™ve got a fairly serious stakeholder management issue. Also, what was the opportunity cost of learning this so late? What could we have been doing with the time and money that weâ€™ve spent to invalidate this assumption?
Wouldnâ€™t it be simpler to plan this from the start? In areas of uncertainty and complexity, we really shouldnâ€™t be blind to our assumptions, rather we should be acknowledging we donâ€™t know everything, but we plan to learn as soon as possible. Even if weâ€™re using leading indicators to show weâ€™re heading in the wrong direction this can be better than relying on the assumption to hold.
Donâ€™t be blind to assumptions, they can be useful when they need to be, but often they are not catered for in many systems of work. Itâ€™s not a difficult thing to add the validate step to a board, but changing the behaviours to ensure you really are meeting that customer / user need can take more time. If youâ€™re not validating your assumptions, youâ€™re likely falling behind your competitors who are.