5 Ways Scrum Is Done Wrong
JT Turner I have been working with Scrum for over 8 years now and I have seen it done right and I have seen it done very wrong. Here are the top 5 ways I see companies do Scrum wrong and how to fix them.
1. Treating Scrum as a Rigid Process
The Problem: Many companies treat Scrum as a rigid, inflexible process that must be followed to the letter. They create detailed documentation about how every ceremony should be conducted and punish teams for deviating from the “official” process.
Why It’s Wrong: Scrum is meant to be adaptive. The whole point is to inspect and adapt based on what you learn.
How to Fix It: Remember that Scrum is a framework, not a process. Use it as a starting point and adapt it to your team’s needs. The Scrum Guide even says you can modify Scrum as long as you maintain its pillars and values.
2. Skipping Retrospectives or Making Them Meaningless
The Problem: Teams either skip retrospectives entirely or turn them into blame sessions where nothing actionable comes out.
Why It’s Wrong: Retrospectives are where the real improvement happens. Without them, you’re just doing waterfall in short iterations.
How to Fix It: Make retrospectives safe spaces for honest feedback. Focus on the process, not the people. Always end with specific, actionable improvements and follow up on them in the next retrospective.
3. Having a Scrum Master Who Isn’t Really a Scrum Master
The Problem: The Scrum Master is often a project manager in disguise, or worse, they’re just a meeting facilitator who doesn’t understand Scrum principles.
Why It’s Wrong: A real Scrum Master is a servant leader who helps the team and organization understand and implement Scrum. They’re not a project manager or a team lead.
How to Fix It: Invest in proper Scrum Master training. The Scrum Master should be focused on removing impediments, facilitating meetings, and coaching the team on Scrum practices.
4. Micromanaging the Development Team
The Problem: Management or Product Owners try to dictate how the work gets done, assign specific tasks to specific people, or constantly check on progress.
Why It’s Wrong: Scrum teams are supposed to be self-organizing. The Development Team should decide how to do the work.
How to Fix It: Trust your team. Focus on the “what” and “why” but let the team figure out the “how.” If you don’t trust your team to self-organize, you have a hiring problem, not a Scrum problem.
5. Ignoring the Definition of Done
The Problem: Teams either don’t have a Definition of Done or they ignore it when it’s convenient. Work gets marked as “done” when it’s actually just “code complete.”
Why It’s Wrong: Without a clear Definition of Done, you can’t have a potentially shippable product increment at the end of each sprint.
How to Fix It: Create a clear Definition of Done that includes everything needed to ship the product. This might include code review, testing, documentation, and deployment. Don’t mark anything as done unless it meets all criteria.
The Real Problem
The real problem I see is that companies want the benefits of Scrum without changing their culture. They want to be agile while maintaining command-and-control management structures.
As Bill Gates said: “Your most unhappy customers are your greatest source of learning.” The same applies to Scrum failures - they’re your greatest source of learning about what needs to change in your organization.
Final Thoughts
Scrum isn’t perfect, and it’s not right for every situation. But if you’re going to use it, use it properly. Don’t blame Scrum for failures when you’re not actually doing Scrum.
Remember: Scrum is simple to understand but difficult to master. It requires discipline, commitment, and a willingness to change. If you’re not ready for that, you’re not ready for Scrum.
The goal isn’t to do Scrum perfectly from day one. The goal is to continuously improve your implementation of Scrum based on what you learn. That’s the real spirit of being agile.