Here’s the background. I’m part of a small Scrum team that started work on a particular project over the summer. Our project manager, to whom most of the team reported organizationally, moved on from the company near the start of this project. We had a change of business analysts in September. I joined the team at that same time, earned Scrum Master certification two months later, and have been serving as a Scrum Master with limited capacity for various reasons. Most of the team has limited training in Scrum or Agile.
I’ve been trying to help the team understand the Scrum framework. I give guidance when appropriate and when I sense it will be accepted. I share resources. I help in whatever ways I can to assist the team in being successful.
Missing Opportunities to Inspect and Adapt
When I came on board, the team had released the results of 5 two-week sprints. The releases were done in 2 bundles. (The world of DevOps is still a challenge, but we’re making progress.) What concerned me was that the team had conducted no sprint reviews or retrospectives yet. No product demos had been presented. We were missing these opportunities to “inspect and adapt.” I began making suggestions that we hold sprint reviews and retrospectives. I also suggested we give a demo to our business partners.
I was happy when a few team members asked for more information on these Scrum events. They agreed we should have a sprint review meeting and demo of the product from the completed sprints. A date was set, invitations were sent. When the day came, I drove 90 miles in pouring rain to be present for the meeting with the hopes of meeting our business partners in person. Unfortunately, they were working remotely and dialed in. But our department manager joined us. I was glad to be present with him.
What Went Well in The First Sprint Review
Here are several things that went well in our first review:
- The demo went smoothly. No technical issues. (We beat Murphy’s Law this time!)
- Business partners made recommendations for changes during the demo. These were immediately added to our product backlog.
- We discovered that a remote team uses the application on a day-to-day basis more so than our business contact. So, we understand that we are an additional step removed from the primary users of our product.
- Our business contact liked the demo so much she suggested we do it again for the primary users. This will give us a better shared understanding of how the application is used.
- We had some discussion about making user acceptance testing more efficient.
- Having a meeting agenda that was shared with participants in advance was very helpful.
- Our business partners are open to participating in future sprint reviews.
- Our manager was please to see our work displayed in the demo and praised us after the meeting.
What Could Have Gone Better
There are a few things that could have gone better in the sprint review.
First, the demo took up too much time. To improve this situation we could:
- Schedule the meeting for 2 hours instead of 1.
- Conduct sprint reviews at the end of each sprint so there would be fewer items to cover.
Second, not everyone was present in the room. This made interaction difficult. To improve this we could:
- Schedule sprint review meetings on a day of the week in which a majority of the participants are in the office.
- Encourage folks to be physically present. Remind them of how much is to be gained by face-to-face interactions.
In the End, I’m Happy
I am very happy with the outcomes of this sprint review. I feel it amounts to a step in the direction of developing a shared understanding of the product we are producing. It’s also a step in the direction of developing a shared understanding of the Scrum events with our business partners.
I am particularly happy that:
- The purpose of “inspect and adapt” prevailed and produced some action items.
- People are open to holding sprint reviews.
- Our manager was present to witness the process.
- Our business contact asked for an additional demo.
Onward and upward!
(The Scrum Diaries are accounts of my experiences with Scrum teams during an organizational Agile transformation. There have been, and continue to be, many bumps in the road along the way. We are learning and growing together as a team. I am a certified Scrum Master (PSM I) and a developer. I fill both of those roles on my team. These Diaries primarily address topics related to Agile and Scrum.)