Art of Product Ownership vs. The Conveyor Belt Approach
•
1 like•218 views
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
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Art of Product Ownership vs. The Conveyor Belt Approach
Similar to Art of Product Ownership vs. The Conveyor Belt Approach (20)
More from Scrum Australia Pty Ltd
More from Scrum Australia Pty Ltd (20)
Recently uploaded
Recently uploaded (20)
Art of Product Ownership vs. The Conveyor Belt Approach
- 1. The Art of Product Ownership vs. The Conveyor belt Approach D. Bales Scrum Australia 24 Oct 2018
- 2. COMPLIANCE
- 3. COMPLIANCE
- 4. COMPLIANCE
- 5. COMPLIANCE
- 6. COMPLIANCE
- 7. COMPLIANCE
- 8. COMPLIANCE
- 9. COMPLIANCE
- 10. COMPLIANCE
- 11. COMPLIANCE
- 12. COMPLIANCE
- 13. COMPLIANCE
- 14. COMPLIANCE
- 15. COMPLIANCE
- 16. COMPLIANCE
- 17. COMPLIANCE
- 18. COMPLIANCE
- 19. COMPLIANCE
- 20. COMPLIANCE
- 21. COMPLIANCE
- 45. COMPLIANCE
- 47. Risks & ChallengesRules & Constraints COMPLIANCE
- 48. Risks & ChallengesRules & Constraints Value COMPLIANCE
- 49. Risks & ChallengesRules & Constraints Value Dynamics COMPLIANCE
- 50. Risks & Challenges Sprint #1 Iterative Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics COMPLIANCE
- 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. 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. CORE FRAMEWORK
- 54. Rules & Constraints CORE FRAMEWORK
- 55. Risks & ChallengesRules & Constraints CORE FRAMEWORK
- 56. Risks & ChallengesRules & Constraints Value CORE FRAMEWORK
- 57. Risks & ChallengesRules & Constraints Value Dynamics CORE FRAMEWORK
- 58. Risks & Challenges Sprint #1 Incremental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics CORE FRAMEWORK
- 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. 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. DIGITAL APP
- 62. Rules & Constraints DIGITAL APP
- 63. Risks & ChallengesRules & Constraints DIGITAL APP
- 64. Risks & ChallengesRules & Constraints Value DIGITAL APP
- 65. Risks & ChallengesRules & Constraints Value Dynamics DIGITAL APP
- 66. Risks & Challenges Sprint #1 Experimental Approach Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value Dynamics DIGITAL APP
- 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. 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. 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
- 75. Rules & Constraints Risks & Challenges
- 76. Rules & Constraints Value & Purpose Risks & Challenges
- 77. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges
- 78. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges Combinations, Patterns & Archetypes
- 79. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges Dynamics Combinations, Patterns & Archetypes
- 80. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Rules & Constraints Value & Purpose Risks & Challenges Dynamics Combinations, Patterns & Archetypes Guiding Principles
- 81. Sprint #1Sprint Goals Sprint #2 Sprint #3 Sprint #4 Feedback,inspect&adapt Rules & Constraints Value & Purpose Risks & Challenges Dynamics Combinations, Patterns & Archetypes Guiding Principles
- 82. APPENDIX
- 83. 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
- 84. 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
- 85. 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
- 86. 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