Being agile while standing in a waterfall

314 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
314
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Being agile while standing in a waterfall

  1. 1. Being agile while standing in a Waterfall Mike Edwards mike@leanintuit.com Twitter: @mikeeedwards Blog: www.mikeeedwards.ca References: agilewaterfall.ca Wednesday, 23 October, 13
  2. 2. Agile will fail at my workplace because of ... • • • • • • • • • • • The concept of dedicating to one task at a time is not supported Because of our culture They won’t change Of me It’s counterintuitive and hard to practice Too focused on mechanics Ridiculous product owners What we do already works Not everyone on our team understands it We only fund capital projects My boss who manages with fear ( Taken from Agile 2013 ) Wednesday, 23 October, 13
  3. 3. Agenda Stories What worked for me Views & experiences Where to from here Wednesday, 23 October, 13
  4. 4. Does Waterfall work? Wednesday, 23 October, 13
  5. 5. I SYSTE M I ANALYSIS PROGRAM DESIGN I coo,.o TESTING I OPERATIONS Figure 2. Implementation steps to develop a large computer program for delivery to a customer. I believe in this concept, but the implementation described above is risky and invites failure. The “I believe in this concept, but the implementation described above is risky and invites failures” -Winston Royce (August 1970) problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are Wednesday, 23 October, 13 violated. Either the requirements must be modified, or a substantial change in the design is required. In effect
  6. 6. Computing: Then & Now IBM System/360 Wednesday, 23 October, 13
  7. 7. What is Agile? Wednesday, 23 October, 13
  8. 8. Saying you do one of these ... XP RAD FDD SAFe Scrum Agile Lean RUP Kanban Wednesday, 23 October, 13 DSDM DAD Crystal
  9. 9. ... is like carrying one of these Wednesday, 23 October, 13
  10. 10. Story time! Wednesday, 23 October, 13
  11. 11. Once upon a time ... • Final component of a larger program • Estimated at 1200 days • Drop dead date of 3.5 months • Highly visible if we failed • Core team assigned of 5 IT people • Waterfall was all we knew Wednesday, 23 October, 13
  12. 12. Go! • 15 contractors in the door within 2 weeks • Secured a team room • Broke the work out into projects • Developed a mantra: “Failure is not an option” • Strong executive sponsorship Wednesday, 23 October, 13
  13. 13. The Result! • Delivered on the date we said we would • Actuals came in $8000 under budget • Delivered all key scope items • No significant quality issues after go-live • Happy customer! Wednesday, 23 October, 13
  14. 14. Another story! Wednesday, 23 October, 13
  15. 15. The situation • Towards end of a larger troubled project (we kept dropping scope) • Team only available for 3 more months • Budget defined by available people and time • Low key enhancement project • Waterfall was best described as a religion Wednesday, 23 October, 13
  16. 16. Go! • Secured a war ‘area’ • Given free reign to ‘try something different’ • Simple one sentence scope statement • No authority to NOT do something in the department’s process • Executive sponsorship watched closely Wednesday, 23 October, 13
  17. 17. The Result! • Finished early • Finished slightly under budget • Features delivered exceeded customer expectation • No quality issues after go-live • Happy customer! Wednesday, 23 October, 13
  18. 18. Ideas for being Agile? Wednesday, 23 October, 13
  19. 19. Describe the characteristics of a successful project? Wednesday, 23 October, 13
  20. 20. Start with the Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Wednesday, 23 October, 13
  21. 21. Ideas Make it about principles Wednesday, 23 October, 13
  22. 22. Post-Mortem Wednesday, 23 October, 13
  23. 23. Learning vs. Improving We can learn the mechanic didn’t latch the cowling Feel better? What does it mean to improve? Wednesday, 23 October, 13
  24. 24. Improve how you Improve • Conduct regular retrospectives throughout the project • • Empower teams to improve • Make improvement an objective for teams Wednesday, 23 October, 13 Make room for ongoing improvements
  25. 25. Ideas Make it about principles Conduct regular Retrospectives & Improve Wednesday, 23 October, 13
  26. 26. People • • • • • • Support those who deliver value Motivate them Trust them Create sustainable pace Foster responsibility Have fun! Wednesday, 23 October, 13
  27. 27. CHRISTOPHER AVERY & THE LEADERSHIP GIFT The Responsibility Process™ RESPONSIBILITY OBLIGATION QUIT SHAME JUSTIFY LAY BLAME DENIAL ChristopherAvery.com ©1991-2012. International trademarks and copyrights apply. Leadership Gift™ is a trademark of Christopher Avery. Responsibility Process™ and Keys to Responsibility™ are trademarks of Christopher Avery and Bill McCarley. Permission is hereby granted to duplicate and distribute only in its entirety without changes or deletions. Wednesday, 23 October, 13
  28. 28. The 5 dysfunctions of a team Wednesday, 23 October, 13
  29. 29. Collaborate! • • • • • • Examine the value of your weekly status meetings Tear down the walls Eliminate the hierarchy Make information visible Build a cross functional team Build a high performing team Wednesday, 23 October, 13
  30. 30. Ideas Make it about principles Conduct regular Retrospectives & Improve Create a high performing team Wednesday, 23 October, 13
  31. 31. Why do we schedule? Wednesday, 23 October, 13
  32. 32. An ineffective schedule An effective schedule? Wednesday, 23 October, 13
  33. 33. Schedule Wednesday, 23 October, 13
  34. 34. Ideas Make it about principles Conduct regular Retrospectives & Improve Create a high performing team ‘Deliver’ frequently Wednesday, 23 October, 13
  35. 35. “The customer just asked for a couple changes” Wednesday, 23 October, 13
  36. 36. Why do we need Change Management? Decisions are made prematurely! Our customers cannot possibly know what they want in detail at the start of a project Wednesday, 23 October, 13
  37. 37. Scope  O In Scope   Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah  Blah blah blah blah  Blah blah blah blah blah blah blah blah  Blah blah blah blah blah blah blah  Blah blah blah blah blah blah blah  Blah blah blah blah blah blah blah blah blah blah blah blah blah   Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Out of Scope   Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah  Blah blah blah blah  Blah blah blah blah blah blah blah blah  Blah blah blah blah blah blah blah  Blah blah blah blah blah blah blah  Blah blah blah blah blah blah blah blah blah blah blah blah blah  Wednesday, 23 October, 13 Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah
  38. 38. Scope Scope Statement   Wednesday, 23 October, 13 In Scope  Add a feature <to the system> and supporting functionality Out of Scope
  39. 39. Delay decisions to the last responsible moment • User stories and user story maps User Story format: As a <user>, I want <some goal>, so that <some reason> Wednesday, 23 October, 13
  40. 40. Scope Scope Management Front Burner User Stories Wednesday, 23 October, 13 Back Burner Fridge Freezer
  41. 41. What can you do about change? Embrace it! Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. (Agile Manifesto - Principle #2) Create an environment allowing everyone to learn Wednesday, 23 October, 13
  42. 42. Ideas Make it about principles Conduct regular Retrospectives & Improve Create a high performing team ‘Deliver’ frequently Defer decisions until the last responsible moment Wednesday, 23 October, 13
  43. 43. How do you report status? a.k.a.: Navigating through the rear window Wednesday, 23 October, 13
  44. 44. Status Reporting • Start ALL projects red • Check the politics at the door • Honesty & Transparency • Put your status on the wall • Build plans allowing for clearer reporting Wednesday, 23 October, 13
  45. 45. Ideas Make it about principles Conduct regular Retrospectives & Improve Create a high performing team ‘Deliver’ frequently Defer decisions until the last responsible moment Keep status reports transparent and real Wednesday, 23 October, 13
  46. 46. Tracking Progress Critical Path Actual vs Target Hours 15 Hours 11 Burn up 8 Actual vs projected total 600 4 450 0 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr Daily burn 12-Apr 19-Apr 300 150 0 8-Mar11-Mar 15-Mar 19-Mar 23-Mar 27-Mar 31-Mar 3-Apr 6-Apr 9-Apr 12-Apr15-Apr18-Apr21-Apr 9-Mar12-Mar 16-Mar 20-Mar 24-Mar 28-Mar 1-Apr 4-Apr 7-Apr 10-Apr13-Apr16-Apr19-Apr22-Apr 10-Mar 14-Mar 18-Mar 22-Mar 26-Mar 30-Mar 2-Apr 5-Apr 8-Apr 11-Apr14-Apr17-Apr20-Apr23-Apr 13-Mar 17-Mar 21-Mar 25-Mar 29-Mar Wednesday, 23 October, 13
  47. 47. Measurements Time sheets Schedule Accuracy Be careful what you measure ... COBIT You might just get it! OPM3 CMMI Wednesday, 23 October, 13 ITIL
  48. 48. The importance of timeliness! Hermann Ebbinghaus Wednesday, 23 October, 13
  49. 49. Some words of wisdom a.k.a. Things I’ve learned the hard way Wednesday, 23 October, 13
  50. 50. Things I’ve learned • Culture cannot be changed - change how the work is done and culture will follow • Start from where you are today and never be satisfied • • • • Improve the whole Wednesday, 23 October, 13 Improve one step at a time Iterate (Build Measure Learn) Have fun!
  51. 51. Thanks! For more Information: http://agilewaterfall.ca http://bit.ly/VKyFD5 Stay in Touch! Mike@leanintuit.com Twitter: @mikeeedwards Blog: www.mikeeedwards.ca Wednesday, 23 October, 13 My upcoming LeanPub book: Being agile while standing in a waterfall!

×