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
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
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)
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
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