{
Adam Ard
}
Why Scrum is the Wrong Way to Build Software
A brief list of what Scrum gets wrong
- Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction.
- Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability.
- Scrum encourages “least amount of work possible” solutions — to conform to its strict predictability requirements.
- By dividing every task into small items that can theoretically be
completed by anyone on the team, Scrum discourages engineers from
taking pride in and/or ownership of their work. This lack of
ownership results in:
- Poor design
- Lack of motivation (“It isn’t my thing”, “It was broken when I start working on it”)
Scrum is highly intolerant to modification, and its proponents typically espouse an all or nothing attitude in its implementation. Its attitude of intolerance to self-examination is present in all of its practices. Only processes that operate internally to Scrum’s framework are open for modification — as for Scrum itself, it is seen as sacrosanct.
“Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” ---The official scrum guide
- Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more.
- Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective.
- Scrum discourages bug fixing, reduction of technical debt, and risk taking, all because of its narrow, exclusive focus on only doing items that Product Owners would interpret as valuable.
- Scrum is hypocritical
- Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on?
- Are they required to present burn down charts that show that they are on target to finish?
- Are they required to do bi-weekly sell-off meeting to justify their activities?
- Scrum makes many faulty assumptions
- It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding.
- It assumes that engineers are not to be trusted with directing their own work.
- It assumes that engineers cannot align themselves with the best interest of the organization, without tight supervision.
- It assumes that engineers cannot conduct a meeting effectively without a facilitator (Scrum Master)
- It assumes that you can plan every facet of a software task by merely talking about it in sprint planning/backlog grooming
- It assumes that all engineers work the same way.
- Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a team’s performance is represented (ie. Velocity)
- Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones.
Scrum is the opposite of many of the points set forth in the original agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan ---agile manifesto
- Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate.