Delivering maximum value means being comfortable with unknowns

It’s interesting to observe that a lot of Scrum teams put a heavy focus on what the definition of done should be. A lot of time is spent meticulously ensuring that their customer has thoroughly defined through acceptance criteria what will signify a completed user story.

One element that often gets far less attention than the definition of done, if at all, is the definition of ready. Arguably it carries more importance than defining done because after all, if we don’t know when we should start then we have no chance of knowing when we are finished.

Agreeing as a team what the necessary requirements are before you can comfortably commit to writing your first lines of code is critically important before every project starts. It can be easy, however, to get so caught up on defining what ready means that you start to lose value in what you’re producing. Or worse still, wait and wait for that “perfect moment” to start that you deliver no value at all.

Andy Hiles visualises this perfectly with his graph:

photo1 (11)

Finding the sweet spot is key for maximum value delivery

It reminded me that more often than not, you need to get to a place where you’re comfortable with the unknowns that are ahead rather than try to understand everything before you deem something ready to work on. If your knowledge is too low however, then it’s going to cost a lot for the team to discover the details as they go. Similarly, if you spend too long mitigating the unknowns before you begin, you’ll bleed cost in other ways.

The sweet spot is somewhere in the middle. Know enough to be confident in what you’re about to embark on, but keep some of the decision making for when it needs to be made. Finding a comfortable level of unknowns (and a required base of known knowns) can push creativity and importantly ensure that you’re not waiting too long or wasting valuable time before you start sprinting. A team sat doing nothing is of course delivering no value at all, but comes at a cost all the same.

As a team, it’s important that you find a level of unknowns that you’re all comfortable with – but it is important you find that level and consider any risks that might be associated. For example, if your ideal definition of ready is that a technical specification document is present, but instead you have are solid user stories and technical people who you can ask questions of, ask yourselves if you can deliver value with what you have.

The chances are that you can. The chances are also that if you don’t accept a reasonable level of unknowns, you’ll lose a tremendous amount of potential value along the way.

Context can make all the difference

During a recent Agile training session that I ran, I played one of my favourite exercises with the group – the celebrity cruise ship prioritisation game. For those unfamiliar with the game, the group are presented with a dozen different celebrities who are all on a sinking cruise ship. A single lifeboat can carry one celebrity to safety at a time, and so the group must prioritise these celebrities in some order to decide who gets saved.

The trick is to use a mixture of male, female, young, old, controversial and acclaimed celebrities so that there is no easy way to sort them, often leaving the group in heated debates about the importance of one person over the next. Without giving the group any sort of sorting value (for example, by age) the results can be very interesting and wildly different each time you play the game based on peoples opinions of the celebrities.

Which celebrity has more value?

Which celebrity has more value?

As I knew I was running the same training session in both Cardiff and London, I thought I’d add some regional influence into the mix in the shape of Welsh singing legend, Tom Jones and English football star, Wayne Rooney. I wondered if the two different groups would view them differently because of their national importance.

My pre-training predictions were that the group in Cardiff would put more value on Jones than Rooney. Sure enough, the Cardiff group held Jones in extremely high regard but didn’t really care for Rooney. Surprisingly, however, a week later (and when England had been eliminated from the World Cup), the London group treated Rooney with similar disregard, many commenting on his lacklustre performances in an England shirt.

Perhaps if the same exercise had been run whilst England were still involved in the World Cup and Rooney had scored a hattrick just the day before, the results would’ve been different?

What it did highlight was that context can have a greater influence on the daily decisions we make than we might originally think, especially when prioritising items. We already know that not all project based decisions can be based purely on fact and can often be subjective.

Add in the context bias and it should reinforce why regular backlog grooming is absolutely vital for a healthy Agile project. No matter how much you and your Product Owner think you know about the contents of your backlog, be very aware that what seemed like an absolute high priority last week could now be less important, given its context against the world around it.

It’s just another reason why a more Agile approach to software development should be favoured over waterfall methodologies. Context can change with the flip of a switch. The industry can shift almost instantly and we should be able to shift with it, rather than be locked into a development cycle based entirely off a rigid technical specification document. To use the Rooney example again, it would be a crying shame to continue development on “Wayne Rooney’s World Cup Soccer” iPhone app given his current perceived value amongst his fellow patriots. Using iterative development, we can just swap out the England star to someone who plays for Brazil in the next release.