Choosing how you will walk through your day, having fun with your colleagues and clients, actively listening and participating in collaborations, and ensuring others also have a great day - I have written a short story a while ago about the basics of the Fish! Philosophy for being an outstanding team member. In other blog posts, I covered how this can make your Sprint Retrospective more effective, and also how it can improve your Sprint Planning. I looked at how this can work out for your Daily Scrum, and now we've arrived at the last specific event of Scrum: the Sprint Review.
A small reminder from the Scrum Guide: “A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.” In other words transparency, inspection, adaptation to maximise product value. The participants of this session are the full Scrum Team: Product Owner, Development Team and the Scrum Master, and stakeholders invited by the Product Owner.
Scenario A:
The Scrum Team enters the meeting room - about 10 minutes late which is the standard in the organization. It is now up to the Development Team members to demo what they have developed. So they do. One of them has prepared a presentation and explains through screenshots the progress they made. A colleague takes over and shows hands-on using the application.
All of a sudden, the Product Owner jumps in between “This is not what I was looking for! Totally unacceptable. We’d better cancel the remainder of the session and you as a team can start working on what I asked for in the last Sprint Planning.”
Total silence. None of the team members knows what to say. And the Scrum Master, well, apparently observes.
The session ends on a down note.
Scenario B:
Half an hour before the start of the Sprint Review, Scrum Team members prepare the room: in each corner they put a flipchart titled with a Product Backlog Item they worked on. They also position a table with a laptop together with each flipchart (further called “stations”).
The Product Owner invited just as usual a number of customers that provided their input on the Product Backlog Items that were addressed. As the Product Owner wanted to catch up with each of them and make it a small networking opportunity amongst them, the stakeholders were perfectly on time to start the Sprint Review.
As the Product Owner did invite the stakeholders, she does open the session thanking everybody for joining and being on time, and continues showing a comic of the metaphor they used to describe their Sprint Goal.
Then everybody is invited to pass by the different stations. Development Team members spread out. The stakeholders do the same. On each station stakeholders are invited to use the newly implemented features while Development Team members observe. They start noting down feedback, questions and remarks the stakeholders give while using the system. Lively conversations are filling the room. A few heated discussions, a number of laughs. Always open and respectful to understand the users’ needs better.
After stakeholders got the opportunity to rotate covering all stations, the flipcharts with the notes were put in the center for all to see. Feedback from the stakeholders was mixed: the Sprint Goal as explained was borderline achieved. “Hey, but I understand that this was really a challenge in two weeks. Well done!” indicates one of them. “With the feedback I saw you noting down, if this can be put in one of the coming releases, then we’ll have added value compared to our current situation.”
The Product Owner all of a sudden throws a fish (a fluffy bear!) to one of the stakeholders who catches it. With it comes the question “What would the next best thing we can do according to you?”. The stakeholder explains, a short feedback round is done, and the fish flies to another stakeholder. Same approach. This continued for the next hour until most of the present stakeholders provided their idea.
The session closes with an informal chat where stakeholders and Scrum Team members mixed up. Some talked about some specific features, others about the market, and still others about … what they would participate in during the upcoming weekend. Anyway, it does help in understanding your stakeholders.
Allow me to assume that you would prefer scenario B. Why is that? It feels straightforward doesn’t it. In fact, in contrast to scenario A, scenario B does implement the four simple practices of the Fish! Philosophy.
A stakeholder mentioned the team did a good job. Which, given the hard work and still only achieving the Sprint Goal borderline, “Makes Their Day” of the Scrum Team.
The Product Owner brought in some “Play”. Throwing a “fish” to pass the word to the next person. And they did use a comic as a metaphor to explain their Sprint Goal to the stakeholders. With some creativity you can make the Sprint Review real fun while still achieving the objective.
Both Scrum Team members and stakeholders performed “Be There”. They were collaborating at the different stations to learn, to find out what worked and what didn’t. They were engaged to explain/understand the real users’ needs.
All in all, they did “Choose Your Attitude”. No the Sprint Goal was only achieved borderline. Yet the context is very similar as in scenario A. And now they were having fun while collaborating effectively towards their objective. Because they chose to.
Anything you want to change about how your team acts during Scrum events? Let us know, we might help you out, or you can join our next Fish! Philosophy workshop
Fish! on…
