Reasons to hate scrum
It seems like lots of people hate scrum, and you can now add me to that list. I do think that some of the criticisms I’ve heard are a little unfair, and defenders rightly point out that the complaints are mostly against bad implementations, the so-called flaccid scrum. But you can only use that defence so often before a different question needs to be asked. Why are there so many bad scrum implementations?
Scrum is popular because it seems like a smaller step from traditional project management techniques. This gives it some appeal with managers who might be put off by more radical sounding agile ideas, like that software developers are capable of planning and organising their own work.
To this type of manager, scrum has many benefits. It has a clear “controlling” role, and although the scrum master is not officially a project management role, it can (and I wager, usually is) be subverted to essentially that. It has a backlog that can end up looking just like a familiar requirements specification and a special role that basically owns the list of requirements. Sure the product owner should represent the users / stakeholders, but very often a proxy is put in their place serving only to be a gatekeeper of information about the product and the direction it should go in.
Now turbo-charge the whole thing with something like Jira. Everything can have an estimate (sure they are story points but its a simple calculation to turn that into time), we can log time against every ticket, we can have burn downs, burn ups and all sorts of other graphs to analyse. We can use this information to optimise our resource usage for maximum efficiency. If things are going badly, we can shake up the backlog, slice things up differently, add more information, pre-allocate tickets to appropriate devs, maybe re-estimate everything now that we have lots of new data — round up the dev team for another round of planning poker…
Sound familiar?
Scrum wants to have its cake and eat it. It wants to be agile, and so talk
about nice stuff like incremental delivery and continuous improvement, but it also wants to keep traditional managers happy, so it retains an emphasis on control, with backlogs, estimation, planning etc. Scrum encourages these things. It elevates the process alongside the actual work rather than trying to keep overhead to a minimum. Pretty soon it can feel like the focus is less on making software than it is on making the velocity number go up.
Hey, did you log a ticket for that extra task you did? That must have been a 4 pointer which would push us over our rolling average!
Agile principles are supposed to be a humble recognition of the reality of making software, but scrum leaves room for old school hubris, like knowing the future (of course we know exactly which tickets we can complete in a given time frame) and maximising efficiency.
I think more value will be delivered in less time if we stick to the real
agile principles and focus on building quality software, rather than how fast we appear to be going. Give people more time to think about the problems and the solutions, talk to users, do some experiments and use their creativity rather than trying to create a better production line.
For these reasons I now think scrum is a bad methodology, especially for teams with little agile experience. I’ve no doubt an experienced agile team could make it work effectively, but then for them the rituals and rules of scrum would not really be necessary. I was joking with a friend the other day about how a new agile methodology was needed that didn’t make such a big song and dance about the process. I ended up knocking together an “agile flow chart” that covered what I think are the main aspects of software development. It was done for a bit of a laugh but I can’t help but think it has some benefits over actual methodologies:
1) Its not a methodology. It doesn’t elevate rituals over real work. You can’t
get a certification in it. Its just a reminder of the steps involved in making
software.
2) It requires small teams. Small teams make communication much easier and mitigate against many other dysfunctions such as the desire to be working on too much different stuff at one time.
I saw this great tweet the other day:
And I think its true, we need to focus on completing things properly before starting new things. We can help this by not having big backlogs, or setting targets for getting a certain number of things done in a given time.
3) Its simple.
I just wish I could do it…
PS: If you think you can improve my flow chart — PR me! https://github.com/RyanGough/method
