When working on projects in an Agile framework, it can be easy to fall into a routine of simply ‘going through the motions’ during Scrum rituals. A project team can settle into a plateau with the repetitive nature of Sprint cycles and associated practices. You may notice that your team performs the rituals as scheduled, yet the core goal of each method has been forgotten. This creates a risk that little value is extracted from each activity, meaning that they no longer provide insight and incremental improvement.

This risk is exceptionally high and standard during Retrospective rituals, especially if the team becomes focused on their achievements during the Sprint rather than exploring opportunities for improvement. When Retros are not conducted in-depth, a huge opportunity is missed – to keep the team performing well and take their performance to higher levels.

So how can Scrum Masters support their teams better to avoid the risk of settling into a less-than-Agile ritual rut?

One approach I can recommend from personal experience is seeking precise performance data. This data can encourage teams to maintain open and curious minds and inspire them to identify improvement opportunities from that data regularly. During retrospectives and other rituals, careful data analysis can also specify the root cause of any obstacles or challenges and determine the best steps to address them.

My Experience With Data

While overseeing a web development team working on a large project, I noticed the defect rate we were regularly measuring was higher than expected, based on previous industry experience.

Upon further investigation of the testing data, it became apparent that many defects were occurring very early in the test cycle after the Developer handed finished stories over to the Testers and began testing. In addition, early in the testing process, the Testers reported often needing to spend time with the Product Owner to clarify expected application behavior and determine if it was acceptable or not.

The analysis of these observations led us to change the story lifecycle by introducing two new team rituals – the ‘Story Kick-Off’ and the ‘Story Demo.’

The Story Kick-Off

Who: Product Owner, Developer, Tester, and UX Lead

What: The purpose of the ritual was for the Product Owner to again walk through the specific user stories and re-explain the expected behavior. It provided another opportunity for the Developer and the Tester to ask any further clarifying questions that were needed. The UX Lead provided design guidance if any minor changes were required arising from that clarification or any unexpected technical limitations that occurred.

When: Directly after the Developer picked up the user stories from the sprint backlog and was ready to start development work.

Results: This ritual improved the understanding and alignment of the key team members in terms of developing and testing stories, improved the quality of the delivered product, significantly reduced the number of defects found in testing, and increased the overall output from the team.

The Story Demo

Who: Product Owner, Developer, Tester, and UX Lead

What: The purpose of the ritual was for the Developer to demonstrate the completed work in the test environment and show how it satisfied the agreed user stories. The practice ensured that everything was configured correctly and set up in the test environment before testing started. It also provided an opportunity for the Product Owner, Tester, and UX Lead to ask any clarifying questions about the application rendering and behavior. This ritual was especially effective at capturing and addressing minor alignment and rendering issues across the desktop, tablet, and mobile breakpoints for our various supported browsers and devices.

When:Directly after the Developer had completed all development, deployed the application changes into the configured test environment, and completed their initial testing to ensure the stories met their definition of done.

Results: This ritual resulted in everyone in the project team is clear about what was acceptable to the Product Owner and the UX Lead in terms of user experience. Any agreed changes were completed, and the Developer would update the user stories, while the Tester would update their test cases. It ensured the final product was fit-for-purpose, provided a good user experience, and was acceptable to the Product Owner. It also reduced the number of defects found during testing and increased the team's general performance.

This is just one example of how observing, analyzing, and employing data during an Agile framework can dramatically improve team performance, product quality, and end-user satisfaction. Allowing data to power your analysis and rituals can deliver exceptional results, especially when combined with a creative mindset across your team. Used wisely, it can turn your Retros from routine ‘blah-blah’ to routine ‘ah-ha’!