Why I Hate Scrum: Forcing Software Engineering Into a Box
An architectural critique of how modern Scrum mechanics stifle creative engineering, weaponize velocity, and fail to account for technical uncertainty.
🚨 Why I hate Scrum methodology for Agile
After working with Scrum teams for years (with different levels of taking it seriously), I’ve come to believe that Scrum is often a poor fit for the kind of work many software engineers actually do.
Scrum assumes that:
• You can predict and estimate the effort of each ticket • Work can be broken into neatly sized chunks every 2 weeks • You can commit to delivery based on those estimates
✅ That might work if you’re fixing bugs or building familiar features.
🚨 But in reality, many of us are doing work that’s uncertain, creative, or exploratory: • Integrating new technologies • Making architectural decisions • Designing from scratch • Dealing with changing or unclear requirements
In these situations, estimation turns into fiction 💭— and planning meetings become painfully long . We spend an enormous amount of time just trying to estimate tickets, only to find that the estimates are wrong anyway 😮💨.
Instead of helping, Scrum often adds pressure:
“Will we finish the sprint?” “Why did this ticket take longer than expected?” “What’s your velocity this sprint?”
⚠️ Especially in the wrong culture, velocity becomes a managerial weapon 🔫:
• Teams are judged by how many story points they “burn”🔻 • Developers are compared by how many points they complete
🎯 The result? A culture of stress that kills creativity and innovation.
🔄 Agile was meant to embrace change and complexity. Ironically, Scrum often tries to control it — and that’s where the tension starts.
If you’ve felt this friction too, you’re not alone.
Let’s stop forcing creativity into a box. Let’s build a process that respects uncertainty and supports real thinking.
💬 Curious to hear others’ experiences — has Scrum helped or hurt your team?