Why SCRUM Doesn’t Work for Me
I don’t know why I hate the Agile mindset. Perhaps I’m too old?
“I’d say that I’m too awesome at coding to require a methodology. Competent coders deliver code. Competent software development teams deliver software, not methods.”
What Works
Nothing is all bad in the world of software development. Nothing at all.
“CSS comes close.”
There are several features of Scrum I fully support.
Having a prioritized backlog? Simply makes sense and the rank order means developers know which tickets to pick off the top.
Tracking progress through burndown? I’m all for transparency, and love graphs.
In theory, daily standup gives a team of experts the tools they need to succeed and solve problems. Doesn’t work in every context but that doesn’t mean the idea is bad.
What Sucks
Self-organizing teams don’t work
The idea of a self-organizing team is diametrically opposed to management. Management needs to control the deadlines, resources, and people. Self-organizing teams run against corporate strategies and are therefore doomed to failure.
Outside help being parachuted into a self-organizing team to help them get ‘a handle on Scrum’ is obviously nonsense. Getting a Scrum expert to say the obvious, actually means that the team is less likely to be self-organizing, as they don’t learn themselves and move on to being the best software developers they can.
“Bit of a paradox, that.”
Fail To Save An Unsuccessful Team
I’ve mentioned before that the teams I work in are oftentimes packed with introverts. The Scrum framework mostly supports extroverted behaviors and disconnects the methods of creating software with actual progress.
You might be in a failing team.
“The Secret Developer raises their hand.”
When the interventions come from the Scrum team they seem to turn the process into a covert waterfall project. Just like the one I’m working on with 4 (four) week sprints “because we have a testing backlog”.
A bad team remains a bad team no matter which method is selected.
Bad estimates
We’ve never created software quite like this before. You might hear from your company that they need to know how much work you will do in this Sprint, and hold you to it.
That would be one thing, but you’ll never get clear requirements. How you’re meant to know how long something new will take, while not knowing what this thing quite is, I’ll never know.
Crunch
Waterfall methodologies were strongly associated with crunch. If you consider Agile and Agile Scrum to be the way software developers designed to get away from waterfall you might be disappointed.
Developers are still rushing to meet management deadlines
You might still need to take your sleeping bag to the office to get it done
“Waterfalls?
Isn’t that caused by the tears that fall as devs miss their children’s birthdays?”
Agile didn’t remove crunch. In some contexts, weekly sprints ensure that developers aren’t allowed any time for tech debt or learning at all.
“That works out great for them. I bet their staff retention is working out great!”
It’s a misreading of Scrum to focus on delivery and the estimates that developers give.
Conclusion
When an organization isn’t ready for an agile mindset, things can get difficult. It’s made even worse by misrepresentations of Agile that make software developer's lives worse.
You know what? Companies should develop techniques that actually help software artifacts to be produced. Actually helps software developers get work done. Help the delivery of products.
“Is that such a lofty goal?”