Last month Giles Bowkett wrote a scathing blog post about scrum called: Why Scrum Should Basically Just Die in a Fire. It’s a provocative article that shows how damaging bad agile and scrum can be to a team.
[featured-image single_newwindow=”false” alt=”Ms. Glaze | Flame | Flickr” title=”Ms. Glaze | Flame | Flickr”]Ms. Glaze | Flame | Flickr[/featured-image]
I’m not going to go point by point and argue with Mr. Bowkett about his experiences with scrum. They are his experiences, and they are truly awful. I have sympathy for him and those who have been burned by a botched agile transformation.
With waterfall, teams know what they are signing up for at the start of a project. They know there will be problems and that a death march is likely. They also know that the date set at the beginning of the project is likely wrong, but still they soldier on.
But with agile and scrum it’s supposed to be different. The agile manifesto is a developer play aimed at making the lives of engineers better. Scrum specifically puts the team in control of how they accomplish their work. Everything should be great.
But often, it isn’t.
Mr. Bowkett makes this point by calling out many common scrum anti-patterns that he has experienced:
- Planning poker not being played correctly
- Scrum master’s behaving badly
- Never ending standup meetings / daily scrums
- Velocity abuse – story point gaming
These are all valid – and unfortunately common – problems on scrum teams. However, the conclusion that he draws from the existence of these problems misses the mark.
In other words, in its best-case scenario, Scrum’s a dog-and-pony show. But that best-case scenario is rare. In the much more common case, Scrum covers up the inability to recruit (or even recognize) engineering talent, which is currently one of the most valuable things in the world, with a process for managing engineers as if they were cogs in a machine, all of equal value.
Rather than cover up individual inabilities, scrum exposes the bad practices of organizations. Quickly. Work becomes transparent, impediments become obvious, and old practices become extra painful.
The culprit here are manager who thought they were getting hyper-productivity for free. They want the benefits of scrum, without having to change.
Mr. Bowkett’s problem is with lousy managers, not scrum.
The agile community is also partially to blame. The tendency is to focus coaching and training on the scrum team. But it is the management team members that we need to be working on the most. Bad scrum cannot take root in an organization that embraces the scrum values from the top down.
Part of embracing the scrum values is accepting the twelve principles of agile from the agile manifesto, which Mr. Bowkett also railed against.
I don’t think highly of Scrum, but the problem here goes deeper. The Agile Manifesto is flawed too. Consider this core principle of Agile development: “business people and developers must work together.” Why are we supposed to think developers are not business people?
We’re not. The intent of this agile principle is the end the “us vs them” mentality between IT and “the business”. With Scrum, the expectation is that the product owner is co-located with the development team and available to answer questions about the product backlog items.
This isn’t a slight against the business acumen of developers. It’s a call for close collaboration between stakeholders and engineers. How else can the development team know if they are working on the most valuable features for the business?
[reminder]Have you been a part of a poor agile transformation? What went wrong? How could things have gone better?[/reminder]