Demo Your Improvement - make learning concrete
Treat your improvements like working software and let the demo pull your improvements through the sprint.
You know that meeting in Scrum where your team decides how they are going to improve? How's that working for you? Do they talk about the same issues, sprint after sprint after...? How can that be? The Sprint Retrospective is truly at the heart of agile and core to inspecting and adapting.
The demo in the sprint review pulls working software through the sprint. Once teams figure this out, they get good at showing up with finished work. Why is the same not true for retrospective actions?
How does this change? First, budget a percentage of the team's time to improvements and second, design how you will demo your improvement at the sprint review.
In this talk, you'll learn how to make your improvement efforts concrete so that they actually happen.
Outline/Structure of the Talk
- Basic Premise behind "Why Demo"?
- Creating a budget for feature work and team improvements.
- How to deliver improvements incrementally.
- Planning experiments to improve.
- Making team improvements actionable and data driven.
- What happens to our cadence?
- Adding team improvement stories to your iteration.
- Including team improvements in the demo.
- Why does this matter at scale?
- Splitting your backlog into two parts (product and improvement).
- Deciding on a budget for improvement.
- Designing concrete ways to make your improvements demo-able.
Scrum Masters, Product Owners, Dev Team members, coaches, managers, leaders