A scrum team has many decisions to make, all the time. Should we focus on usability or new features? Should we fix the bugs that are driving our current customers crazy or develop the new features that will help us land the next big customer? Should we use PHP or Ruby on Rails? There is a lot of pressure to make the best decision, the choice that results in the most valuable result. Something many people miss, is that when we make the decision will often impact the value of the result. Should we make the decision now? Or wait a bit and keep our options open? One of the sessions I led at Agile Open Northwest was titled “When Should We Decide?” and it examined this very question.
We explored the idea, using a simple casino game. Each player places a single $2 bet on the outcome of two coin flips. The choices are: heads-heads, heads-tails, tails-heads, and tails-tails. If the player guesses right, the house pays $8, otherwise the player is paid nothing.
We had 20 people playing the game. Each player started with $20, and played 10 rounds. At the end of this, we totaled up how much money each player had left. Some were winners, some were losers–one poor soul actually managed to lose all 10 rounds—but the average result was almost exactly $20. On average, the players broke even.
Then we changed the rules of the game. The player was still betting on the final outcome of two coin tosses, but now they only made a $1 bet before the first coin was tossed. Once they knew the outcome of the first coin toss, they placed another one dollar bet, selecting any one of the four possible outcomes. The payout was the same as before: for each dollar bet on the correct outcome, the player received four dollars. After 10 rounds under the new rules, the players did much better. The average stack of money in front of a player at the end of this round was $33.
What ensued was a great discussion about why the players did so much better the second time. By delaying the decision of how to bet the second dollar, the player made that decision with more information: they already knew the result of the first flip. With this additional information, the player is able to make a better decision. As it turns out, our casino game has a lot in common with the Monty Hall Problem.
By definition, plans and decisions that we make early are made with less information than those we make later. If we can delay those decisions, then we can make better-informed choices. Think about release planning in waterfall. We planned a whole release, perhaps 12 – 18 months of work, up front. Those plans rarely worked out well; we were making all our bets before the first coin was tossed.
A scrum team, on the other hand, spreads their planning out over the course of the release. Every week or two, they plan a sprint, and revise their release plan. They also revise their product plans and their technical designs. By delaying decisions, the scrum team gets the benefit of all that has been learned since the start of the project, and can incorporate this knowledge into their decision-making. The result is better schedules, architectures, and products.
An interesting topic that came up in our discussion was the myth of indecision: the idea that it shows character to commit early and then stick to your guns no matter what. We see this in politics all the time, if a candidate changes their mind about an issue they are often accused of being wishy-washy, or a weak leader. Perhaps all they are doing is revising their position to reflect the latest information and learning.
We also talked about the fact that many decisions can’t be delayed indefinitely without losing value or increasing risk or penalty. My friend Llewellyn Falco had a great example: He wanted to attend Agile Open Northwest, but he waited too long to register; the conference had sold out. In this case, the longer he delayed the decision to register, the greater the risk that he wouldn’t be able to register at all. Another example of this is the pricing for the Certified Scrum Master and Certified Scrum Product Owner workshops that Agile Learning Labs puts on. We offer early bird discounts. If a student waits too long to sign up, they lose the opportunity to get the discount. Llewellyn’s story has a happy ending, as he got in when someone else canceled.
Funny how it all seems to come back to a classic agile idea: It is best to make decisions at the last responsible moment.
Cheers,