According to the 15th annual State of Agile report, there has been a tremendous increase in the adoption of agile frameworks over the last year. Within software teams, agile adoption grew from 37% in 2020 to 86% in 2021.
Agile beneath the Ice
In the midst of this agile explosion, many teams are experiencing difficulties. According to the 15th Annual State of Agile report, 46% of survey respondents report struggles with inconsistent practices and 43% report cultural classes.
Why is this? Often, organizations and teams that adopt Scrum have not fully embraced the concepts behind empiricism (making decisions based on what is known), and have not adopted the three pillars that make empiricism possible: transparency, inspection and adaptation.
Instead, many teams moving to an agile framework end up going through the motions without understanding the reason behind the framework. When this happens, Scrum (or any other agile method) merely becomes window dressing without much value.
Below are some common symptoms of teams who are “pretending” to be agile:
Teams are not delivering a “done,” usable increment each Sprint. By usable we mean that the product is fully tested and provides a fully usable increment of valuable functionality.
The Daily Scrum is a status update instead of a mini planning session.
The Sprint Review meeting is merely a demo, and not an opportunity for collaboration.
The Sprint Retrospective does not result in actionable improvement ideas that the Scrum Team addresses proactively.
The quality of the product resulting from the Scrum Team’s work is not increasing.
The Scrum Master is not coaching the Scrum Team or the parent organization in techniques to improve the use of the Scrum framework.
Developers don’t self-manage or collaborate with the Product Owner on ways to maximize the product’s value.
The organization does not respect the Product Owner’s decisions.
Resource managers do not know how to support agile teams.
How to stop pretending to be agile
First, don’t give up! Adoption of the Scrum framework is an ongoing journey.
Second, understand that Scrum’s foundation is the empirical control process. The framework performs best when events, artifacts and accountabilities of Scrum embody the three pillars of transparency, inspection, and adaptation.
Below is an overview of how empiricism applies to the Scrum events, artifacts and accountabilities and presents some tough questions to ask for determining whether your team has truly embraced Scrum or is merely pretending.
The Sprint
The Sprint is a container for all of the Scrum events. During the Sprint, no changes occur that would endanger the Sprint Goal, quality does not decrease, the Product Backlog is refined as needed, and Developers might clarify or renegotiate the scope with the Product Owner as it learns more. The duration of the Sprint should remain fairly consistent over time (it shouldn’t change every Sprint), and it must be one month or less.
To assess whether the Scrum Team is fully embodying empiricism, ask these questions:
Is the duration of the Sprint consistent over time so that it is transparent to the Scrum Team and its stakeholders?
Does the Sprint result in a done, usable Increment?
Sprint Planning
Sprint Planning is the first event within a Sprint. At the Sprint Planning event (timeboxed to a maximum of eight hours), the Scrum Team inspects the Product Backlog and creates the Sprint Backlog for the upcoming Sprint.
To assess whether the Scrum Team is fully embodying empiricism, ask these questions:
Is the team inspecting the Product Backlog at the Sprint Planning meeting?
Is the team creating a Sprint Goal and working together to create the Sprint Backlog, which contains both what the team will deliver and the plan for delivering it?
Daily Scrum
The Daily Scrum is a touchpoint for the Developer