Real Options Agile Tour Brussels 2013

3,699 views
3,815 views

Published on

Stories about how we used Real Options, Set-Based Design, the Creative Process to make surprisingly good decisions in bad circumstances

Published in: Business, Economy & Finance
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,699
On SlideShare
0
From Embeds
0
Number of Embeds
1,783
Actions
Shares
0
Downloads
38
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Real Options Agile Tour Brussels 2013

  1. 1. Real Options: how and when (not) to make decisions Pascal Van Cauwenberghe
  2. 2. Consults Manages projects Programs Agile Open http://agileopen.net http:/atbru.be @pascalvc http://blog.nayima.be Creates games Tells tall tales Organises conferences http:/xpday.net
  3. 3. http://www.cafepress.com/+true-story+mugs
  4. 4. Once upon a time...
  5. 5. The project (1) Social website Video Game http://www.flickr.com/photos/rohdesign/3307874546 http://www.flickr.com/photos/seandreilinger/2187892869
  6. 6. The website http://www.flickr.com/photos/rohdesign/3307874546
  7. 7. The NIOUZE CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES 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. Redesign de tous les sites! Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair 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... :-) Template: www.presentationmagazine.com
  8. 8. Le Redesign http://www.flickr.com/photos/rohdesign/3307874546
  9. 9. The team
  10. 10. Estimated sales # http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg t
  11. 11. 1. Cost of Delay € t
  12. 12. Previous redesigns
  13. 13. Creative Process Generate options Test and choose options Problem Customer Implement Supplier
  14. 14. Creative Process
  15. 15. Our Creative Process
  16. 16. Don’t try to decide too fast
  17. 17. 2. The Creative Process
  18. 18. http://www.flickr.com/photos/miagant/5203621384
  19. 19. Real Options Team to the Rescue! Olav Chris Chris “Give us a day and we’ll tell you when and how to decide”
  20. 20. What is the problem? Cost of Delay: a delay (even one day) can cost us 50% of sales
  21. 21. 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
  22. 22. 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
  23. 23. Comparing our options Option Value Blue Yellow + Blue Cost Price Expires Consistent ??? Design / ??? Reduced risk of Delay Blue redesign ??? ???
  24. 24. When do we have to decide? We are here! Yellow + Blue option ??? Produce DVD+box Stock shops Servers Blue option ??? March ???? Oct Nov Dec
  25. 25. 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.” 
  26. 26. When do we have to decide? We are here! Yellow + Blue option ??? Produce DVD+box Design and test (2M) Servers Blue option ??? March Stock shops August Oct Nov Dec
  27. 27. 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
  28. 28. 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
  29. 29. 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”
  30. 30. When do we have to decide? We are here! Yellow + Blue option ??? Produce DVD+box Design and test (2M) Servers Blue option ??? March Stock shops August Oct Nov Dec
  31. 31. When do we have to decide? We are here! Yellow + Blue option ??? Producte DVD+box Design and test (1M) Servers Blue option ??? March Stock shops Sept Oct Nov Dec
  32. 32. 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
  33. 33. Comparing our options Option Value Cost Price Blue Consistent 1 week of / Design refactoring + 2h followup / 2 weeks 01/09/20XX Yellow + Blue Reduced risk of Delay 01/09/20XX 1 week of Blue refactoring redesign + 2h followup / (1 month) 2 weeks Expires
  34. 34. 3. Real Options Optimal Decision Process Decisions Option Option Option http://commitment-thebook.com/ Implement Deadline
  35. 35. 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:
  36. 36. 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
  37. 37. And they lived happily ever after
  38. 38. Another story?
  39. 39. The project (2) Internet Banking http://www.flickr.com/photos/seeminglee/8276505285 p.s. La banque n’est pas HSBC Internet Banking servers http://en.wikipedia.org/wiki/File:Rack001.jpg
  40. 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. 41. The problem We are here! Decision Platform A Not enough Implement time Platform B
  42. 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. 43. Our solution We are here! Decision Implement Platform A Implement Platform B Finish implementation of chosen platform
  44. 44. Set-based development APP 3 parallel implementations: •Platform A •Platform B •Development+test platform API A Server B Server Test Server
  45. 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...
  46. 46. And they lived...
  47. 47. The NIOUZE CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES 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. Redesign de tous les sites! Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair 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... :-) Template: www.presentationmagazine.com
  48. 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! C A B B
  49. 49. And they lived happy
  50. 50. 4. Set-based development Option A Option B Option C
  51. 51. That’s only logical, captain!
  52. 52. It’s just common sense!
  53. 53. Predictably Irrational
  54. 54. 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 overestimate 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!”
  55. 55. How did you survive this long?
  56. 56. 5. We’re not rational, but we can fake it
  57. 57. Yes but… Options are too expensive
  58. 58. 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...
  59. 59. The problem We are here! NEW system 01/01/XXXX
  60. 60. 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€
  61. 61. A backup option We are here! Decision NEW system Update old system ? Implement 01/01/XXXX
  62. 62. NO! “Failure is not an option”
  63. 63. 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!
  64. 64. 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
  65. 65. Architectural decisions
  66. 66. 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.
  67. 67. Principle of the right moment Easy to change decision: decide early Hard to change decision: • Make it easier to change • Delay decision date
  68. 68. 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”
  69. 69. 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
  70. 70. “Every seemingly bad situation or decision hides a good decision. You just have to look.”
  71. 71. Mr Nobody A boy faced with the consequences of choices...
  72. 72. A boy faced with the consequences of choices... Chooses not to choose “Mr. Nobody” a movie by Jaco Van Dormael
  73. 73. Thank you! • If you want to know more pascal@nayima.be http://blog.nayima.be

×