I think Scrum, applied pragmatically is a great way of working, however depending on people and culture, it has a number of short comings and pitfalls that I have noticed over the years. Someone defending Scrum might (partially justified) defend Scrum by saying that people who fall into these pitfalls are doing it wrong, but at the same time, if it is easy to fall into the anti-patterns based on the “default” way of working, I would say the pitfalls are very much part of Scrum. Those old enough to remember probably have some clue about all the pitfalls of Rational Unified Process when it was big: most RUP implementations became bastardizations of the core purpose of RUP, but nonetheless tainted its reputation to the point where it is barely used anymore.
So what are the pitfalls? Here’s my take:
Task rather than outcome focus
Though user stories and conditions of satisfaction are the target, due to the way Scrum does sprint planning it is easy to fall into being task focused rather than outcome focused: in practice this means people become more focused on moving around task cards on the board rather than take the next logical action that will contribute towards achieving the goal of the user story. This results in a lot of waste when meaningless tasks are done regardless, and sometimes meaningful tasks being omitted, resulting in missed conditions of satisfaction and non-delivery.
Sprints as mini-waterfalls
For all the aggressive posturing against waterfall methodologies from a lot of Agilists, Scrum is certainly very prone to the same failings as waterfall methodologies but just on a shorter time span: the task orientation and way sprint planning is done often gives both management and team members the false sense of security that everything can be known and planned for in a Sprint. Not any more true for Scrum than for traditional project methodologies: what you know will rarely bite you. What you don’t know that you don’t know most definitely will.
Scrum invites micro-management
Again, the strong task focus of Scrum is an open invitation for micro-management by Seagull managers and those team members and stakeholders prone to it. This is a very real risk that could kill the flow that a team might have.
Story pointing is too course grained and as inaccurate as any sort of estimation
In my experience and opinion, any estimate that is on a scale of higher than a day is likely to have an error margin up or down of 100%. Any estimate that is on a scale of more than a week can effectively be replaced by “I don’t have a f***in clue”. Though story pointing may look like a holy grail for managers wanting to extrapolate things like velocity, progress and likely time lines they are will probably be no more accurate than the good old guesstimates of waterfall projects.
If you used a pseudo-random number generator with a story-point distribution like a bell curve with a bias towards 2 or 3 points, I’m pretty sure it would be just as accurate as most peoples story point estimates.
“Let’s play Sprint sudoku!”
Ever seen a sprint board for a largish team? Chances are it will read like an advanced sudoku board, with cards all over the place. Is that really achieving visibility of the work to be done? Is that visualization worth anything at all? Is having 10 stories and 100 tasks on a board conducive to people keeping focus and actually finishing any of the stories?
Does all this mean I am dismissing Scrum out of hand? Not at all. But I do think being aware of the potential pitfalls is important, and that Scrum is not perfect by any means. A methodology and process will never be a replacement for good judgement and common sense.
I personally like some of the things coming out of the Lean/Kanban camp, if applied with common sense and judgement. On a project I am working on at the moment we have tried to mix in some of these practices (WIP limits, work queues etc) to minimize the risk of some pitfalls, and the initial signs are promising.
