Bad Agile Management Burns Scrum Teams

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.

Ms. Glaze | Flame | Flickr

Ms. Glaze | Flame | Flickr

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:

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?

Question: Have you been a part of a poor agile transformation? What went wrong? How could things have gone better? You can leave a comment by clicking here.

Please note: I reserve the right to delete comments that are offensive or off-topic.

  • Ryan, I have been through two agile transformations. The first one lacked executive support and didn’t last too long. After some changes in executives and a plan to better engage the executive team the process began to pick up steam. It sounds like Giles issue is more of one of misunderstanding. Excellent work!

  • Ryan, you’ve really gotten to the root of the issue with so many teams. Scrum is about transparency. Part of its job is to point out problems with a giant spotlight. Scrum itself doesn’t fix what is already broken, it’s not a magic pill we swallow. It’s the company, leaders, and teams responsibility to each do their part.

    • Great points here. I’m working on a post that looks at the impact/effect of transparency. The spotlight is double edged. Thanks for reading.

  • I read it and had the same impression. Any system imposed on a dysfunctional environment by bad management will be a disaster. One thing I like about Kanban is that it starts with where you are, but even that rule is often overlooked by managers trying to sneak in changes or model “optimal” processes. However, I worked in a pretty healthy environment that was happier and able to do even better work after the introduction of Scrum. Some healthy and intelligent teams may stumble upon processes that bring the same results, but for the less creative or less experimental folks out there, approaches like Scrum and Kanban can be very valuable.

    • Scrum is a great way to get new teams started on the agile path. I’ve seen in some cases where they move from scrum to kanban and enjoy great success. Context is everything. Part of the fun is figuring out which framework/methodology will be successful in your environment.