Scrum is not a set of work instructions; it’s a framework. Scrum relies upon the collective intelligence of those using it to figure out how best to apply it in their situation. However, many take this to mean that they should figure out how to modify Scrum itself to suit their situation.
That is not the case.
It means that teams should choose the complementary Scrum practices and Sprint duration suitable to their environment, not modify the Scrum framework itself. When people say that they are “customizing” Scrum, what that means, in reality, is they are deliberately breaking it.
Don’t customize Scrum. Customized Scrum isn't Scrum!
As a minimalist framework, Scrum contains only what is needed. Every piece of the Scrum framework is there for a reason. When teams modify any part, they won’t get the full benefits of Scrum and they can't call it Scrum. In this article, we will discuss three of the worst Scrum “customizations.” Warning: don’t try these in your organization!
#1 Develop in one Sprint; test in the next
The Scrum framework relies on an iterative, incremental approach to optimize predictability and control risk. Every Sprint, the Scrum Team (or teams) should deliver an increment of usable product. Newer teams can find frequent delivery intimidating and might decide to take a modified approach, which in many cases means developing in one Sprint and testing in the next.
Why it’s a bad idea
First, dividing development and testing into two Sprints limits organizational agility. It will take the team a minimum of two Sprints before they can demonstrate a Done product for any item. If the customer doesn’t like the feature, it will take at least two Sprints before the team finds out. Modifying Scrum this way limits the team’s ability to change direction, delays business value and increases the risk of delivering something that doesn’t work. Bug fixing what the team produced becomes a nightmare, too, and quality suffers.
Second, this approach becomes a huge administrative burden. Teams splitting their work into two Product Backlog items add the cumbersome task of linking them together. Or they create separate development and testing tasks under a single Product Backlog item that needs to remain open over two Sprints. In this case, they have no way of knowing what their actual velocity is since some of the work is done in one sprint and some in the other, hampering their ability to forecast accurately or plan future Sprints.
Modifying Scrum to develop in one Sprint and test in the next is extremely limiting and is the worst “customization” of the bunch. Teams who develop in one Sprint and test in the next are not adhering to the Scrum framework, because the purpose of each Sprint is to develop a Done, usable increment of valuable working Product.
Try this instead:
The purpose of each Sprint is to deliver a usable Increment of value. The first task is to get the team’s agreement on this purpose. Next, if the organization doesn’t have a Definition of Done, work together to create one that describes all of the work required on each Product Backlog item before it can be considered usable. Then, establish a plan for refining items in the Product Backlog to ensure that higher ordered ones are sized such that the team can complete them within one Sprint. Finally, give it a try and use the Sprint Retrospective to identify improvement opportunities.
See our article Three Steps to Done in Scrum (rebelscrum.site) for more on this topic.
#2 Eliminating the Sprint Retrospective
Time is a limited resource. In facing this reality, some Scrum Teams will suggest eliminating the Sprint Retrospective to “save time.”
Why this is a bad idea
The purpose of the Sprint Retrospective is to discuss ways Scrum Team members can better work together. It’s also an opportunity to discuss the quality of work, possibly updating the Definition of Done to improve it. Scrum Teams struggling with having enough time to accomplish their work need the Retrospective more than anyone. Here, they can identify and remediate impediments and find innovative ways to move work forward. Skipping the Retrospective leaves potential improvements off the table, which can result in actual time wasted.
Try this instead:
Keep it productive
To keep the Sprint Retrospective productive, ensure the event results in one or two actionable ideas for improvement—and then be sure to implement those improvements! Nothing is more demotivating than continuously brainstorming action items that no one carries out.
Additionally, don’t allow the Retrospective to become a vent session. It is up to the Scrum Master to ensure that this event is positive, productive and kept within the timebox.
See our article Ideas for Scrum’s Sprint Retrospective Event | Scrum.org for ways to keep this meeting from becoming stale.
#3 Turning the Daily Scrum into a daily marathon
The Daily Scrum is a 15-minute collaboration event for Developers to inspect progress and adjust work to increase the likelihood of delivering an Increment that meets the Sprint Goal. Sometimes, the team chooses to ignore the timebox. Instead of a quick collaboration, the Developers participate in an exhausting hour-long marathon event where the whole team goes down various rabbit holes to solve problems involving one or two Developers.
Why this is a bad idea
According to the 2020 Scrum Guide, “Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.”
A Daily Scrum exceeding the 15-minute timebox, creates a lot of waste, which is not in line with lean principles.
Try this instead:
If you identify weighty impediments and collaboration opportunities during the Daily Scrum, anyone who wants to participate can do so in “the 16th minute” meaning after the timebox. By doing this, we protect the Daily Scrum for identifying issues, not necessarily solving them if they involve deeper, targeted collaboration. Those who do not need to be part of the discussion can opt-out and get on with other work.
Conclusion
When people say that they are “customizing Scrum” what it really means is that they are breaking the framework.
Don’t customize Scrum. If you do, you won’t experience the full benefits of the framework. Instead, apply Scrum as it is designed and see if it works for you.
What are the worst Scrum “customizations” you have seen? I’d love for you to share them in the comments below!
____________________________________________________________________
Is your team struggling with Scrum? For those who have never received formal training in Scrum, I recommend the Applying Professional Scrum course, which offers the best overview of the accountabilities, events, and artifacts necessary for a high-performing Scrum Team. The whole team can take this class so that everyone has an expectations baseline for how they will work together using Scrum. Contact Rebel Scrum to schedule a private class for your Scrum team or sign up for one of our upcoming Applying Professional Scrum public classes.
For those taking on the Scrum Master accountability, I recommend the Professional Scrum Master course.
If you’re interested in learning about the simplest way to scale multiple Scrum Teams working together on a single product, the Scaled Professional Scrum class will show you how using the Nexus framework.
Comments