Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What I Learned From Burning Down My House

39,514 views

Published on

This presentation is about what I learned from when my house burned down.
The presentation is elling the story of a sense of urgency, but targeted at (agile) software development

Published in: Business, Technology

What I Learned From Burning Down My House

  1. 1. What I learned from burning my house…<br />A Sense of Urgency<br />Robin Dymond<br />Innovel<br />Yves Hanoulle <br />PairCoaching.net<br />
  2. 2. About()<br />Yves Hanoulle<br />Robin Dymond, CST<br />Change Consultant<br />Training, Coaching & Consultancy Services <br />on agile & Team practices<br />in EMEA. <br />Trainer, Management Consultant and Coach<br />Training, Coaching organizations on Scrum, Agile and Lean.<br />Certified Scrum Trainer<br />2<br />
  3. 3. You.About(1 minute)<br />Who are you?<br />What makes you different?<br />What would be the successful outcome of this talk for you?<br />3<br />
  4. 4. Agenda<br /><ul><li>Intro
  5. 5. Complacency
  6. 6. False sense of Urgency
  7. 7. True sense of Urgency
  8. 8. Bring the outside in
  9. 9. Behave with Urgency every day
  10. 10. Find the opportunities in a crises
  11. 11. Dealing with NONO’s
  12. 12. Keep the urgency up</li></ul>4<br />
  13. 13. Model, you apply it, our experience<br />5<br />
  14. 14. Referee Cards<br />6<br />
  15. 15. Why are we are here?<br />Kotter: 70% of change efforts fail.<br />Womack: few companies adopting Lean become Lean organizations<br />Organizations are struggling with transitioning to Agile<br />The problem of change is a universal issue<br />It’s about creating Learning organisations<br />7<br />
  16. 16. Intro I: 1991/08/01 19:36<br />8<br />
  17. 17. Intro II<br />9<br />
  18. 18. Intro III<br />10<br />
  19. 19. Notes 1<br />What were the ramifications of this devastating fire? For you, for the family? What did you lose? What did it cost?<br />How does this accident relate to you? <br />Were you complacent? Was it just an accident? How did it change you?<br />11<br />
  20. 20. Complacency<br />12<br />
  21. 21. Complacency<br />13<br />
  22. 22. Complacency<br />Wiktionary:<br />A feeling of contentment or self-satisfaction , especially when coupled with unawareness of danger or trouble<br />Merriam-Webster:<br />a feeling of being satisfied with how things are and not wanting to try to make them better : a complacent feeling or condition<br />14<br />
  23. 23. Complacency<br />15<br />
  24. 24. What is Complacency in Software development?<br />16<br />
  25. 25. Complacency<br /><ul><li>Manual build
  26. 26. Manual testing
  27. 27. Not updating practises/Technology
  28. 28. Solo programming
  29. 29. Not fixing failing build
  30. 30. Complicated proces with # steps without value
  31. 31. “That’s the way we work here”
  32. 32. Not changing the organisation
  33. 33. Blame the messenger</li></ul>17<br />
  34. 34. False Urgency<br />18<br />
  35. 35. What is False Urgency in Software development?<br />19<br />
  36. 36. False Urgency<br /><ul><li>Many meetings
  37. 37. Heavy process with many approvals
  38. 38. Detail estimates for detailed requirements
  39. 39. Overtime for months
  40. 40. Many more meetings
  41. 41. Over assigning work to ensure everyone is 100% active
  42. 42. Check the hours instead of the results
  43. 43. Micro management
  44. 44. Adrenaline Junkies
  45. 45. E-mail, twitter, phone</li></ul>20<br />
  46. 46. True urgency<br />21<br />
  47. 47. True Urgency<br />22<br />
  48. 48. Quadrant of Effective People<br />TrueUrgency<br />False Urgency<br />23<br />
  49. 49. Bring the outside in<br />24<br />
  50. 50. What is Bring the outside in in Software development?<br />25<br />
  51. 51. Bring the outside in<br /><ul><li>Visit your competitors
  52. 52. Learn ideas from other industries (lean)
  53. 53. Walk a mile in your customers shoes
  54. 54. Use your own software (Eat your own dogfood)
  55. 55. Information Radiators all around the company
  56. 56. Hire consultants
  57. 57. Become a student
  58. 58. Read books
  59. 59. Go to a conference
  60. 60. Rotate people between teams</li></ul>26<br />
  61. 61. Behave with urgency every day<br />27<br />
  62. 62. What is Behave with urgency every day in Software development?<br />28<br />
  63. 63. Behave wih urgency every day<br /><ul><li>Prioritized Product backlog
  64. 64. Daily Stand up
  65. 65. Limiting Work In Progress
  66. 66. Removing impediments
  67. 67. Sun does not set on a defect
  68. 68. Continous improvement
  69. 69. Stop the line
  70. 70. What’s the bottleneck today?
  71. 71. Measure time to market</li></ul>29<br />
  72. 72. Crisis Coach<br />30<br />
  73. 73. Find opportunities in a crises<br />31<br />
  74. 74. Open Vulcano Conference<br />32<br />
  75. 75. What is Find opportunities in a crises in Software development?<br />33<br />
  76. 76. Find opportunities in a crises<br />Challenger Explosion  Reorg NASA<br />Netscape problems  Mozilla<br />Music Piracy  iPod + iTunes<br />Late overbudget Projects  agile <br />Bug  First Unit test then fix<br />Building software is hard  automate build<br />Retrospectives<br />1 common enemy  Unites people<br />Limited budget  higher focus on value<br />34<br />
  77. 77. Orlando<br />35<br />
  78. 78. NONO’s<br />36<br />
  79. 79. Ignore/co-opt<br />37<br />
  80. 80. Fire NONO’s<br />38<br />
  81. 81. Keep NONO’s Distracted and Busy<br />39<br />
  82. 82. Deal with NONO’s<br />What is Keep them busy in Software development?<br />40<br />
  83. 83. Keep the NONO’s busy<br />we don’t think this works in agile<br />41<br />
  84. 84. Identify the nono<br />42<br />
  85. 85. Deal with NONO’s<br />How can we identify the nono in Software development?<br />43<br />
  86. 86. Deal with NONO’s: Identify the nono<br />Explain what is a NONO<br />Make their behavior transparent to everyone<br />Use social accountability and peer pressure to align<br />Team:<br />Self-organisation<br />Pair-Programming<br />Co-located teams<br />Organisation:<br />Education<br />Raising Impediments<br />Information Radiators<br />44<br />
  87. 87. Prime Directive<br /> Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.<br />At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgment used to embarrass.<br />45<br />
  88. 88. Keep urgency up<br />46<br />
  89. 89. How can we Keep the Urgency up in Software development?<br />47<br />
  90. 90. Keep Urgency Up<br />What is the Bottleneck today?<br />Feedback<br />Retrospectives<br />Stop The Line<br />Customer collaboration<br />Continuous Improvement<br />Eliminating non value work<br />Daily Standup<br />Burndown charts<br />Demos<br />Continuous Deployment<br />48<br />
  91. 91. Rate of change in business is increasing<br />49<br />
  92. 92. Leading Change<br />A sense of urgency<br />The guiding team<br />Visions and strategies<br />Communication<br />Empowerment<br />Short-term wins<br />Never letting up<br />Making Change stick<br />50<br />
  93. 93. Sources<br />http://www.librarything.com/catalog.php?view=YvesHanoulle<br />51<br />
  94. 94. Free Lifetime support<br />Innovel LLC<br />PairCoaching.net<br />Yves Hanoulle<br />Blog, Twitter, Slides, Books, Pictures <br />http://www.hanoulle.be<br />Mail : Mailing at Paircoaching dot net<br />Mobile: +32 476 43 38 32<br />Skype: YvesHanoulle<br />More? Google me<br />Free life time:<br /> My life not yours ;-)<br />Robin Dymond<br />rdymond@innovel.net<br />www.innovel.net<br />www.scrumtraining.com<br />Americas: (804) 239-4329<br />Europe: +32 489 674 366<br />52<br />
  95. 95. Благодарю!<br />&<br />Дякую!<br />53<br />

×