Thinking more product: Moving from Scrum to a dual-track agile approach by Suzanna Haworth at #AgileIndia2019
•
3 likes•399 views
In this talk, Suze explores a case study from her recent work in a London agency, where, working for a large retail client, the programme of work moved from a project-based delivery model incorporating Scrum to a more product-based model. Drawing on aspects of Kanban, Design Thinking and Lean Startup, and implementing a dual-track agile approach, the team is now ‘thinking more product’. Suze will delve into how the organisation has shifted to this model and how it coped with the change. She will talk through some of the difficulties that she experienced along the way and how these issues were mitigated, and provide take away techniques to help in your organisations. More details: https://confengine.com/agile-india-2019/proposal/8036/thinking-more-product-moving-from-scrum-to-a-dual-track-agile-approach Conference link: https://2019.agileindia.org
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Thinking more product: Moving from Scrum to a dual-track agile approach by Suzanna Haworth at #AgileIndia2019
Similar to Thinking more product: Moving from Scrum to a dual-track agile approach by Suzanna Haworth at #AgileIndia2019 (20)
More from Agile Software Community of India
More from Agile Software Community of India (20)
Recently uploaded
Recently uploaded (20)
Thinking more product: Moving from Scrum to a dual-track agile approach by Suzanna Haworth at #AgileIndia2019
- 1. Thinking more product: Moving from Scrum to a dual- track agile approach @suzehaworth
- 2. + A bit about me… + @suzehaworth
- 4. How did software projects run?
- 6. PMI A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
- 7. A project
- 8. A project Here’s that magic point where everything ends
- 9. A project Here’s that magic point where everything ends …said no-one, ever
- 10. FORGET PROJECTS
- 14. FORGET AGILE
- 16. THERE ARE BASIC PRINCIPLES OF GOOD PRODUCT DELIVERY
- 18. Feedback and iterate Value getting working designs, prototypes or software over defining requirements upfront Prioritise the customer and the outcomes CUSTOMER FIRST
- 20. Iterative development Deliver a working product quickly to the customer Team and customers working together to make adjustments FREQUENT DELIVERY
- 22. Key to making your project work and building a better product Don’t rely on documentation to define requirements and share knowledge Your client is part of the team too! Face to face communication and shared decisions TEAM COLLABORATION
- 24. 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan TEAM COLLABORATION CUSTOMER FIRST FREQUENT DELIVERY AGILE
- 25. LEAN 1. Focus on customers 2. Optimise the whole 3. Elimate waste 4. Learn first 5. Deliver fast 6. Keep getting better 7. Energise workers TEAM COLLABORATION CUSTOMER FIRST FREQUENT DELIVERY
- 28. B O O K A N A P P O I N T M E N T C O N T A C T L E N S E C O M M E R C E V I R T U A L T E C H G L A S S E S E C O M M E R C E 1 2 3 4 4 x product streams
- 29. D E V E L O P M E N T A G E N C Y O U R A G E N C Y C L I E N T Product Owner UX & design pair Development & QA
- 30. CARRY OUT THE PLAN 31 2 4 DEVISE A PLAN LOOK BACK UNDERSTAND THE PROBLEM
- 36. So what did we know?
- 42. REQUIREMENTS DEFINED BY PRODUCT OWNER PRODUCT DEFINED BY TECH ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 43. REQUIREMENTS DEFINED BY PRODUCT OWNER SPRINT RELEASES NOT HAPPENING PRODUCT DEFINED BY TECH ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 44. REQUIREMENTS DEFINED BY PRODUCT OWNER SPRINT RELEASES NOT HAPPENING PRODUCT DEFINED BY TECH TOO MANY STORIES IN EACH SPRINT ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 45. REQUIREMENTS DEFINED BY PRODUCT OWNER SPRINT RELEASES NOT HAPPENING PRODUCT DEFINED BY TECH TOO MANY STORIES IN EACH SPRINT WORK NOT GETTING BUILT ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 46. REQUIREMENTS DEFINED BY PRODUCT OWNER SPRINT RELEASES NOT HAPPENING NOT WORKING AS A TEAM PRODUCT DEFINED BY TECH TOO MANY STORIES IN EACH SPRINT WORK NOT GETTING BUILT ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 47. REQUIREMENTS DEFINED BY PRODUCT OWNER SPRINT RELEASES NOT HAPPENING NOT WORKING AS A TEAM PRODUCT DEFINED BY TECH TOO MANY STORIES IN EACH SPRINT SILOED PRODUCT SCRUM TEAMS WORK NOT GETTING BUILT ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 48. REQUIREMENTS DEFINED BY PRODUCT OWNER SPRINT RELEASES NOT HAPPENING NOT WORKING AS A TEAM PRODUCT DEFINED BY TECH TOO MANY STORIES IN EACH SPRINT SILOED PRODUCT SCRUM TEAMS NOT INVOLVED IN DECISIONS WORK NOT GETTING BUILT ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 49. REQUIREMENTS DEFINED BY PRODUCT OWNER SPRINT RELEASES NOT HAPPENING NOT WORKING AS A TEAM PRODUCT DEFINED BY TECH TOO MANY STORIES IN EACH SPRINT SILOED PRODUCT SCRUM TEAMS NOT INVOLVED IN DECISIONS WORK NOT GETTING BUILT ‘FEATURE FACTORY’ NO CUSTOMER TESTING PRIOR TO RELEASE GETTING TOLD WHAT TO DESIGN CUSTOMER FIRST FREQUENT DELIVERY TEAM COLLABORATION
- 50. 1. We needed to focus on the core principles
- 51. 2. We needed to work towards building a better product for customers 1. We needed to focus on the core principles
- 55. Discover and test that what you are building is what the customer needs
- 56. Deliver what your customer needs… rather than what you (or they!) think they want
- 59. HOW DID WE MAP THE PROCESS?
- 60. E X I S T I N G D A T A & R E S E A R C H I N S I G H T S 1
- 63. E X I S T I N G D A T A & R E S E A R C H I N S I G H T S 1 2 T H E P R O B L E M S T A T E M E N T
- 65. Focus on the problem you are trying to solve and a measurable outcome… don’t just jump straight to the solution
- 66. Problem statements value outcomes over outputs
- 67. “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Albert Einstein
- 68. How might we [action] so that [benefit]?
- 71. How might we make prescription entry more simple so that customers can complete contact lenses purchases more easily?
- 72. E X I S T I N G D A T A & R E S E A R C H I N S I G H T S 1 2 3 A S S U M P T I O N S T H E P R O B L E M S T A T E M E N T
- 73. MAKE ASSUMPTIONS
- 74. A declaration that is assumed to be true
- 75. Our customers have a need to: These needs can be solved with: What problems does our product solve? When and how is our product used? What features are important? How should our product look and behave? We will solve this through:
- 76. We need to separate out the prescription and delivery in the journey to cause less confusion and ease the pain point
- 77. We should provide customers with the ability to express reorder based on their last purchase, to save them refilling in their prescription
- 78. E X I S T I N G D A T A & R E S E A R C H I N S I G H T S H Y P O T H E S E S 1 2 3 4 A S S U M P T I O N S T H E P R O B L E M S T A T E M E N T
- 80. We believe that [doing / building / creating this] For [this user / persona] Will achieve [this outcome] We’ll know we’re right when we see [this signal / metric]
- 81. We believe that separating the prescription and delivery For contact lens purchasers Will achieve a decrease in drop-off at this point in the journey We’ll know we’re right when we see more customers completing the prescription step
- 82. U X / D E S I G N 5
- 83. U X / D E S I G N P R O T O T Y P E 5 6
- 85. Static Gauge reactions to concepts / propositions Test short journeys and simple goals e.g. Invision Low fidelity
- 86. Interactive Get input on experience / mechanics of a journey Test new products/features, look & feel & motion principles e.g Principle Medium fidelity
- 87. Live Gauge reactions to true functionality of full scenarios Test look & feel & complex interactions e.g HTML prototype High fidelity
- 88. U X / D E S I G N P R O T O T Y P E T E S T 5 6 7
- 90. Face to face interviews Guerrilla testing Online testing Surveys
- 91. U X / D E S I G N P R O T O T Y P E T E S T I N S I G H T S I T E R A T E 5 6 7 8
- 92. TEST & ITERATE
- 94. 1. Validated learning 2. Build things customers need
- 95. 3. Business value 1. Validated learning 2. Build things customers need
- 96. 3. Business value 1. Validated learning 2. Build things customers need 4. A better backlog
- 97. Back to Agile…
- 98. Agile doesn’t have a brain!
- 99. How does that fit with a development team working in Scrum?!
- 100. DUAL-TRACK AGILE
- 101. John Ciecholewski
- 102. John Ciecholewski
- 103. John Ciecholewski
- 105. John Ciecholewski Design thinking Kanban
- 106. John Ciecholewski Design thinking Kanban Lean UX
- 107. John Ciecholewski Design thinking Kanban Lean UX Scrum
- 108. CARRY OUT THE PLAN 3
- 110. Reality
- 111. 2 Working collaboratively, so as not to revert to a Waterfall approach 1 Changing mindset: shifting to problems not solutions, outcomes not outputs 3 Despite different processes, ensuring ways of working are clear to all 4 Ensuring delivery feedback goes into the discovery backlog
- 112. • Team feel more autonomous People Process Product Outcomes roadmap • Customer feedback goes into backlog • Less team churn • Testing with customers • Using a mixture of prototyping • PO not defining requirements • Improving key metrics • Working with problems and outcomes • Development agency more engaged with customers
- 114. 5 core bits of advice….
- 115. 1. Engage your team
- 116. 2. Safe environment for failure
- 117. 3. Inspect and adapt
- 118. 4. Understand and sell the value
- 119. 5. Involve everyone
- 120. LOOK BACK 4
- 121. ✘ 1. Still product silos
- 122. ✘ 2. Too little, too late 1. Still product silos
- 123. ✘ 3. A lot of tech debt 2. Too little, too late 1. Still product silos
- 124. 1. A focus on the customer ✔
- 125. 2. Less development waste 1. A focus on the customer ✔
- 126. 3. Better key metrics 2. Less development waste 1. A focus on the customer ✔
- 127. 3. Better key metrics 2. Less development waste 4. A happier team! 1. A focus on the customer ✔
- 128. By thinking about the core principles around good product delivery you can make customers and your team happier
- 129. =