Introduction
I first learned about Scrum way before the 2020 manifesto update was in place. So when we went to a Scrum master training after this 2020 release we had a nice little discussion about the change that has had the most impact with me since this update to the Scrum guide.
The shift from creating one inspectable working artifact at the end of a sprint. Into releasing much more frequently within the sprint itself. This is a real good thing since we live in a CI/CD world and holding something back when its Done is not necessary.
The problem i have with this is that it shifted the focus from my knowledge about what a Sprint Review was. And this got me thinking.
Some more background
For our team, achieving the "Done" status means a feature is primed for deployment. This doesn't imply hurried releases; substantial changes are deliberated upon, ensuring they align with user requirements and broader objectives. Each update is meticulously vetted, with our Product Owner playing a pivotal role, aligning the release with business imperatives.
If you have a decent CI/CD implementation your team can forget that this update is released the moment it is deployed in our staging area. When we decide to pull the update trigger and go live is up to the business. The team will need to know when something is fully released since we also keep an eye on the potential issues. But the Developers should not have a stake in the actual release. I understand this needs some more explanation. We save that post for the future.
We do keep the DONE unreleased and DONE released separated in our DONE lane.
Our mini Sprint Reviews
To draw a finer point, our feature releases often resemble a series of "mini Sprint Reviews"
There's a comprehensive discussion about changes and potential impacts.
Deployment timings are strategized.
Detailed changelogs are curated.
Stakeholders are kept in the loop, their feedback actively sought post-release.
This thorough approach often means that by the time our Sprint Review rolls around, the major talking points have been addressed.
This takes away some topics from the sprint review. Especially when you have a decent CI/CD in place and you work by frequent releases.
When you discuss and go live with updates before the end of the sprint and you got the feedback on the released features. Why bother people again to provide feedback of discuss the release again? Scrum is a framework that facilitates talk. But we do need value in this meetings. And to us the sprint review on this topic has become quite useless.
What do we discuss?
One might wonder, with such an exhaustive pre-release evaluation, what remains for the Sprint Review? We're refining our approach, but here's our current structure
Assessing our adherence to the sprint goal.
Analyzing tasks that remain untouched in the sprint.
Delving into ongoing development items.
Adjusting the backlog to reflect any changes from the last sprint, ensuring upcoming sprints have clear priorities.
Proactively identifying new tasks or adjustments based on our recent learnings.
Engaging stakeholders for detailed feedback where necessary.
Working like this offers some distinct advantages for us. Stakeholders are in all departments of our company. A lot of them work hybrid or even 3/4 days in a hybrid combination. By doing frequent releases and planning accordingly we discuss the release when they are in the company which just works best for us. The ability to discuss things face to face is invaluable. It just works better and creates more understanding between each other.
While our reviews traditionally fall on Fridays. This is not an issue since we can just notify the stakeholder any day we are done. Discuss the update. And go live. We dont have to make a whole lot of fuzz about these things. We have short feedback loops! Planning dreadful meetings is for slow moving large companies where everybody thinks they are important and keeps stalling things in bureaucracy.
Most of our Sprint Reviews dont discuss anything related to what we deployed. We dont inspect the increment. The increment is already inspected and we move on quickly to the other topics as discussed above.
Conclusion
A few essential components drive this approach of ours.
A Product Owner with genuine decision-making authority, ensuring alignment with broader business goals.
You need a Scrum team which works tightly together in completing full stories or features. Getting them really DONE. You need FLOW in your team to be able to pull this off.
You need a decent CI/CD framework in which you can deploy automated and frequently. (We are working on that ourselves. We are automated but not enough just yet. We can take out a lot more manual labor.)
As Scrum continues to evolve, so do our practices, always keeping value and efficiency at the forefront.
