The problems with Scrum
You might be wondering why everyone talks about Scrum so much. Often when I write about Agile on this blog, I’m pretty much talking about Scrum. It is the most widely used and known methodology for Agile software development in the world.
Remember, Agile is not a methodology, it is a set of values and principles. Agile is a philosophy and a mindset. Scrum is a methodology, so is Extreme Programming, Crystal, etc. Scrum is successful because it is simple (pretty easy to learn) and powerful (easy to apply). It is a common methodology that people choose when they want to try adopting the Agile mindset and philosophy.
However, Scrum is not perfect. (Nothing is). There are some problems with Scrum, and you need to know about them before applying it. They are not fatal flaws but it is helpful to be aware of them.
Scrum is unclear on how to manage the product backlog
Scrum talks about backlogs: the Sprint Backlog and the Product Backlog. The Sprint Backlog is straightforward: it is the scope of work for the sprint. Any user stories that are about to be worked on in a sprint get moved into the Sprint Backlog. The Product Backlog is different: it is the collection of ideas about what might go in the product in the future.
Scrum gives very little guidance (pretty much none) on how to manage your product backlog. Without training and experience, product owners will be completely lost, and probably just go crazy writing a hundred random user stories and features and stuffing them all into a tool.
This is not a good approach. At best, you will end up with a bag of leaves instead of a tree (go read this: The New User Story Backlog is a Map if you want to read more about that idea). At worst, you will end up with your team spending half or more of their time trying to estimate and figure out all these random ideas, most of which won’t get built, and some of which won’t add much value if they do.
If you need more guidance on managing your product backlog, I would recommend you read my article on Product Backlog Misconceptions. If you want to learn a really good system for managing a product backlog, I would recommend User Story Mapping by Jeff Patton.
Scrum and product backlog management
There are dozens of good approaches to product backlog management, like Story Mapping (see above), Impact Mapping, Lean Startup, Design Thinking, etc. Scrum just says “there’s a backlog! The product owner can put whatever they like in there! Go nuts!”. Which seems fun and “lightweight” and “flexible”, but it is a problem for a lot of people.
Some would say that Scrum is a “software development methodology” (let’s build software that matches the idea for this product). Rather than a “product management methodology” (let’s come up with some ideas for a product that solve some customer problem). Which is fine, but it’s a bit of a cop-out because you can’t really have one without the other.
Scrum puts too much emphasis on delivery predictability
Scrum puts probably too much emphasis on trying to generate predictability around delivery. That is, things like story point estimation, velocity, burndown, etc. Those can be useful things but they can be easily seized on by middle managers to shoehorn the team into big defined “predictable” releases and “performance measurement / management”, which is just a horrible thing to do (read this: Servant Leadership and management by measurement)
It is difficult to find a solution to this. One extreme solution is the #NoEstimates movement, who say that all estimation is a waste of time. I like some of their ideas but I think it is probably going a bit too far. Personally I think estimation is not very valuable, and we should put more emphasis on reducing the uncertainty around benefits rather than around costs. I encourage my team to do some high level estimation, and to spend a small amount of time on story point estimation, if they feel it is valuable.
Lightweight estimation can be useful for release planning. But organisations need to accept explicitly that software delivery is notoriously difficult to predict and measure, and that’s fine, and we need to all get over it and get along with our jobs. The last thing we need is uncomfortable conversations that start “I thought you said this would only take one sprint?!”.
But Scrum goes on and on and on about this stuff, which gives middle management the wrong idea and encourages them to use points and velocities as levers to manipulate teams. Which is not fun for anybody.
Scrum pretends there is nothing outside the scrum team
Another of the problems with scrum is that it abstracts away the entire organisation outside the scrum team. It recognises only the product owner, scrum master, and a few “developers”. Nobody else exists according to Scrum. Of course, other people will exist in an organisation. Even a small startup will have a CEO, sales / marketing person, accountant, and so on. Larger organisations may have thousands of people not in a scrum.
In a way, this blindness is actually an advantage. That’s because it doesn’t let those outside organisation people sneak into the scrum process. And that’s good because they don’t belong there. Scrum tries to limit the ability of non-participants in the agile software development process to mess with the agile software development process. Which sounds great.
But it provides NO guidance for how the poor scrum master is to facilitate the boundary between the scrum and rest of the organisation. This is fundamentally the big unsolved problem of “how to scale agile” that you hear people talking about. Some would say that Scrum’s inability to answer this is by design and I’d say that’s right. But it’s still a problem that a lot of people get stuck on and I think adding a big framework like SAFE isn’t necessarily the right idea.
Scaling scrum
Big complex “scaled agile” frameworks encourage the rest of the organisation to go on pretending we’re all still living in 1996, doing Waterfall and monolithic applications and requirements-driven design and silo business unit IT all the other balderdash we’ve moved away from because it was generally horrible. They talk about big “product increments” that we have to have giant meetings and workshops to define. Really agile organisations have everyone work in small increments, not just software development.
It’s a hard problem and I’m not saying I have the easy answer. If I did I’d write a book and course about it and become rich and drink cocktails out of a pineapple on a beach. But pretending the problem doesn’t exist doesn’t help either.
Anyway, this post should probably ruffle up a few feathers – let me know what you think in the comments!
