real options agile tour brussels 2013
DESCRIPTION
Stories about how we used Real Options, Set-Based Design, the Creative Process to make surprisingly good decisions in bad circumstancesTRANSCRIPT
Real Options: how and when
(not) to make decisions Pascal Van Cauwenberghe
Consults
Manages projects
Programs
Creates games
Tells tall tales
Organises conferences @pascalvc
http://blog.nayima.be http:/xpday.net
http:/atbru.be
Agile Open
http://agileopen.net
http://www.cafepress.com/+true-story+mugs
Once upon a time...
The project (1)
http://www.flickr.com/photos/seandreilinger/2187892869
http://www.flickr.com/photos/rohdesign/3307874546
Video Game
Social website
http://www.flickr.com/photos/rohdesign/3307874546
The website
New DESIGN !! L'analyse par les Options Réelles est
une technique qui permet de prendre
des décisions sur les décisions. C'est
cool, c'est meta.
Mais quel est l'intéret pour l'équipe au
quotidien ?
Vous prenez plein de décisions
chaque jour comme développeur ou
architecte. Des décisions qui peuvent
couter cher.
Les Options Réelles ne sont pas très
compliquées, cela s'explique en
quelques minutes. Mais en appliquant
les Options Réelles sur les projets
informatiques et sur l'architecture des
logiciels j'ai découvert que plein de
choses que je croyais vraies ou qui
me semblaient intuitivement
correctes étaient fausses.
J'illustre chaque technique avec des
exemples qui viennent de projets
auxquels j'ai participé les dernières
années, ou bien de la vie de tous les
jours.
Découvrez une autre façon de voir les
décisions, des techniques simples
pour gérer des projets ou définir une
architecture de logiciel. Vous
découvrirez peut-être que vous aussi
croyez des choses qui sont fausses.
Au minimum vous entendrez
quelques histoires belges... :-)
CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES
The NIOUZE
Redesign
de tous les
sites!
Le “vieux” design jaune
sera remplacé par un
design bleu cool, fresh et
clair
Template:
www.presentationmagazine.com
Le Redesign
http://www.flickr.com/photos/rohdesign/3307874546
The team
Estimated sales
t
#
http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg
http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg
1. Cost of Delay
t
€
Previous redesigns
Creative Process
Problem
Generate
options
Test and choose
options
Implement
Customer Supplier
Creative Process
Our Creative Process
Don’t try to decide too fast
2. The Creative Process
http://www.flickr.com/photos/miagant/5203621384
Real Options Team to the
Rescue!
“Give us a day and we’ll tell you when and how to decide”
Olav Chris Chris
What is the problem? Cost of Delay: a delay (even one day) can
cost us 50% of sales
Real Options
Real Options Have a value
Have a cost (= the price of the option)
Have a price (“strike price”) when we exercise the option
Have an expiration date/condition
~ “Call Option”
An option is not an obligation
This is a metaphor
What are our options?
1. Go in production with the (new) blue design • Yes but, we risk delay while we wait for the new design
to stabilize
• Yes but, meanwhile there will be many changes to the
design
2. Go in production with the (old) yellow design, the
redesign with the (new) blue design • Yes but, it won’t be consistent with the other sites
• Yes but, the blue redesign will cost extra time/money
Comparing our options
Option Value Cost Price Expires
Blue Consistent
Design
??? / ???
Yellow +
Blue
Reduced
risk of
Delay
??? Blue
redesign
???
When do we have to
decide?
Yellow + Blue option ???
Blue option ???
Dec Nov
Stock
shops
Oct
Produce
DVD+box
Servers
???? March
We are here!
Questions for the developers
• Do we have to apply the design from the start? • “We’ve always done it like this, but we could do it later”
• How much time to apply the Yellow design? • “Around one month”
• How much time for a complex design? • “Less than two months”
• Imagine the worst design the designers can create • Laughs. “Two months. We’ve got experience with that kind
of design.”
When do we have to
decide?
Yellow + Blue option ???
Blue option ???
Dec Nov
Stock
shops
Oct
Produce
DVD+box
Servers
August March
We are here!
Design
and test
(2M)
How will we decide?
• IF the new blue design is completely stable
• AND if the estimate of the blue design < 2 months
• THEN we use the blue design
• ELSE we use the yellow design AND we’ll plan the
blue redesign once the blue design is stable
• Meeting: August 1st
Meanwhile...
• We develop the site in “black & white”
• One team member participates in the followup
meetings of the new design (2 hours every 2 weeks)
and keeps the team informed of the situation
The day is not done yet
• A few more questions:
• Developers, what changes when the design
changes? • Developers show architecture and code
• What if there was less to change? • Quick architectural “spike”: remove duplication,
separate concerns...
• How much to refactor the site? • “We can do it in a few days”
• “Afterwards, any redesign costs less than 1 month”
When do we have to
decide?
Yellow + Blue option ???
Blue option ???
Dec Nov
Stock
shops
Oct
Produce
DVD+box
Servers
August March
We are here!
Design
and test
(2M)
When do we have to
decide?
Yellow + Blue option ???
Blue option ???
Dec Nov
Stock
shops
Oct
Producte
DVD+box
Servers
Sept March
We are here!
Design
and test
(1M)
The benefits of reducing
cycle time • We can decide another month later
• We have one month more to implement functionality
• The redesign Yellow=>Blue costs 1 extra month, not 2
• New meeting date: September 1st
Comparing our options
Option Value Cost Price Expires
Blue Consistent
Design
1 week of
refactoring
+ 2h followup /
2 weeks
/ 01/09/20XX
Yellow +
Blue
Reduced
risk of
Delay
1 week of
refactoring
+ 2h followup /
2 weeks
Blue
redesign
(1 month)
01/09/20XX
3. Real Options
Optimal Decision Process
Option Implement
Option
Option
Decisions Deadline
http://commitment-thebook.com/
Retrospective
• 1 september: the blue design isn’t stable (no surprise).
We keep using the yellow design.
• Product delivered on time
• “This project was a lot less stressful than usual”
• Functions:
• Design:
Real Options
• Have a Value
• Have a Cost
• Have a Price
• Have an Expiration Date/Condition
• Are not an obligation
• Only decide when you must or have a good reason
• Meanwhile, look for more information and options
And they lived happily ever after
Another story?
The project (2)
http://www.flickr.com/photos/seeminglee/8276505285
p.s. La banque n’est pas HSBC
http://en.wikipedia.org/wiki/File:Rack001.jpg
Internet Banking Internet Banking servers
Your mission, should you
decide to accept it... • Online banking goes live on DD/MM/YYYY
• Company X will develop the frontend
• You need to deliver the backend servers on time
• A few small details...
• We’re still deciding what server platform to use
• We’ve started documenting the DB you have to use
• We’ll start documenting the requirements
• “But start developing, because we don’t have a lot of
time!”
• Would you accept this mission?
Implement Not enough time
The problem
Platform A
Platform B
Decision
We are here!
Our solution
• IF we don’t have enough time to implement either
Platform A OR Platform B
• THEN we implement Platform A AND B
• It’s logical when you think about it…
Our solution
Implement Platform A
Finish
implementation of
chosen platform Implement Platform B
Decision
We are here!
Set-based development
APP
API
A
Server
B
Server
Test
Server
3 parallel implementations:
•Platform A
•Platform B
•Development+test platform
Retrospective
• Decision: platform A
• Implementation A in production on time
• Dev+Test platform continues to be used
• Implementation B was wasted
• To be continued...
And they lived...
Company B acquires A L'analyse par les Options Réelles est
une technique qui permet de prendre
des décisions sur les décisions. C'est
cool, c'est meta.
Mais quel est l'intérêt pour l'équipe au
quotidien ?
Vous prenez plein de décisions
chaque jour comme développeur ou
architecte. Des décisions qui peuvent
couter cher.
Les Options Réelles ne sont pas très
compliquées, cela s'explique en
quelques minutes. Mais en appliquant
les Options Réelles sur les projets
informatiques et sur l'architecture des
logiciels j'ai découvert que plein de
choses que je croyais vraies ou qui
me semblaient intuitivement
correctes étaient fausses.
J'illustre chaque technique avec des
exemples qui viennent de projets
auxquels j'ai participé les dernières
années, ou bien de la vie de tous les
jours.
Découvrez une autre façon de voir les
décisions, des techniques simples
pour gérer des projets ou définir une
architecture de logiciel. Vous
découvrirez peut-être que vous aussi
croyez des choses qui sont fausses.
Au minimum vous entendrez
quelques histoires belges... :-)
CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES
The NIOUZE
Redesign
de tous les
sites!
Le “vieux” design jaune
sera remplacé par un
design bleu cool, fresh et
clair
Template:
www.presentationmagazine.com
A little bit later
• Company B sends a letter to the bank
“Great news! We’ve just acquired company A. All
development on platform A has been stopped. We will
stop support very soon.
Please migrate to platform B.”
• Easy!
A B B
C
And they lived happy
4. Set-based development
Option
A
Option
B
Option
C
That’s only logical, captain!
It’s just common sense!
Predictably Irrational
Predictably Irrational
• Sunk Cost Fallacy • “Never throw good money after bad”
• We can’t estimate absolute values • But relative estimation is OK
• We over-value the value of what we have and over-
estimate the cost of change
• We have a faulty Discount Model (today vs tomorrow)
• We have choice anxiety
• We don’t like uncertainty • “I’d rather have a bad decision than no decision!”
How did you survive this long?
5. We’re not rational,
but we can fake it
Yes but… Options are
too expensive
Another project
• Hard deadline: the EU law changes on 01/01/YYYY • The current system is not compatible with the new law
• We’re building a replacement system
• What happens if we’re too late (cost of delay)?
• Deadline is getting nearer...
The problem
NEW system
We are here!
01/01/XXXX
Can we buy a backup option?
• Shouldn’t we look at backup options?
• Option: ask vendor to estimate cost and last moment
to start work to make current system compatible
• My estimate: option costs < 1000€
A backup option
NEW system
Update old system ?
Decision
We are here!
01/01/XXXX
Implement
NO! “Failure is not an option”
What happened next?
• System is not accepted for production in december
• Company can’t invoice it’s customers
• Every month of delay cost X00.000€
• But we saved a few thousand euros on options!
What have we learned?
• Manage the Creative Process
• See difficult decisions as options
• Don’t decide. Decide when and how to decide
• Sometimes doing everything is the right option • At least for a while
• First consider value, only then cost
• Tools help me calm down in stressful situations with
irrational people (like me)
• Keep it simple: • I manage my options with Google Calendar
Architectural decisions
Everything you learned about
architecture is wrong
“Architecture is all the decisions that have
to be made early because they are
costly to change”
Problem: early in the project you don’t
know enough to make the RIGHT
decision. Anyway, things will change.
Principle of the right moment
Easy to change decision: decide early
Hard to change decision:
• Make it easier to change
• Delay decision date
Minimum effort principle
Don’t do tomorrow’s work today(YAGNI)
AND
Don’t do anything today that makes
tomorrow’s work more difficult
Aka “The laziness principle”
A good architecture…
Creates options for your team; your
organisation and your customer
Creating and maintaining the options is
continuous, daily work in small steps
Otherwise you create legacy systems that
contain fewer and fewer options
“Every seemingly bad
situation or decision
hides a good decision.
You just have to look.”
Mr Nobody
A boy faced with the consequences of choices...
A boy faced with the consequences of choices...
Chooses not to choose
“Mr. Nobody” a movie by Jaco Van Dormael
