Inspecting and adapting your product
•
0 likes•514 views
A workshop I gave at the South African Scrum Gathering on 9 Sep 2011 (#SGZA) in Johannesburg. It examines why sprint reviews are so often awful and how we need to follow some of the rules of a retrospective if we are to achieve value from the review process
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (15)
Similar to Inspecting and adapting your product
Similar to Inspecting and adapting your product (20)
Recently uploaded
Recently uploaded (20)
Inspecting and adapting your product
- 1. Inspecting & Adapting your Product Carlo Kruger (@ironicbuddha) Karen Greaves (@karen_greaves) Leaders in facilitating lasting Agile change
- 2. Your Sprint Review S U X Carlo Kruger (@ironicbuddha) Karen Greaves (@karen_greaves) Leaders in facilitating lasting Agile change
- 3. Sprint Reviews • Who comes? • Who facilitates? • How long? • How do you feel afterwards? 8m put together these thoughts on your current sprint reviews 2m per table present back 15m total
- 4. This story has had its serial numbers filed off to protect the innocent (and in case anyone in the audeience from that team recognises it) Very short Review, Developers didn’t know the system too well, and besides hated public speaking so threw tester under the bus and tester did all demoes, dev’s facing to finish by review time, frequently broke things by checkins just before review. Team didn’t want to do reviews anymore managers from the business side used the session to complain about things PO didn’t prioritise Never comment on work in the sprint Stakeholders felt stories too small and boring, why did it take so long to develop Team demoralized
- 5. Team has an awesome ScrumMaster, so made it the topic of the retrospective Team we wanted to address: 1 - show value in what the team has worked on 2 - include the entire team in the process 3 - show the benefits of doing Scrum (important as like many teams, still building credibility for Agile in the organisation ) Retrospective Actions: Review now had a structure and agenda explain the value of the stories Added context of sprint in the overall release plan
- 6. Result? Applause! Happy team and PO, felt their hard work had been recognised Energised for the next sprint
- 7. Well, that went well, right?
- 8. No Applause, please! Ken wrote an article (sadly no longer available on SA site called “No Applause Please” As humans we crave applause and unconsciously will do whatever we can to get it So what are the chances we will expose failure in a meeting where we crave approval and applause?
- 9. Misunderstood role of the Review. It is not intended as stakeholder communication or management Supposed to be an inspect & adapt point for the Product!
- 10. Failure As adults we only learn through trying and learning from the outcome Without safety we will not expose failure, ergo we never learn
- 11. Lowering the stakes & create Safety to allow failure back in the room - remove managers - focus on the team and contributors (who came to SP1)
- 12. Whose work are we inspecting? The team’s work is done. If they meet their DOD, there is no need to look further We’re actually inspecting the PO’s work. We are collaborating on “what should the product do next” The PO chooses to accept the PO’s work (or not)
- 13. Pop Quiz: Who sets sprint goals?
- 14. a facilitated conversation resulting in action Can the PO facilitate his own review?
- 15. Divergence Convergence Good retrospectives follow a dynamic of divergence to convergence a pattern missing from most sprint reviews
- 16. how can reviews be more like retrospectives?
- 17. The dirty secret of Scrum is that we did not (yet) have a retrospective in the original version of Scrum
- 18. Set the Stage What was the sprint goal? How many stories did we commit to? How did we do?
- 19. Gather Data Look at the software produced Everyone should have a chance to USE the software
- 20. Generate Insights Analyse the fit for purpose, direction, progress Does the vision still fit? Does our next sprint align with the insights we’re generating?
- 21. Choose Focus Set Sprint Goal for next sprint What are we going to change about our product? (functionality, priority) How will we measure the impact of those changes?
- 22. Close the Review Review the outcome of the review identify new stories identify new priorities
- 23. 20m at table 3 min presentation per table
- 24. @ironicbuddha @karen_greaves scrumcoaching.wordpress.com www.scrumsense.com Leaders in facilitating lasting Agile change end
Editor's Notes
- \n
- \n
- 8m put together these thoughts on your current sprint reviews\n2m per table present back\n\n15m total\n
- 15 m Review, Tester demoes, dev’s frequently broke things by checkins just before review.\nTeam didn’t want to do reviews anymore\nJust session for managers to bitch about things PO didn’t prioritise\nNever comment on work in the sprint\nManagers felt stories too small and boring, why did it take so long\nTeam felt crap! (even though they delivered more than what was committed to)\n\n
- So in the retro we wanted to address some issues & misconceptions.\n1 - show value in what the team has worked on\n2 - include the entire team in the process\n3 - show that the way we are working is beneficial (important as we are still in the "show that agile is working for us" phase)\n\nEntire team with PO worked on this together and came up with great ways to do this. Structure was added to the Review and discussions around best ways to explain the why behind the stories as well as context of sprint in larger Release, and progress towards that.\n\n\n
- Outcome of this sprint was that everyone in room understood where our sprint fitted in and what the value of the stories are. The applause was more for the work accomplished than the review "process". We have reached a milestone that the company wanted to hit a year ago! \n
- \n
- \n
- Misunderstood role of the Review. \nIt is not intended as stakeholder communication or management\n
- Failure\nAs adults we only learn through trying and learning from the outcome\nWithout safety we will not expose failure, ergo we never learn\n\n
- Lowering the stakes & create Safety\n - remove managers\n - focus on the team and contributors (who came to SP1)\n
- The team’s work is done. If they meet their DOD, there is no need to look further\nWe’re actually inspecting the PO’s work. We are collaborating on “what should the product do next”\nThe PO chooses to accept the PO’s work (or not)\n
- Pop Quiz: Who sets sprint goals?\n
- Can the PO facilitate his own review?\n
- \n
- \n
- The dirty secret of Scrum is that we did not (yet) have a retrospective in the original version of Scrum\n
- What was the sprint goal?\nHow many stories did we commit to?\nHow did we do?\n
- Look at the software produced\nEveryone should have a chance to USE the software\n
- Analyse the fit for purpose, direction, progress\nDoes the vision still fit?\nDoes our next sprint align with the insights we’re generating?\n
- Set Goals\nWhat are we going to change about our product? (functionality, priority)\nHow will we measure the impact of those changes?\n
- Review the outcome of the review\nidentify new stories\nidentify new priorities\n
- 20m at table\n3 min presentation per table\n
- \n