Scrum is a framework, not a set of work instructions. There aren't endless pages of process flow diagrams, no detailed agenda for each event, or guidelines for how many Product Backlog items you need and how you should write them.
Instead, the Scrum Framework is very lightweight, and it seems to get less restrictive with each release of the Scrum Guide. What is included is really important, though. Every piece of the framework is there for a reason. In this article, I will discuss five common ways that teams modify the Scrum framework and the negative impacts of each.
Not Delivering value incrementally
In my experience, the most frequently missed element of Scrum is the concept of incremental delivery. According to the 2020 Scrum Guide, “Scrum employs an iterative, incremental approach to optimize predictability and to control risk.” According to Scrum, each Scrum Team - or set of Scrum Teams working on a single product should deliver a usable increment each Sprint. Usable — meaning if the product involves software delivery, it should work at the end of each Sprint.
Teams overlook this element of Scrum — a lot.
Imagine a team building an online car insurance application involving 5,000 fields. The approach to this work should look quite different depending on whether a team is using a traditional waterfall or agile approach. The waterfall team might first build the database with all 5,000 fields. Then, they might create the data interface. Finally, they would deliver the front-end user experience. If there are technical issues, such as the database not working well with the front-end software, they might not discover that until the end of the project because there is low visibility into the progress of the work along the way.
A Scrum Team building this application should deliver a working product with each Sprint. For example, they might build a database, data interface and user experience for the first four fields in one Sprint. In the next Sprint, they might deliver a working application with the following four fields. Each time they complete a Sprint, what they deliver should be usable (Done), even if it is not all 5,000 fields. This approach allows Scrum Teams to discover any technical issues early. They also get stakeholder feedback at each Sprint Review and develop ways to improve their processes at the Sprint Retrospective.
But this is not what always happens. Instead, many supposedly “agile” teams approach the work the same way as a team using a waterfall approach. Instead of delivering a working product incrementally, they fall into the trap of trying to build the database for all 5,000 fields, the data interface for all 5000 fields, and the front end for all 5000 fields. What happens then, of course, is that it takes several sprints to get to Done.
This team might use all five Scrum elements. They may have all three accountabilities. But, they are not fully embracing the Scrum framework because they are not delivering a usable increment each Sprint.
The result of not delivering value incrementally
Teams who ignore incremental delivery don’t get the full benefits of Scrum. They are hampered by lower work visibility, are less able to change direction, deliver business value slower, and cannot reduce risk as early as teams who fully embrace incremental delivery.
Adopting Scrum involves a mindset shift — requiring us to work and think differently. Rather than looking just at the end delivery, teams should sort out the most valuable thing to do next and do it.
Skipping the Sprint Retrospective
Another way teams sometimes modify Scrum is to skip the Retrospective. When they are under pressure to deliver work, some teams see skipping the Retrospective as a way to “save time.” This one really breaks my heart because the Retrospective is a valuable opportunity for the team to inspect themselves and improve how they work together as a team.
The result of skipping the Retrospective
It’s not much of an exaggeration to say that the result of skipping the Retrospective is catastrophic. Teams that use the Retrospective to make small improvements in how they work together will not recognize themselves in six months. A series of minor improvements makes a bigger impact than any massive one-time re-write of the process could be. Small improvements are less disruptive than large improvements and allow the team to reflect frequently on what is not working and what is working. Teams who do not take these small improvements tend to be lower-performing teams and do not deliver value as quickly to the organization.
Eliminating the Scrum Master accountability
Organizations attempting to save money sometimes eliminate the Scrum Master accountability to reduce the headcount.
The result of eliminating the Scrum Master accountability
The irony here is that the Scrum Master’s purpose is to improve the adoption of Scrum, resulting in earlier value delivery and more efficient teams. If there is no Scrum Master, the team will likely be lower performing, which delays value delivery resulting in higher costs to the organization.
No Product Goal
Many Scrum teams do not realize that the Product Backlog should contain a Product Goal. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next. An example of a product goal for a web application might be to decrease shopping cart abandonment or increase sales.
The result of not having a Product Goal
Teams without a Product Goal have reduced focus and opaque measures of progress. They are like a ship without a rudder — they may go somewhere, but is it the right somewhere? Who knows? Without a Product Goal, it is hard to evaluate whether the product is heading in the right direction or whether the ordering of the Product Backlog makes sense. In addition, the Product Goal provides transparency to the team and its stakeholders. Without a Product Goal, it is harder to understand the product strategy, resulting in a loss of transparency for the organization.
No Definition of Done
A Definition of Done (DoD) describes all the work the team needs to complete for each Product Backlog item before considering it Done. As the 2020 Scrum Guide poetically puts it, “The moment a Product Backlog item meets the Definition of Done, an Increment is born.”
Imagine that your Scrum Team is baking a batch of cookies this Sprint. Each team member might have a different idea of when the cookies are “Done.” For some, it is when the cookies come out of the oven, while others believe it’s when they are on the cooling rack. Still others might consider the cookies done after they put them away and clean the kitchen. A DoD offers the Scrum Team a guide for how much work they need to do before considering each Product Backlog item Done. This information provides the Developers with critical guidance for how many Product Backlog items they can pull into the Sprint.
A Definition of Done provides transparency to all stakeholders, clarifying what it means when a Developer says that a Product Backlog item is Done. Does it mean the item has just been tested or tested and integrated into the main code base? The DoD makes it clear.
The result of not having a Definition of Done
Without a common understanding of all of the work that needs to be completed for each Product Backlog item for it to be Done, it’s unclear how many items the team can pull into the Sprint. Pulling in too many items will risk meeting the Sprint Goal.
An unclear DoD will also mean the Scrum Team and its stakeholders will not have transparency regarding the Increment delivered. For example, the Product Owner might not know the level of performance testing happening. For a software product, this might mean that some Developers are conducting code reviews and some are not. Or, some Product Backlog items might be development-only stories, and some may be testing-only stories.
This lack of transparency around the Increment reduces the team's adoption of Empiricism. 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. (See our recent article Is your Team “Pretending” to be Agile? for a fuller discussion of Empiricism.)
Conclusion
Adopting the Scrum framework is the first step towards a better way of delivering complex products. It can be tempting for those newer to Scrum to think that modifying some Scrum elements will make it easier to adopt, but it’s the opposite. When teams modify the Scrum framework, they are not experiencing its full benefits, likely resulting in lower-performing teams and slower value delivery to the organization.
New to Scrum? I recommend the Applying Professional Scrum (APS) course. APS allows those new to the framework to understand the Scrum roles, artifacts and events. Both public and private classes are available.
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 training classes or contact us to discuss private Scrum training and consulting options for your organization.