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.