Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (14)
Similar to Real Options: How and When (not) to take Decisions
Similar to Real Options: How and When (not) to take Decisions (20)
More from AgileCoach.net
Recently uploaded
Recently uploaded (20)
Real Options: How and When (not) to take Decisions
- 1. Real Options: how and when (not) to make decisions Pascal Van Cauwenberghe
- 2. Consults Manages projects Programs Creates games Tells stories Organises conferences@pascalvc http://blog.nayima.be http:/www.xpday.net http:/www.atbru.be
- 4. Once upon a time...
- 5. The project (1) http://www.flickr.com/photos/seandreilinger/2187892869 http://www.flickr.com/photos/rohdesign/3307874546 Video Game Social website
- 7. 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
- 9. The team
- 11. 1. Cost of Delay t €
- 13. Creative Process Problem Generate options Test and choose options Implement Customer Supplier
- 14. Creative Process
- 16. Don’t try to decide too fast
- 17. 2. The Creative Process
- 20. Real Options Team to the Rescue! “Give us a day and we’ll tell you when and how to decide” Olav Chris Chris
- 21. What is the problem? Cost of Delay: a delay (even one day) can cost us 50% of sales
- 22. Real Options Real Options Have a cost (= the price of the option) Have a value 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
- 23. 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
- 24. Comparing our options Option Cost Price Value Expires Blue ??? / Consistent Design ??? Yellow + Blue ??? Blue redesign Cost of Delay == 0 ???
- 25. When do we have to decide? Yellow + Blue option ??? Blue option ??? DecNov Stock shops Oct Produce DVD+box Servers ????March We are here!
- 26. 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.”
- 27. When do we have to decide? Yellow + Blue option ??? Blue option ??? DecNov Stock shops Oct Produce DVD+box Servers AugustMarch We are here! Design and test (2M)
- 28. 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
- 29. 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
- 30. 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”
- 31. When do we have to decide? Yellow + Blue option ??? Blue option ??? DecNov Stock shops Oct Produce DVD+box Servers AugustMarch We are here! Design and test (2M)
- 32. When do we have to decide? Yellow + Blue option ??? Blue option ??? DecNov Stock shops Oct Producte DVD+box Servers SeptMarch We are here! Design and test (1M)
- 33. 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
- 34. Comparing our options Option Cost Price Value Expires Blue 1 week of refactoring + 2h followup / 2 weeks / Consistent Design 01/09/20XX Yellow + Blue 1 week of refactoring + 2h followup / 2 weeks Blue redesign (1 month) Cost of Delay == 0 01/09/20XX
- 35. 3. Real Options Optimal Decision Process Option Implement Option Option Decisions Deadline http://commitment-thebook.com/
- 36. 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:
- 37. And they lived happily ever after
- 38. Another story?
- 39. 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
- 40. 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?
- 41. ImplementNot enough time The problem Platform A Platform B Decision We are here!
- 42. 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…
- 43. Our solution Implement Platform A Finish implementation of chosen platformImplement Platform B Decision We are here!
- 44. Set-based development APP API A Server B Server Test Server 3 parallel implementations: •Platform A •Platform B •Development+test platform
- 45. Retrospective • Decision: platform A • Implementation A in production on time • Dev+Test platform continues to be used • Implementation B was wasted • To be continued...
- 47. 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
- 48. 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
- 49. And they lived happy
- 51. That’s only logical, captain!
- 52. It’s just common sense!
- 55. Sunk Cost Fallacy • Our investment to date is gone • We should not take it into account when deciding if we want to continue • Yet we value money and time spent very highly • Solution: look at the “deltas” of value and cost • “Marginal Economics” (Reinertsen, Flow) • Also: “Emotional Sunk Cost”
- 56. We suck at estimating • We have trouble with absolute values • Use relative estimates to make decisions • We overestimate the costs and underestimate the benefits of changing a decision • Once decided, we fear losing what we have • We overestimate the value of what we have • This confirms that we made a good decision • We overestimate the value of events closer to now (faulty discount function) => We favour short term decisions
- 57. Choice Anxiety • We freeze when there’s too much choice • Many choices, high odds of take the wrong choice • We lose sight of the goal when we have too many options • Spend all our time “chasing options” • Create “generic solutions”
- 58. Above all...
- 59. We don’t like uncertainty • Especially when under stress • These tools help me calm down, slow down • We don’t decide, we plan to decide: • When will we make the decision? • How will we make the decision? • What data will we use? Where/how will we get the data? • Who needs to be involved • => We make decisions quickly and confidently • My favourite tool to manage options: my calendar
- 60. How did you survive this long?
- 61. 6. We’re not rational, but we can fake it
- 62. What is architecture? “Architecture are those decisions that are hard to change and must be taken at the beginning of the project” If the decision is hard to change • Either we make it easier to change • Or we buy an option to move the decision back I’m ready to pay for valuable options • “Yes but… There are some things you can’t change”
- 63. Yes but… Options are too expensive
- 64. Another project (4) • 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... • 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€ • “No. Failure is not an option”
- 65. 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!
- 66. What is the added value for your customer of your architecture and process?
- 67. Useful techniques (1) • Cost of Delay: • What is the (financial) in time for early/late delivery? • Creative Process: • Create options, select options, implement • Options: • Cost, value, price, expiration date/condition • Optimal Decision Process: • Decision point = Deadline – Implementation Time
- 68. Useful techniques (2) • Variation Separation: • Keep items with different rate of variability separate • Set-based design: • Implement many options simultaneously. Choose the best • Sunk Cost Fallacy: • Forget your investment to date • Create options for your customers
- 70. Principle of the right moment Easy to change decision: decide early Hard to change decision: • Make it easier to change • Delay decision date
- 71. 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”
- 72. 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
- 73. “Every seemingly bad situation or decision hides a good decision. You just have to look.”
- 74. Thank you! • If you want to know more pascal@nayima.be http://blog.nayima.be