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.

Art of Product Ownership vs. The Conveyor Belt Approach

51 views

Published on

by Dave Bales


This presentation aims to raise awareness that default Product Ownership (that uses only ordering and prioritising PBI’s) is not enough to be successful. A higher level of consciousness is required to appreciate the challenges and dynamics of the work at hand. Devising evolutionary strategies to cater for the undercurrents, changing landscape and the opposing dynamics in the product and its backlog, may help to tip the balance in favour of being more successful.

Project dynamics can include:

Releasing a new insurance app to millenials on a smartphone platform. The challenge with this is that more customer testing and an exploratory approach of how milenials think will be required, hence each sprint goal may include working toward a customer testing objective;

A compliance risk project where compliance objectives are static. How those objectives are satisfied is variable, hence an evolving strategy to use an iterative approach is to be considered. The first iteration would be to neutralise the compliance risk, starting with a manual process. Successive iterations would then be run by automating and adding more value;

An integration risk project, where a central framework has to integrate with several other systems. An evolving strategy would focus on setting sprint goals to achieve integration, as well as regression testing objectives to neutralise the integration risk early

Published in: Business
  • Be the first to comment

  • Be the first to like this

Art of Product Ownership vs. The Conveyor Belt Approach

  1. 1. The Art of Product Ownership vs. The Conveyor belt Approach D. Bales Scrum Australia 24 Oct 2018
  2. 2. COMPLIANCE
  3. 3. COMPLIANCE
  4. 4. COMPLIANCE
  5. 5. COMPLIANCE
  6. 6. COMPLIANCE
  7. 7. COMPLIANCE
  8. 8. COMPLIANCE
  9. 9. COMPLIANCE
  10. 10. COMPLIANCE
  11. 11. COMPLIANCE
  12. 12. COMPLIANCE
  13. 13. COMPLIANCE
  14. 14. COMPLIANCE
  15. 15. COMPLIANCE
  16. 16. COMPLIANCE
  17. 17. COMPLIANCE
  18. 18. COMPLIANCE
  19. 19. COMPLIANCE
  20. 20. COMPLIANCE
  21. 21. COMPLIANCE
  22. 22. COMPLIANCE Flexible
  23. 23. COMPLIANCE Sprint #1 Flexible
  24. 24. COMPLIANCE Sprint #1 Flexible
  25. 25. COMPLIANCE Sprint #1 Flexible
  26. 26. COMPLIANCE Sprint #1
  27. 27. COMPLIANCE Sprint #1
  28. 28. COMPLIANCE Sprint #1
  29. 29. COMPLIANCE Sprint #1
  30. 30. COMPLIANCE Sprint #1
  31. 31. COMPLIANCE Sprint #1
  32. 32. COMPLIANCE Sprint #1 Sprint #2
  33. 33. COMPLIANCE Sprint #1 Sprint #2
  34. 34. COMPLIANCE Sprint #1 Sprint #2
  35. 35. COMPLIANCE Sprint #1 Sprint #2
  36. 36. COMPLIANCE Sprint #1 Sprint #2 V1.0 V2.0
  37. 37. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 V1.0 V2.0
  38. 38. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 Sprint #4 V1.0 V2.0
  39. 39. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 Sprint #4 V1.0 V2.0
  40. 40. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 Sprint #4 V1.0 V2.0
  41. 41. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 Sprint #4 V1.0 V2.0
  42. 42. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 Sprint #4 V1.0 V2.0
  43. 43. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 Sprint #4 V1.0 V2.0
  44. 44. COMPLIANCE Sprint #1 Sprint #2 Sprint #3 Sprint #4 V1.0 V2.0
  45. 45. COMPLIANCE
  46. 46. Rules & Constraints COMPLIANCE
  47. 47. Risks & ChallengesRules & Constraints COMPLIANCE
  48. 48. Risks & ChallengesRules & Constraints Value COMPLIANCE
  49. 49. Risks & ChallengesRules & Constraints Value Dynamics COMPLIANCE
  50. 50. Risks & Challenges Sprint #1 Iterative Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics COMPLIANCE
  51. 51. Risks & Challenges Sprint #1 Iterative Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics 1. Neutralise risk 2. Add Value Guiding Principles COMPLIANCE
  52. 52. Risks & Challenges Sprint #1 Iterative Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics Iterator Incrementalist + Archetypes: 1. Neutralise risk 2. Add Value Guiding Principles COMPLIANCE
  53. 53. CORE FRAMEWORK
  54. 54. Rules & Constraints CORE FRAMEWORK
  55. 55. Risks & ChallengesRules & Constraints CORE FRAMEWORK
  56. 56. Risks & ChallengesRules & Constraints Value CORE FRAMEWORK
  57. 57. Risks & ChallengesRules & Constraints Value Dynamics CORE FRAMEWORK
  58. 58. Risks & Challenges Sprint #1 Incremental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics CORE FRAMEWORK
  59. 59. Risks & Challenges Sprint #1 Incremental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics 1. Establish A Connection 2. Build Upon The Baseline Guiding Principles CORE FRAMEWORK
  60. 60. Risks & Challenges Sprint #1 Incremental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics 1. Establish A Connection 2. Build Upon The Baseline Guiding Principles Incrementalist + Regressionator Archetypes: CORE FRAMEWORK
  61. 61. DIGITAL APP
  62. 62. Rules & Constraints DIGITAL APP
  63. 63. Risks & ChallengesRules & Constraints DIGITAL APP
  64. 64. Risks & ChallengesRules & Constraints Value DIGITAL APP
  65. 65. Risks & ChallengesRules & Constraints Value Dynamics DIGITAL APP
  66. 66. Risks & Challenges Sprint #1 Experimental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics DIGITAL APP
  67. 67. Risks & Challenges Sprint #1 Experimental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics 1. Discover and adapt Guiding Principles DIGITAL APP
  68. 68. Risks & Challenges Sprint #1 Experimental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics 1. Discover and adapt Guiding Principles or Archetypes: Pivoteer Alchemist DIGITAL APP
  69. 69. Feature Beacon Minimaliser Steel Thread Iterator De-Dominator Pivoteer Conveyor Belt Alchemist Renovator Incrementalist Rumble Go Between Pick ’n’ Mix Diverge Converge The Pacifier Regressionator Stealth Flight
  70. 70. Rules & Constraints
  71. 71. Rules & Constraints Risks & Challenges
  72. 72. Rules & Constraints Value & Purpose Risks & Challenges
  73. 73. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges
  74. 74. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges Combinations, Patterns & Archetypes
  75. 75. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges Dynamics Combinations, Patterns & Archetypes
  76. 76. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges Dynamics Combinations, Patterns & Archetypes Guiding Principles
  77. 77. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Feedback,inspect&adapt Rules & Constraints Value & Purpose Risks & Challenges Dynamics Combinations, Patterns & Archetypes Guiding Principles
  78. 78. APPENDIX
  79. 79. Stealth Flight Risk Mitigation When To Use When a rookie agile team need time to get established but stakeholders might disrupt them Approach Refine the backlog to use very short sprints e.g. 1 week for the first 3-5 sprints and then settle into a more appropriate sprint duration. This allows the team to fly under the radar and use the scrum framework 3- 5 times before the stakeholders start asking questions about their performance. Beware… If the overall project duration is only 5 sprints long, then the team may not have time to settle down properly and be effective Regressionator Risk Mitigation When To Use When there is a risk of wide impacts on other systems or actors Approach Refine the backlog to implement and develop the automated regression testing capability first and then look to deliver features with complimentary automated regression test suites. Beware… The time taken to automate regression testing first may delay new features and raise stakeholder concern, tension and conflict The Pacifier Stakeholders When To Use When there are multiple competing stakeholders influencing the priorities Approach Refine the backlog into small packages of work with each package satisfying one specific need for a stakeholder. The packages can then be arranged by organisational priority in the backlog Beware… Individuals stakholders may be upset with general approach across all stakeholders is present rather than a tailored feature set just for them Diverge Converge Time Bound When To Use When time is short but we need to get the best solution Approach Refine the backlog into several sprints that fit within the time constraint with the early sprints trying new ideas and prototypes, and the later sprints refining the final product Beware… Need to converge when it is the right time to stop diverging Pick N Mix Experimentation When To Use When it is unclear which items to work on next Approach Refine the backlog into several groups of items that can be attempted in each sprint, the initial forecast may be purposefully larger than the exhibited velocity but is then trimmed back with items that can be progressed, and the remainder placed back on the backlog. Beware… The purpose of the sprint may not be clearly understood until after the sprint forecast is trimmed back Go Between Risk Mitigation When To Use When there are strong dependencies between systems, teams or products Approach Refine the backlog with mock ups and interfaces to decouple dependencies between the actors. Also allow for regular connection and integration to realise any integration issues. Beware… Reconnect regularly especially if the projects have risk of diverging rather than converging
  80. 80. Rumble Experimentation When To Use When it is unclear which solution will work best Approach Refine the backlog into several prototypes that can be built and tested in parallel with distinct opportunities when the population of solutions is culled with the fittest ones remaining Beware… Time taken to create multiple prototypes is traded for knowledge of which solution is best Incrementalist Risk Mitigation When To Use When a progressive approach to add feature by feature is needed Approach Refine the backlog into successive increments that begin to fit together and can be tested in an ever growing feature set Beware… The end product may no be viable until all of the increments are in place Renovator Risk Mitigation When To Use When there is a significant amount of technical debt that is compromising the team Approach Refine the backlog in order of priority with artificially high value purposefully placed upon technical debt items so that they are done ahead of other items Beware… New features may be neglected leading to stakeholder tension and conflict Alchemist Experimentation When To Use When there is a need to get grungy broad insights quickly and course correct with small experiments Approach Refine the backlog into several sprints with each sprint being an open experiment to answer a question or test an assumption. Each sprint may have a sprint goal which describes the hypothesis, question or assumption to be tested by the sprint. Beware… The end destination may arrive at a different place than first anticipated Conveyor Belt Default When To Use The default action - give up thinking and instead just do the next priority Approach Refine the backlog in order of priority based upon valuation techniques and estimation techniques applied. Beware… The end product may be an incoherent collection of feaures Pivoteer Experimentation When To Use When the end outcome is not known and deeper insights are needed with hi fidelity feedback Approach Refine the backlog into multiple Lean Startup cycles with each cycle having 2-4 sprints to build and supply hi fidelity outcomes that can be evaluated at the end of the cycle, and a decision to pivot or persevere can be made. Each Lean Startup cycle will need a hypothesis, goal or statement of intent, and each sprint will need a sprint goal which may be a sub-part of the wider intent. Beware… Time taken to create a hi fidelity output that can be validated may be wasted
  81. 81. De-Dominator Dependencies When To Use When your team is using agile and a team that you are dependent on is using waterfall Approach Refine the backlog to provide regular prototypes that can be modelled as consumers of the other teams' services. These prototypes can then be used to inform the formal specifications that are requested from the waterfall teams. Beware… Reconnect regularly especially if the projects have risk of diverging rather than converging Iterator Risk Mitigation When To Use When a versioning approach solves the initial problem quickly and then makes it more solid later Approach Refine the backlog into a series of iterations with each iteration having a goal or statement of its intent. The goal of the product should be satisfied with a very basic first iteration, and successive iterations adding more and more value. Beware… First basic iterations may not be well received Steel Thread Risk Mitigation When To Use When there is integration risk present such as when a number of systems are used together Approach Refine the backlog to integrate all of the systems right from the first sprint. The functionality does not have to do anything, only connect the systems together at this point to neutralise the integration risk. Additional sprints should then add value to form an iterative approach. Beware… Need access to all of the systems in order to get them connected Minimaliser Time Bound When To Use When there are more items than time to complete them, and a ruthless approach is needed Approach Use valuation techniques, and estimatione techniques to determine the return on investment of each item, and prioritise. Be ruthless and discard those items that are not going to be done. Beware… The end result may not be a viable product Feature Beacon Stakeholders When To Use When there is a risk of generating multiple features that degrade the user experience Approach Construct a guiding light that reminds you of the purpose and intention of the product, which could be a user experience map or feature road map to provide clarity on what is best for the product, and then refine the backlog to correspond with the guiding light. Beware… Individuals stakeholders may be upset with general approach rather than a tailored feature set just for them
  82. 82. Framing Insights Approach 4. Dynamics (Do you see any particular dynamics or characteristics of the backlog?) 2. Value (Where is the *real* value in the backlog?) 1. Product / Project Observations (What do you see at a high level in the backlog and the nature of the work?) 3. Challenges + Risks (What are the key challenges and risks of the product or project?) 5. Archetypes (Which archetypes will be most useful for delivering this backlog?) Strategy Canvas Copyright © David L. Bales 2018 All Rights Reserved 6. Strategies (How will you apply the chosen archetypes to the backlog and form a release plan?) V1.1
  83. 83. dave@agileme.com.au agileme.com.au au.linkedin.com/in/balesy @daveLbales

×