Successfully reported this slideshow.

Lean out your backlog - Lean and Kanban Belgium 2010

1

Share

Upcoming SlideShare
Product Discovery @ Nubank
Product Discovery @ Nubank
Loading in …3
×
1 of 104
1 of 104

Lean out your backlog - Lean and Kanban Belgium 2010

1

Share

Download to read offline

Presentation given by Pascal Van Cauwenberghe at Lean & Kanban Belgium 2010.

Some techniques and methods for Lean and Agile product development.

Presentation given by Pascal Van Cauwenberghe at Lean & Kanban Belgium 2010.

Some techniques and methods for Lean and Agile product development.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Lean out your backlog - Lean and Kanban Belgium 2010

  1. 1. Lean out your Product Backlog<br />Pascal Van Cauwenberghe<br />Nayima<br />
  2. 2. “Here we are now.Entertain us.”<br />Kurt Cobain, American Philosopher<br />
  3. 3. Consultant. <br />Project Manager. <br />Games Maker.<br />His Blog: blog.nayima.be<br />NAYIMA<br />We make play work<br />
  4. 4. And so it begins…<br />We’re going Agile!<br />
  5. 5. Congratulations<br />
  6. 6. What do I do now?<br />
  7. 7. Write User Stories<br />
  8. 8. A Vomit of User Stories<br />
  9. 9. Prioritise User Stories<br />
  10. 10. We need Business Value on each card<br />
  11. 11. HELP!<br />
  12. 12. There has to be a better way<br />
  13. 13. I’d like to have a chat with you about...<br />
  14. 14. 1. Some Business Analysis tools<br />That I’ve used the past 10 years<br />
  15. 15. 2. Tell war stories<br />Projects where we used the tools<br />
  16. 16. 3. Explain why we do this<br />
  17. 17. 3. Explain why we do this<br />Before<br />After<br />
  18. 18. 4. You may have to do some work<br />
  19. 19. 5. Share some more wisdom from American philosophers<br />
  20. 20. Who are your top 3 stakeholders?What is their #1 goal?<br />You have 2 mins <br />to share with your neighbour<br />
  21. 21. Goal Table<br />Stakeholder, n: Role, Team or Organisation involved or affected by the project<br />Goal, n: What a stakeholder wants to achieve<br />Capability, n: Something we need to achieve the goal. Necessary, but maybe not sufficient<br />Test, n: A way to decide if a goal has been achieved<br />Measure, n: A way to determine how close we are to a goal<br />Risk, n: Negative consequences of achieving the goal<br />
  22. 22. A Phone Company<br />
  23. 23. Focus on goals not means<br />
  24. 24. Quantify stakeholder goals<br />
  25. 25. The Logical Thinking Process<br />
  26. 26. The Logical Thinking Process<br />Intermediate Objectives Map<br />Prerequisite/<br />Transition Tree<br />How do we get there?<br />In small steps.<br />What is our goal?<br />What are we missing?<br />Future Reality Tree<br />Current Reality Tree<br />Would that work?<br />What could possibly go wrong?<br />Why don’t we have <br />what we need?<br />Conflict Resolution Diagram<br />What could be done to resolve the <br />underlying fundamental conflict?<br />
  27. 27. Using the Logical Thinking Process<br />Intermediate Objectives Map<br />Current Reality Tree<br />Conflict Resolution Diagram<br />Future Reality Tree<br />Prerequisite/<br />Transition Tree<br />Context Diagram<br />
  28. 28. Phone Intermediate Objectives Map<br />Get request<br />Update billing<br />Add service<br />Perform request<br />Provision service<br />Confirm request<br />How difficult could it be?<br />
  29. 29. A Phone Company<br />
  30. 30. Derive capabilities from goals<br />
  31. 31. Some customers seem to have the phone number of our CEO...<br />
  32. 32. What are the criteria your organisation uses to select and prioritise work?<br />You have 2 mins to share with your neighbour<br />
  33. 33. “Party like it’s 1999”<br />, American Philosopher<br />
  34. 34. It’s 1999<br />While people are getting worried about Y2K…<br />
  35. 35. Project E<br />Goal: Build an online bank that sells mortgage loans in Sweden<br />And then in other European countries<br />Constraint: integrate with Swedish government databases<br />Constraint: 2 developers<br />Constraint: the press conference for the launch is in 2.5 months<br />
  36. 36.
  37. 37. What happened?<br />We launched on time<br />Full-featured frontend<br />Combination of manual and automated processes<br />One country at first, then expanded to Europe<br />All manual processes were automated gradually as customer base grew<br />Money coming in invested in backoffice automation<br />
  38. 38. Good looking frontend<br />Press conference<br />Ease of use<br />Curious customers <br />can ask for quote<br />Integration with Swedish government Databases<br />Implement Swedish Business Rules<br />Expand to other countries<br />Scale number of customers<br />
  39. 39. Business Value Model<br />Diagram of effects<br />What are the important goals?<br />How will we achieve the goals?<br />What are our constraints?<br />This is our strategy<br />This is our definition of value<br />
  40. 40. A Phone Company<br />
  41. 41. For example<br />Leading<br />Lagging<br />Customer satisfaction<br />Successful transactions<br />Reliable process<br />Call center cost<br /># calls<br />Request confirmation<br />Customer loss<br />Regulations<br />
  42. 42. Project Economic Framework<br />
  43. 43. Using the Logical Thinking Process<br />Intermediate Objectives Map<br />Current Reality Tree<br />Conflict Resolution Diagram<br />Future Reality Tree<br />Prerequisite/<br />Transition Tree<br />Context Diagram<br />Business Value Model<br />Plan<br />
  44. 44. Business Value Model == Hypothesis<br />Make reasoning & assumptions explicit<br />Verify regularly and improve<br />
  45. 45. PDCA cycle<br />
  46. 46. Product Development cycle<br />
  47. 47. Create a Business Value hypothesis<br />
  48. 48. Verify and improve your Business Value hypothesis<br />Early and often<br />
  49. 49. “Coin an acronym and you have a profitable consulting business”<br />Dave Nicolette, American philosopher<br />
  50. 50. IDD<br />Irritation Driven Development<br />TM<br />
  51. 51. IDD<br />You heard it here first<br />TM<br />
  52. 52. Everybody participates in building the models<br />
  53. 53. The Kano Model<br />Stupid features<br />Table stakes<br />Linear features<br />
  54. 54. “If I had asked my customers what they wanted, they would have said ‘Faster horses’”<br />Henry Ford, American philosopher<br />
  55. 55. The Kano Model<br />Stupid features<br />Table stakes<br />Linear features<br />Exciters<br />
  56. 56. WOW! I didn’t know you could do that!<br />
  57. 57. “The big print giveth.The small print taketh away”<br />Tom Waits, American philosopher<br />
  58. 58. What could possibly go wrong?<br />
  59. 59. Political risk<br />One type of product is the responsibility of division A<br />Other type of product is the responsibility of division B<br />Division manager bonus is based on revenue of division…<br />
  60. 60. Find one risk of success on your project<br />You have 2 mins to share with your neighbour<br />
  61. 61. What are the dangers of success?<br />
  62. 62. “The chief cause of problems is solutions”<br />Eric Sevareid, American philosopher<br />
  63. 63. “When do we (finally) start writing User Stories?”<br />We thought you were an Agile coach?<br />And can’t we start coding yet?<br />
  64. 64. Writing stories made easy<br />Goal<br />AS A...<br />TO ACHIEVE...<br />I NEED...<br />GOTCHAS<br />Stakeholder<br />Capability<br />Test and <br />measure<br />Risk<br />I KNOW I GOT<br />IT WHEN...<br />TO ACHIEVE ...<br />AS A ...<br />I NEED ...<br />PASSES<br />IT’S DONE WHEN ...<br />TO NOT ACHIEVE ...<br />I NEED ... Another capability<br />
  65. 65. User Story Carpaccio<br />Goal Table<br />Project Level Story<br />Project Level Story<br />Project Level Story<br />Project Level Story<br />Release Level Story<br />Release Level Story<br />Release Level Story<br />Release Level Story<br />Release Level Story<br />Iteration Level Story<br />Iteration Level Story<br />Iteration Level Story<br />Iteration Level Story<br />
  66. 66. Derive detailed stories from goals<br />Step by step<br />
  67. 67. Kanban board<br />TODO<br />BUSY<br />Accept<br />DONE<br />Iteration<br />Release<br />Value<br />
  68. 68. Integrate analysis into your flow<br />From Value to Cash<br />
  69. 69. Help! My developers have gone Kanban!<br />
  70. 70. Conflict Resolution Diagram<br />Prerequisite 1<br />Requirement 1<br />Objective<br />Requirement 2<br />Prerequisite 2<br />
  71. 71. Conflict Resolution Diagram<br />Detailed <br />estimates <br />and plans<br />Reliable long <br />term roadmap<br />Satisfy growing customer base<br />No estimates<br />No planning<br />Be more efficient<br />
  72. 72. How would you solve this?<br />
  73. 73. Conflict Resolution Diagram<br />Detailed <br />estimates <br />and plans<br />Reliable long <br />term roadmap<br />Satisfy growing customer base<br />Assumption: estimating is the only way<br />to determine the cost of a feature<br />No estimates<br />No planning<br />Be more efficient<br />
  74. 74. What if…<br />We didn’t have to estimate to have a cost?<br />We didn’t have to create detailed stories to estimate and plan?<br />But that’s not possible, is it?<br />
  75. 75. Conflict Resolution Diagram<br />Detailed <br />estimates <br />and plans<br />Set budget and<br />Build to budget<br />Reliable long <br />term roadmap<br />Satisfy growing customer base<br />No estimates<br />No planning<br />Be more efficient<br />
  76. 76. Building the roadmap<br />Put stakeholder goals in the roadmap, not features<br />More implementation freedom<br />More meaningful for customers<br />Estimate the value of each goal in the roadmap<br />Decide how much you want to invest to realise the value <br />As a percentage of the capacity of the team<br />Create a roadmap based on value and budget<br />Not cost<br />
  77. 77. Building the roadmap<br />Goal 2<br />Value/<br />Budget<br />Goal 1<br />Value / Budget<br />Goal 4<br />Value/Budget<br />Goal 1<br />Value / Budget<br />Goal 3<br />Value/<br />Budget<br />Release 2<br />Release 1<br />
  78. 78. Implementing the roadmap<br />For each release, the product manager and team decide how to achieve goals, given the budget <br />Don’t have to stick to individual budgets as long as release budget is respected<br />Constraints create a challenge<br />Which leads to more creativity<br />Monitor flow of stories and handle risks<br />
  79. 79. Would you rather haggle…<br />
  80. 80. …or solve problems?<br />
  81. 81. Respectful Challenge<br />
  82. 82. Make it a problem-solving exercise<br />That’s what we’re good at<br />
  83. 83. Keep focus<br />Don’t work on 1000 goals at the same time<br />
  84. 84. Don’t outrun your customers<br />Backlog<br />The Bottleneck<br />The Business<br />Operations<br />Dev team<br />
  85. 85. Don’t outrun your customers<br />The Bottleneck<br />Dev team<br />The Business<br />Operations<br />Backlog<br />6 releases <br />per year<br />2 releases <br />per year<br />
  86. 86. 4 customers are faster than 1<br />The Bottleneck<br />Dev team<br />Backlog<br />Sales<br />Operations<br />Production<br />Finance<br />Audit<br />Customers<br />6 releases <br />per year<br />2 major releases <br />per year per group<br />
  87. 87. We don’t call them “The Business”We call us “We”<br />Dev team<br />Backlog<br />Sales<br />Operations<br />Production<br />Finance<br />Audit<br />Customers<br />6 releases <br />per year<br />2 releases <br />per year per group<br />
  88. 88. Integrate deeply with your customer<br />
  89. 89. Yes, but! No, but!<br />
  90. 90. Commonly heard objections<br />“We’ve spent 6 months on analysis already”<br />“Business Value is impossible to measure”<br />“This is waterfall analysis, it’s not agile”<br />“This is too hard”<br />“Doing this with the whole team is a waste of time”<br />“It’s too structured”<br />
  91. 91. The Phone Company<br />Before<br />Already spent 2 months on analysis<br />Identified 60 features<br />2 years worth of work<br />“We need web-based self-service”<br />Reluctantly agreed to do a few days of analysis training<br />After<br />Only 10 out of those 60 features delivered value<br />Identified 4 new features crucial to the success of the project<br />25% of the value could be delivered within one month; no need for a web application<br />
  92. 92. The Chemicals Company<br />Before<br />Asked consultancy to provide bid<br />Consultants did 3 months of analysis<br />Estimate: 9 months of development<br />Customer asked us for a second opinion<br />After<br />2 weeks to provide bid<br />Estimate: 3 months of development<br />Customer increased value by exchanging features during the project<br />Delivered one day early<br />
  93. 93. The Transport Company<br />Before<br />A new team on their first Agile project<br />Two days of business analysis with the whole team<br />“Aren’t we wasting too much time analysing?”<br />“Why are the developers here?”<br />“When can we start coding?”<br />After<br />In production 3 months earlier than predicted<br />“I can’t believe we already released. Normally we’d still be doing analysis.”<br />Developers came up with a new use for existing data, with large financial and ecological benefits<br />
  94. 94. The Transport Company<br />Before<br />Development teams deliver more, faster thanks to agile methods<br />Real bottleneck is test and deploy: several months between development and deployment<br />Delivering more is making things worse<br />No budget to improve test and deploy<br />After<br />Every agile project has quantified value<br />Cost of deployment delay becomes visible: millions per month<br />Cost of improving test and deploy is insignificant compared to cost of delay<br />Started test and deploy improvement<br />
  95. 95. To summarize<br />These are the only things you need to know to pass the test<br />
  96. 96. Just remember<br />Focus on stakeholder goals, not means<br />Model and measure value<br />Apply the science of product development and systems thinking to generate questions<br />Tap into everyone’s creativity<br />Analyse just-in-time using pull<br />Make it a problem-solving exercise<br />There’s a lot more where this came from<br />
  97. 97. Business Analysis Body of Knowledge (BABOK)<br />International Institute of Business Analysts (IIBA)<br />www.theiiba.org<br />
  98. 98. From the BABOK<br />“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”<br />
  99. 99. The Agile Extension to the BABOK<br />The Agile extension gives guidance on how to perform business analysis on Agile projects<br />Overview available on IIBA website<br />We need your input and review<br />Yahoo group: Agile_BA_Requirements<br />
  100. 100. “I must say I find television very educational. The minute somebody turns it on, I go into the other room and read a book” <br />Groucho Marx, American philosopher<br />
  101. 101. If you want to know more<br />
  102. 102.
  103. 103. Merci<br />Thank You<br />Dank u<br />
  104. 104. If you want to know more<br />www.agilecoach.net<br />www.nayima.be<br />blog.nayima.be<br />

Editor's Notes

  • Portia and Pascal introduce themselves by sharing a bit about their background.
  • How long did the project take?
  • TODO: redraw so that titles are correct
  • TODO: redraw so that titles are correct
  • TODO: redraw so that titles are correct
  • TODO: redraw so that titles are correct
  • ×