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 Developers. It has a timebox of 15 minutes for every day of the Sprint. The purpose of this event is to increase the likelihood that the Scrum Team will deliver the Sprint Goal. It provides an opportunity for the Developers to discuss progress and plan work for the next 24 hours.
To assess whether the Scrum Team is fully embodying empiricism, ask these questions:
Is the team using this event to inspect progress?
Is the team planning work for the next 24 hours to increase the probability of meeting the Sprint Goal?
Sprint Review
The Sprint Review is the third event within the Sprint. The purpose of this event is for the Scrum Team and its stakeholders to inspect the Sprint outcomes and adapt the Product Backlog based on feedback.
To assess whether the Scrum Team is fully embodying empiricism, ask these questions:
Is the team using this event to inspect the increment?
Is the team using this event as a collaboration meeting, or is it merely a demo?
Sprint Retrospective
The Sprint Retrospective is the final event in a Sprint. Its purpose is for the Scrum Team to inspect themselves and find ways to improve the quality of the product and the team’s effectiveness.
To assess whether the Scrum Team is fully embodying empiricism, ask these questions:
At the Sprint Retrospective, is the team talking about how the Sprint went regarding individuals, interactions, processes, tools, and its Definition of Done?
Is the team identifying specific action items that it can take to improve the product’s quality or the team’s effectiveness? Is the team accomplishing these action items?
Product Backlog
The Product Backlog is a single, ordered list of everything known to be needed in a product. In a nutshell, it’s the to-do list for the Scrum Team. The Product Owner is accountable for the Product Backlog’s content and order, and no one can tell the Developers to work from any other list.
To assess whether the Product Backlog fully embodies empiricism, ask these questions:
Is the Product Backlog transparent and accessible to the Scrum Team and the product’s stakeholders?
Does the Product Backlog show what the team will work on next?
Does the Product Backlog include a Product Goal?
Sprint Backlog
The Sprint Backlog is the Developers’ plan for what they will accomplish in the Sprint. It contains the Sprint Goal, the Product Backlog items the Developers have selected for the Sprint, and its plan for delivering them.
To assess whether the Sprint Backlog fully embodies empiricism, ask these questions:
Can all Developers access the Sprint Backlog?
Is the Sprint Backlog up to date so that it shows the progress of the Sprint?
Does the Sprint Backlog contain the plan for delivering the Sprint (are Developers tasking their work out at the right level)?
Does the Sprint Backlog include a Sprint Goal that succinctly describes the purpose or desired outcome of the Sprint?
The Increment
The Increment is the product (or products) the Scrum Team delivers at the end of the Sprint. It’s the sum of all Product Backlog items completed within a Sprint. An increment exists as soon as even one Product Backlog item meets the Definition of Done.
To assess whether the Increment fully embodies empiricism, ask these questions:
Is the increment done and usable?
Does a Definition of Done exist?
Does the increment meet the Definition of Done?
Product Owner
The Product Owner represents the interests of the business or community product stakeholders through the content and order of the Product Backlog. The Product Owner may delegate this work but remains accountable for it, and no one can tell the Developers to work from any other list.
To assess whether the Product Owner fully embodying empiricism, ask these questions:
Is the Product Owner ensuring that the Product Backlog is transparent and shows what the Scrum Team will work on next?
Is the Product Owner ensuring that the Sprint Review is being used to both inspect the increment and adapt the Product Backlog?
Developers
Developers estimate, plan, and execute the Scrum Team’s work. They collaborate with the Product Owner to maximize Product Backlog value and determine what work items to pull into the Sprint (Developers own the Sprint Backlog).
To assess whether the Developers are fully embodying empiricism, ask these questions:
Are the Developers using the events to inspect and adapt (for example, are they using the Daily Scrum to review progress towards the Sprint Goal, and are they adjusting the daily plan accordingly?)
Are Developers delivering a done, usable Increment at least once per Sprint?
Scrum Master
The Scrum Master is accountable for establishing Scrum according to the Scrum Guide. It sounds simple, but it isn’t. Being a Scrum Master involves part art and science. The perfect Scrum Team does not evolve overnight. It can take years to become a high-performing unit. A wise Scrum Master knows what challenges to tackle first.
To assess whether the Scrum Master fully embodies empiricism, ask these questions:
Is the Scrum Master promoting empiricism by ensuring that the artifacts are transparent and accessible to appropriate stakeholders?
Is the Scrum Master promoting empiricism by ensuring that the events are being used to inspect the appropriate artifacts?
Is the Scrum Master promoting empiricism by ensuring that the events are being used to adapt? For example, is the Daily Scrum used to adjust the team’s plan to increase the likelihood of meeting the Sprint Goal?
Is the Scrum Master promoting empiricism by reinforcing the Scrum accountabilities as needed?
Conclusion
The journey towards the ideal Scrum Team doesn’t happen overnight. If you come across symptoms that your team is merely pretending to be agile, discuss what you’ve found at the Sprint Retrospective. Use this event to identify actionable improvements for your Scrum Team. For more ideas on the Sprint Retrospective, check out Rebel Scrum’s Ideas for Scrum’s Sprint Retrospective Event.
コメント