In some of my classes, people tell me they are using Scrum—but they can't call it Scrum. Why? Because someone in their organization had a bad experience with it.
What’s causing this?
Too many rules. Too many extra layers. Too much stuff added in the name of Scrum.
One student told me her company started using Scrum when they hired a vendor who claimed to be an expert. But that vendor piled on excessive documentation, endless approval gates, and rigid processes. Now, after that frustrating experience, the company won’t call anything “Scrum.” Even if they are using Scrum, they call it something else.
Rather than abandoning the name, these organizations need to rediscover what Scrum actually is.
Scrum is not a massive rulebook.
Scrum is not extra overhead.
Scrum is not user stories, approval gates, or any of the countless optional practices people pile on top of it.
Scrum is simple:
- 5 events
- And a mindset of inspecting, adapting, and focusing on value
Teams using Scrum should adopt the complimentary practices that work for them, and no more.
That’s it.
Stop the Waste, Keep the Name
If excessive process or documentation requirements are holding your team back, discuss it at the Retrospective. Here are a few simple exercises to help your team identify ways to simplify their processes.
Stop, Start, Continue - A simple "Stop, Start, Continue" exercise can help. In this exercise, the team makes a list of the things that they should Stop doing, the things that they should Start doing, and the things that they should Continue doing. Then, they identify one thing that they will take action on immediately.
15% - Start this exercise by acknowledging that there are a lot of improvement areas for your team, and they can't be solved overnight. Then, explain that a series of small steps is better than a drastic overhaul, so ask your team to brainstorm ways that they could simplify or improve their work by 15%. A series of 15% changes will have a drastic impact on the Scrum team over time. Then, select one thing and take action on it immediately.
Escalate - If there really are some requirements and restrictions beyond the Scrum team's control, the Scrum Master should escalate to leadership. Is the team being required to create excessive documentation? Discuss with the leadership team ways to reduce this burden. Is the team not truly cross-functional? Start with small steps. If you can't get the teams combined, can they refine together? Do a shared Review together? As the Scrum Master, your purpose is to improve the adoption of Scrum, and sometimes that means looking beyond the Scrum team and helping to cause change that makes it easier for the Scrum team to practice Scrum.
Why Call It Scrum?
Changing the name of what you are doing doesn't solve the problem. It simply hides it. If your team is using Scrum, call it Scrum. Here’s why:
Change Starts with Clarity – When you call it Scrum, you can help the organization see that all those extra rules didn’t come from Scrum. They were added. And if they aren’t helping, they can go. Dropping the name doesn’t fix the problem.
Access to Better Training and Resources – When you call it Scrum, you open the door to a vast world of learning. Coaches, courses, and a global community of practitioners are available to help. Rename it to something else, and suddenly, your team is on an island.
Avoid Reinventing the Wheel – Without a common language, every team has to explain their approach from scratch. Calling it Scrum means you don’t have to build everything from the ground up—Scrum already provides the foundation.
Conclusion
Scrum provides just enough (but not too much!) structure to help teams work together. It clarifies who is accountable for what, so teams can collaborate effectively. It includes artifacts that make progress visible, so teams can adapt and improve.
Scrum isn’t about rules—it’s about collaboration.
Scrum isn’t broken. The way people modify it sometimes is. Scrum is simple, so keep the name, drop the extra rules, and use Scrum for what it was meant to do—help teams deliver value.
Been there. Was the Program Manager for a large internal project. The only "traditional" IT project I've worked on in 35 years (all others were product development for sale to external customers). Having worked in Scrum for a few years leading up to that I thought I'd bring those experiences to this team, which was large (multiple Dev teams, Product, Sales, Manufacturing, etc.). Went to the new VP of IT and the response was "We're IT. We only do waterfall." So, I slowly introduced some "best practices" with different names. No daily scrums. Just once/day reviews (that the team quickly changed to twice/day because of the value). No Sprint Reviews. But got everybody together regularly to "show ou…