Why Teams adopted Scrum during the Pandemic
The human cost of the pandemic has been devastating. We lost loved ones. Many of us lost businesses and jobs. Many more are still working from home two years after the pandemic's start. Our lives have changed forever, and they cannot change back.
Amidst all of these dramatic upheavals, there was another change. During the first year of the pandemic, Scrum adoption more than doubled for software development teams. According to the 15th Annual State of Agile Report, the use of agile approaches for software development grew from 37% in 2020 to 86% in 2021. This means that agile adoption for software development doubled in a single year — the first year of the pandemic. I don’t think that is a coincidence.
Why, during a year of such turmoil and devastating human loss, would a particular framework experience such dramatic growth? I think that the root cause comes down to the fact that agile frameworks in general — and Scrum in particular — offer much greater transparency, accountability, and opportunities for collaboration than traditional methods.
When teams went remote due to the pandemic, they needed a way to provide transparency to other team members and leadership about what they were working on. The Scrum framework offers transparency through the three artifacts of Scrum: the Product Backlog, the Sprint Backlog and the delivery of a Done Increment which meets the Definition of Done each Sprint.
The Product Backlog
The Product Backlog is an ordered list that contains all of the work the Scrum Team will undertake. It is, in essence, the plan for what the Scrum Team will do next. Each item on the Product Backlog is ordered, provides a description and is sized. That means the Product Backlog is not just a list; the team can use it to forecast upcoming delivery timelines. The Product Backlog also includes a commitment in the form of the Product Goal, which is the Scrum Team’s long-term objective that describes the future state of the product.
How the Product Backlog promotes transparency
The Product Backlog offers management and other team members a window into what the Scrum Team is working on at any time. The Product Goal provides transparency to stakeholders about where the product is heading. Having this information continuously updated and available in a centralized location is tremendously helpful to management and other team members in a remote environment. When my team abruptly moved work home at the start of the pandemic, many of us wondered how that work would continue. Having a Product Backlog that provided information in a central location was invaluable and helped make the transition to working from home more manageable for Scrum Teams.
The Sprint Backlog
The Developers create the Sprint Backlog during the Sprint Planning event. As its owners, the Developers update the backlog daily as their work progresses. The Sprint Backlog contains a list of the Product Backlog items selected for delivery (what). It also includes the Sprint Goal, which describes the purpose of the Sprint (why). And finally, it contains the plan for delivering the selected Product Backlog items (how).
How the Sprint Backlog promotes transparency
At any moment, team members — or anyone with access to the Sprint Backlog — can see the Sprint’s progress. The Sprint Goal allows Developers and stakeholders to see what the team will deliver in the Sprint. This kind of transparency is particularly important for distributed teams where members cannot easily talk to each other to ask a quick question.
At least once per Sprint, the Scrum Team delivers an Increment of usable product that meets their Definition of Done. Usable means that the team has delivered an item with end-to-end functionality. The Definition of Done is the team’s description of the work required to complete each Product Backlog item.
How the Increment promotes transparency
Delivering a Done increment each Sprint increases transparency because stakeholders can frequently inspect what the Scrum Team produces. In a remote environment, this kind of transparency is essential because it ensures the Scrum Team is in touch with stakeholder and customer needs. (For more about Incremental delivery, check out our recent article What is Iterative, Incremental Delivery? The Hunt for the Perfect Example.)
When organizations rapidly transitioned to a remote environment during the pandemic, it became more important to ensure that everyone understood their responsibilities and how they contributed to the team. The Scrum framework promotes clarity through three accountabilities: the Product Owner, the Developers and the Scrum Master.
The Product Owner represents the interests of the business or community product stakeholders through the content and order of the Product Backlog. They may delegate this work but they remain accountable, and no one else can tell the Developers to work from any other list.
The Product Owner accountability
The Product Owner is the bridge between corporate strategy and the Scrum Team. The Product Owner is accountable If the team is not delivering the right value to the organization or is delivering work unaligned with organizational goals because they are the one who decides what the team works on. The Product Owner sets the course for the Scrum Team, ensuring the Developers have clear direction from a single place rather than multiple sources. In a remote environment, being clear about what work is needed and in what order is critical. (Check out our recent article, Characteristics of a Great Product Owner for more on the Product Owner accountability in Scrum.)
Developers estimate, plan, and execute the work of the Scrum Team. They collaborate with the Product Owner to maximize Product Backlog value and determine what work to pull into the Sprint (Developers own the Sprint Backlog). There are no hierarchies among Developers on a Scrum Team; everyone is accountable for working together to deliver a Done increment which meets the Sprint Goal at least once per Sprint.
The Developer Accountability
The Developers decide how the Scrum Team delivers the work. No one, not even the Product Owner, tells Developers how to deliver their work. This clarity promotes Developer accountability because team members know where each person’s responsibilities end and where the next begins. The Product Owner orders the work; the Developers deliver the work. Simple. Clear. No confusion.
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 more art than science. The perfect Scrum Team does not evolve overnight. It can take years to become a high-performing team.
The Scrum Master Accountability
The Scrum Master ensures that Product Owners, Developers and those interacting with the Scrum Team understand the importance of clear accountabilities. This clarity helps the Scrum Team deliver value to the organization by reducing conflict and opening the path to high performance.
When the pandemic forced us to a remote environment, those using Scrum in my organization had a much easier time adjusting than those using traditional project methods. The rigor of the five Scrum events explained below ensures that remote team members collaborate effectively.
The 2020 Scrum Guide states, “Sprints are the heartbeat of Scrum, where ideas are turned into value.”
How the Sprint promotes collaboration
The Sprint is a container event for all other Scrum events. It starts with Sprint Planning, ends with the Sprint Retrospective and has a maximum one-month timebox. So, at least once every 30 days, the team gets together to see how the previous Sprint went, discuss ways to improve their processes and plan for the next Sprint. This frequent feedback loop really is the heartbeat of Scrum, ensuring that Developers frequently collaborate with the Product Owner, Scrum Master and stakeholders. (Check out our article 5 Misconceptions about Scrum's Sprint Event for more about the Sprint in Scrum.)
At the Sprint Planning event, the Scrum Team meets to inspect the Product Backlog and create a plan for the upcoming Sprint.
How Sprint Planning Promotes Collaboration
Sprint Planning is highly collaborative and involves Developers, the Scrum Master and the Product Owner meeting to select the Product Backlog items to deliver in the upcoming Sprint. Developers decide how they will deliver the selected Product Backlog items and determine their Sprint Goal with the Product Owner and Scrum Master. They capture this information in the Sprint Backlog.
The Daily Scrum is a 15-minute daily event where Developers inspect progress towards the Sprint Goal and adjust the Sprint Backlog accordingly.
How the Daily Scrum promotes collaboration
At the Daily Scrum, Developers discuss how the Sprint is going. This is an opportunity to identify any impediments the team is experiencing and create a plan for the next 24 hours. The short timebox prevents waste and serves to increase collaboration because 15 minutes is not a huge time investment — anything longer tends to result in poor attendance. (Check out our recent article, The Daily Scrum event: 5 surprisingly common misconceptions, for more on the Daily Scrum event.)
The Scrum Team and product stakeholders to come together in the Sprint Review to see what the Scrum Team accomplished in the Sprint and collaborate on what to do next to deliver the most value.
How the Sprint Review promotes collaboration
The Sprint Review is all about collaboration. As the result of stakeholder feedback and collaboration, the team often updates the Product Backlog, and it’s also an opportunity to inspect the progress towards the Product Goal. As a Product Owner myself, I frequently get terrific ideas from stakeholders about innovative new Product Backlog items that could help the Scrum Team make faster progress towards the Product Goal. (Check out 5 Activities to Spice Up Your Next Scrum Sprint Review.)
During the Sprint Retrospective, the Scrum Team inspects itself, collaborating on better ways to work together.
How the Sprint Retrospective promotes collaboration
The Sprint Retrospective promotes collaboration by defining a space for the Scrum Team to discuss how they can improve the way they work together. During this event, the team discusses how the Sprint went regarding individuals, interactions, processes, tools, and their Definition of Done. As an outcome of the Retrospective, the team identifies ideas for improvement and implements them as soon as possible. In essence, they are looking for ways to improve their collaboration. (For more about the Sprint Retrospective in Scrum, check out our recent article The Power of the Sprint Retrospective.)
The world has changed for good since the pandemic. It has altered the way we live and work together. Despite all the pandemic’s significant grief, it has had some bright spots. I believe that the rapid adoption of Scrum during the pandemic is one of them.
Scrum is very attractive to distributed teams because its core features address the key challenges of remote work. The Scrum framework provides increased transparency through the Scrum artifacts (Product Backlog, Sprint Backlog and Increment), accountability through the three Scrum accountabilities (Product Owner, Developers and Scrum Master) and opportunities for collaboration through the five events (the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective).
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum trainings or contact us to discuss private training and consulting options for your organization.