I was reading a blog post from a coach who was working with a continuous deployment team. In essence, every story (work item, PBI, etc.) from their sprint made it into the customers hands immediately. They received feedback on each in real-time and took follow-up actions as appropriate.
Since they were using Scrum, they were still conducting a Sprint Review every few weeks. The coaches question related to the value of the review. As it seemed that everyone was questioning it in this particular context. That is, since they saw (and accepted) things in real-time, what was the need to see them again in a review? Or were they just doing it because the Scrum Guide said to do it?
And the backstory was that the coach was struggling with dogmatic Scrum in the organization. I.e., doing things just because the book said to do them, rather than thinking and adapting.
This question made me think a bit about Sprint Reviews. And it led to the following online response to that coach –
My reply
I think of the end of Sprint ceremony, whatever we want to call it, where the team pauses and shows their work results, as an opportunity for the following five things to occur:
To show working code and gain feedback on its correctness in meeting client needs.
To show plans for upcoming (next) iterations/sprints to confirm directional soundness.
To expose some of the challenges the team is facing (overcoming, needs help with, etc.) and engage the organization in assisting them.
To expose how the team is approaching their continuous improvement efforts (growing, learning, improving, evolving, etc.)
To foster organizational (broader audience) team awareness of the team’s progress & efforts and provide an opportunity for appreciation.
In other words, exposing:
Results or Outcomes
Plans and Coming Attractions
Challenges and Impediments
Improvement Trends and Learning
Appreciations
IMHO, far too many organizations and teams focus only on #1 as the goal of the review/demo. I actually think it’s too big of a communication & transparency opportunity to simply focus on what was delivered.
It’s also a rich opportunity to explore other things, albeit briefly, for customers, stakeholders, and leaders.
I know this might fly in the face of the Scrum Guide guidance. So, I’m no disagreeing with it. I’m simply augmenting it based on my personal experience.
In the case of this continuous deployment context, #1 is occurring. But you might be missing out a bit on #2 - #5. And you might want to create an opportunity to occasionally explore those aspects.
Simply food for thought…
Wrapping Up
The point I was trying to make to the coach was, yes, if you solely looked at the Sprint Review as showing features, then in this context, there was no need for it. And you know, there are many teams who view the Sprint Review’s focus as solely this.
But I’ve personally found (and learned) that the Sprint Review and be a HUGE thing beyond simply showing working software. It can be one of the driving forces and truly creating a collaborative and engaged agile culture. It can “draw leaders” into the dynamics of the team and help them to learn their role and responsibilities. And it can serve as an energizer for each of the teams, as they deliver customer value and continuously improve.
But that’s just me, what do you think?
Stay agile my friends,
Bob.
References
Here’s a link to an article about sprint review (Bazaar) techniques that nicely compliments this one –
And here’s an InfoQ reprint of a related piece I wrote a few years ago –