Jeremy Jarrell

Agile Made Simple

Tag: lean

Stop Doing Experiments and Start Making Bets

Many teams have embraced the experiment mindset, which teaches that you can learn more from simply trying out an idea and seeing the results than you would ever learn from…

Many teams have embraced the experiment mindset, which teaches that you can learn more from simply trying out an idea and seeing the results than you would ever learn from intense upfront analysis.

While this mindset can help your team make rapid gains, there’s also a dark side to this approach.  Although experimentation can yield faster and more in-depth learning than traditional analysis, many teams forget that some initial lightweight analysis can also be useful for helping them choose those experiments that are the most likely to succeed.  As a result, these teams embark upon poorly planned and risky experiments without first considering what they stand to gain…or lose.

The root of the problem lies in the word “experiment”.  By their nature, experiments can be very open ended.  This can make them a bad model for change since the lack of a defined end state can lead to a lack of clarity on how to proceed, or even a lack of understanding of what the team stands to gain from the experiment.

Playing the Game

A better model is a bet.  Imagine playing a game of poker but with no chips.  Without a need to commit chips then each hand becomes nothing more than a simple experiment with no potential upside or downside.  This means that you could play forever and still have no real investment in the game.

But adding chips to the hand changes the game.  When you’re working with a finite amount of chips you start to become very aware of the real possibility of gain and the real possibility of loss that hides in each hand.  

This forces you to weigh your options much more carefully.

Watch a great poker player play the game and you may be surprised at what you see.  Great poker players don’t play every hand…in fact, many even sit out more hands than they actually play.

Why?  Because great poker players know that they have a finite amount of chips and, if they want to play the game long enough for that big pay out, then they need to protect the chips they have.  This means that they evaluate each hand at the outset and decide if it’s a hand they stand a chance at winning.  If they’re not likely to win, then they simply bow out and wait for a better opportunity.  This is because they know that every hand has a cost, and the more bad hands that they pass on, the more likely they’ll still be in the game when those truly great hands come along.

Betting on Change

So should you abandon experiments altogether?  Not so fast.  A true embracement of an experiment mindset is one of the hallmarks that separates the best teams from the mediocre ones.  The difference, is that rather than simply diving headfirst into every opportunity, the best teams evaluate each of the possible experiments on their plates and choose to focus on those experiments that have the most potential for a positive upside, given the investment they’ll need to make.

For example, imagine that during the most recent retrospective your team complained that their Product Owner is not easily accessible throughout the sprint to provide feedback or clarification on items that are in progress.  As a result, your team has repeatedly found themselves reviewing items at the Sprint Review that turned out to not be what the Product Owner had in mind.  This means that they’ve had to invest additional time in the next sprint to rework those items, which has slowed the team down as a whole.

After a few minutes of brainstorming your team comes up with several experiments they could run which could help address the problem.  For example, maybe the Product Owner could appoint a proxy Product Owner on the team that would be empowered to provide feedback and make decisions on the Product Owner’s behalf whenever he’s unavailable.  Or, perhaps the Product Owner could make more of an effort to attend the team’s standup whenever possible so he’s available to provide feedback to the team as items are complete.  Of, maybe he could even keep regular “office hours” in the team room so he’s more accessible to the team a few days per week.

Placing the Right Bet

Any of these options could be worth pursuing, and when each is considered as an experiment they all look equally promising.  It’s only when we look at these options through the lens of making a bet do the tradeoffs between each become more clear.

The table below demonstrates a simple framework for evaluating different experiments through the lens of a bet.

Bet Potential Upside Potential Downside Odds of Success 
Proxy Product Owner Quick response to questions

Proxy may provide wrong responses leading to future rework

Proxy role becomes a distraction from that team member’s responsibilities

Unlikely
Product Owner attends standups

Slightly more availability to team

Quicker response to questions, if asked during standup

Greater impact on Product Owner’s time Possible
Product Owner office hours

Tighter collaboration with team

Quicker response to questions

Less impact on Product Owner’s time

Different way of working for Product Owner Likely

When a team starts to look at experiments through the lens of a bet, not only does the potential for gain become clearer, but they also better understand the investment that they’ll need to make to carry out each experiment.  This can help them better separate those experiments that are likely to fail from those that have a better chance of success so they’ll know where to focus their efforts.

Knowing the Cost

An experiment mindset can be a powerful tool for teams who desire to improve their way of working.  But, while experiments may appear to be free, few truly are.  Most experiments carry with them very real costs, but by evaluating the potential for loss or gain of each your team can focus on those experiments with the greatest likelihood for success…meaning that they’ll be around to play the game for a long time to come.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Stop Doing Experiments and Start Making Bets

No deadline. No ship. It’s that simple.

If you want to ship your product then you have to set a deadline.

When I was a kid, my big sister and I were addicted to a show called “Out of This World”.  The show revolved around a Evie, a young girl with an alien for an estranged father, who could freeze time simply by pressing her index fingers together.  I don’t have to tell you that this is the type of concept that takes hold in the mind of an 8 year old and never lets go.  I also don’t have to tell you that I spent countless hours in my room pressing my fingers together hoping that ‘maybe this time’ time would freeze for me.

NoDeadlineNoShip

As I’ve gotten older, obviously I’ve realized the fallacy of this idea.  The idea that a race of aliens (the Antareuns, I believe) who are capable of freezing time could ever develop interstellar travel is ludicrous.

You see, interstellar travel would be a huge technological achievement, even for the race of extra-terrestrial swingers that existed in the show.  An achievement so large, in fact, that it could have only been wrought by the constant pressure of deadlines.  The problem, however, is that deadlines and time pressure would be meaningless to a race that could freeze time on a whim.  Why march towards a ship date when you can just freeze time until it’s ready?  What forces the tradeoff between delivery and functionality when you can simply freeze time until all of the functionality is done?  You see, as technologically advanced as the Antareuns were they lacked one crucial piece of knowledge that we learned in software long ago:  if you don’t have a deadline, you’ll never ship.

Without the pressure of a hard deadline features will creep, schedules will slip and a released product yours will never be.  Part of the reasoning behind this comes back to an idea known as Parkinson’s Law.  Parkinson’s Law succinctly states: Work expands so as to fill the time available for its completion.  What this means in a nutshell is that regardless of the true time required for a task, however much time you schedule for the task is how long that task will take.  Do you have a 1 week feature on the schedule for 2 weeks?  Then that feature will take 2 weeks.  How about that 30 minute meeting scheduled for 1 hour?  Congratulations, you just bought yourself a 1 hour meeting.  Like water, any task will invariably expand to fill the time allotted for it.

So what happens when you have a task without a deadline?  Then that task has an infinite amount of time allotted for it, and thus, that task will never be completed.  If you want to ship your product then you have to set a deadline.  No, your product won’t be done at arrival of your deadline.  It won’t have all of the bells and whistles you so desperately believe that your customers need and it won’t have that last 0.999% of polish that it would be unthinkable to release without.  However, guess what: your competitor’s product won’t be done yet either but it’ll already be in the market.  And if their product is all your customers are going to see, then all of the polish in the world won’t save you.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on No deadline. No ship. It’s that simple.

Type on the field below and hit Enter/Return to search