I sighed as I stared blankly at my laptop screen. Another sprint planning meeting was about to start, which meant another two weeks of frustration lay ahead.
I had such high hopes when I joined a team that used Scrum. It was 2013, and I was a Ruby on Rails developer who never used it before. The project manager who hired me promised it would bring more structure and predictability to the software development process. But in reality, Scrum only highlighted the existing dysfunction.
The product manager was coming to sprint planning meetings bursting with big ideas but few details. “We need to add a one-click customizable report generation feature!” she declared. Then, it was up to us, engineers, to figure out all the specifics on the fly.
This “iterative design” approach led to kludgy, debt-ridden code that became harder to maintain with each new sprint. Tasks that should have gotten simpler instead grew more complex as the codebase became a tangled mess.
But try telling that to managers. As far as they were concerned, user stories should have taken the same time, no matter how disorganized the underlying system became. So, when tickets started taking longer, they blamed me and the rest of the engineering team for being lazy and incompetent.
“Why are you delivering fewer and fewer story points?” the Scrum Master would demand during standups as if shaming us would suddenly make the work go faster.
On the engineering side of things, we’ve seen the writing on the wall months ago. We predicted problems as tech debt started piling up, but our concerns were dismissed.
When our warnings had come true, the development team was paying the price. Accused of intentional sabotage and sandbagging by managers, morale was almost nonexistent.
As the planning meeting kicked off, I wondered how much more of this I could take. I used to love coding, but after months of working in this team, I felt like just another cog in the dysfunctional Scrum machine. There had to be a better way to develop quality software, one that treated engineers with respect rather than disdain. After a while, I started looking for a project where management valued its developers as more than replaceable resources.
Why So Many Teams Struggle with Scrum
I’ve seen Scrum go wrong in a bunch of ways. For starters, all those short sprints and daily meetings stress people out. When a startup CEO is breathing down your neck to get more stuff done daily, you stop caring about writing good code. You hack something together to tell you’ve finished another story yesterday. Before you know it, your code is a mess.
Then there’s the Scrum Master role. They’re supposed to shield the engineers, keeping other managers from interfering so you can focus on work. But nine times out of ten, the Scrum Master doesn’t have the authority to actually say no to the VP or a C-level executive. The whole “self-organizing team” thing sounds nice in theory, but good luck with that at most companies.
Plus, you’ve got to consider how much time these Scrum meetings take away from building things. After a while, you realize you spend more hours talking about work than doing work. Developers get fed up sitting in another 3-hour sprint planning meeting when they’d instead be writing code.
Finally, Scrum is extremely prescriptive and keeps you from improving your process. You’re trapped doing everything according to “The Scrum Guide,” even if it’s not working for your team or you’re not doing Scrum. Instead of having open conversations about getting better, it’s lather, rinse, and repeat the same rituals every two weeks.
And don’t even get me started on story points and velocity. They’re supposed to increase transparency, but let’s be real — they make people anxious that others are judging them on some arbitrary metric. Developers cringe when they have to provide estimates in story points that are not a measure of time but, at the same time, are used to determine how much you can do in a week.
I understand that Scrum has good intentions. But in the real world, all its excessive rules and metrics often do more harm than good.
Scrum is like communism. It fails everywhere, every time, but they tell you, “You aren’t doing it right.”
- Santiago Valderrama
Moving Beyond Scrum
If Scrum isn’t working for your team (and chances are it doesn’t if you’re reading this), you have options. Let’s go through some ways to keep the good stuff from agile while skipping the parts of Scrum that are making everyone miserable.
Waterfall Variations
Sometimes, your team just needs a little more planning upfront, especially if the features you’re building are complex. I know Scrum is supposed to embrace change, but if you’re constantly building the wrong things and having to redo work, a little bit of design thinking early on can go a long way.
When I started working as an engineering manager, I went nuts with our distributed team because people kept going in different directions. Taking time to create some lightweight specs and envisioning the architecture gave them a common starting point and solved the problem. They still iterated and got feedback, but it wasn’t chaotic anymore.
Kanban with Priority Queue
If Scrum’s rules and rituals burn people out, Kanban could be the cure. My friend Rob, a backend engineer, was ready to quit because their daily standup had become toxic. Switching to a Kanban board with a backlog of prioritized work saved his team. There were no more sprints, just pulling the next task from a huge backlog. Suddenly, work seemed manageable again to him. I asked him again how things were going recently, and morale was sky-high.
Ad Hoc Adaptations
You don’t have to follow Scrum exactly as written in the Scrum Guide. In our team, we realized that daily standups were completely unnecessary, so we skipped them. Cutting them to once a week has worked like magic for us for years. Don’t be afraid to customize processes to make your team happy and productive.
The goal is to keep the agile spirit while making work enjoyable. Give your team the autonomy to shape rituals that work for them. There are no silver bullets, but options exist to regain your mojo.
While Scrum intends to facilitate agile development, inflexible rituals, and rules cause it to routinely fall short. For any process to work, teams need the freedom to adjust it to their context instead of having it imposed rigidly.
Originally posted on Medium.com
