[matthewmacleod]

I actually started writing a point-by-point response to this, but it mutated into a thousand words and will be better suited to a blog post at some point in the future.

In the meantime, I think these are generally the same shallow straw-man arguments against Scrum that we all see pretty frequently. I guess the key points to bear in mind will be:

- Scrum is not a be-all and end-all solution to all product development. If you are developing a product for a slow-moving third-party (a case which is described as one of Scrum's downfalls) then you are correct – it's probably a bad choice. So is any agile approach. That is totally fine, and I'm not sure why it's seen as a bad thing.

- Scrum is not a fully-described, cast-iron set of rules that have to be followed. It's a framework which can (and must!) be changed to suit the team, and the product that's being developed. Concerns like wider-scale management and integration of multiple projects are so dependent on the functioning of an individual organisation that it would be ineffective to have a prescriptive set of rules. Your 'Agile Coach', product owners and management team generally have to deal with these issues in other ways.

- Scrum is (apparently, based on the objections in this article) implemented poorly in many places. For example, the 'seemingly endless series of meetings'? That's explicitly one of the things that Scrum does not encourage! Micromanagement is the same. Scope change during a sprint as well. That Scrum is poorly implemented is not a reasonable criticism of it, for me.

- It's okay to fail to meet targets when delivering software, and inevitable that it will happen. Scrum provides the tools to manage and recover from those failures, and to help ensure they are limited in scope. Those retrospectives, for example – it's totally valid to say 'We committed to feature <x>, and failed to deliver it because <unforeseen dependency y> prevented us from doing so'. The important thing is to understand what caused that failure, and how similar failures can be prevented in the future. That's a fantastically powerful tool to have.

Perhaps I'm just biased, because I've been working in excellently-managed agile teams that have been delivering software very effectively, and have seen how useful Scrum has been as a framework to manage the complexity of planning it.

[sheepmullet]

"Perhaps I'm just biased, because I've been working in excellently-managed agile teams that have been delivering software very effectively, and have seen how useful Scrum has been as a framework to manage the complexity of planning it."

I'm lucky enough to have been in the industry before agile and scrum were popular and back before the agile days I worked on excellently managed teams that delivered great software effectively. I've also seen a lot of agile projects crash and burn.

At it's core agile is a small set of guiding principles. Principals I'm sure most of us agree with. Yet it's hard to sell these principles to process heavy organisations. I've seen it fail time and time again despite the efforts of top consultants and coaches.

IMO, agiles real success has been in giving structure to cowboy driven teams. Teams that now actually write requirements down. You could never convince these "cowboys" to write an SRS... But a few user stories... That's more realistic.

[RalfR]

I value your opinion, even if I do not agree with it. The argument of "Scrum being poorly implemented" is brought again and again.

It's just another one of these go-to killer arguments.

If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?

Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire army of coaches and consultants, who make a ton of money from it.

I'd love if you'd continue the discussion over at Agile Overflow.

[matthewmacleod]

If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?

That's simple, I think:

- 1. Scrum is not actually 'mega simple'. Like I said, it's a framework of outline for building a system suited to your organisation. It still requires skilled people to implement it correctly. It's like expecting coders to become magically better because they start using a framework like Rails - it might describe good practices, but it won't fix bad developers!

- 2. Related to that, we see bad implementations because methodology will not fix a broken organisation. If you have bad developers or bad managers, you will not produce good products. If you hire a bad consultant, you will not produce a working Scrum implementation.

Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire army of coaches and consultants, who make a ton of money from it

It's obviously possible to have working and efficient implementations of Scrum; I'll testify that ours is excellent, and that's mostly down to hiring a very effective Agile Coach who knows how to implement it properly. And I know we're not the only ones - I expect you'll never hear about the good implementations full of happy developers!

The existence of an army of awful, unqualified consultants is a separate issue. You wouldn't expect to hire bad programmers and get good software; why would you expect good methodologies from bad consultants?

Hire someone skilled and let them implement a good system, and it will work.

[nl]

If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?

It fails because the problem it is trying to solve is so hard.

There is no silver-bullet methodology that make delivering quality software on time easy. Scrum does make a decent job of it though in an environment where Scrum can be implemented correctly. If it can't be implemented, then it won't work.

[gchpaco]

I'm reminded of the discussions about XP when it was newer. Lotta folks thought XP meant "cowboy away" and then got excited when it invariably didn't work--the original folks said "well, look, you're not doing the process; you can't blame it if you're not doing it".

Now the thing is this looks a hell of a lot like a No True Scotsman argument, especially if you're only glancing at it in passing. Yet, boundary setting is a legitimate thing to do; the XP folks had put up their lists of practices, etc. XP is/was very demanding, very tricky to do; it was an open question for a little while whether it was actually implementable by average organizations. The interface with the product owner was a particular issue, and is still in Scrum.

Put another way, when you say "Scrum says to do X" (say, very few meetings which should go quickly), and someone goes "Scrum sucks because we're constantly in meetings explaining why we're not getting any work done", and you say "You're not doing Scrum"... you have a point. Scrum teams are not supposed to be crunching; if the product has to ship by date X, then some of the features won't get in, and it's the product owner's _responsibility_ to say which ones those are. If the product owner says "I don't care these are all mission critical we can't discard any of them" then you're not doing Scrum, even if you have some highly educated boob with a certificate from some idiot making them a Scrum Ninja or whatever saying that you are!

Now, some of the practices are more important than others, and most of these frameworks say "you kinda need to be flexible, but try it first". So there are grey areas. And sometimes (as with XP) the existence proof that it is even possible to do the process is nontrivial. But kabuki-scrum (thank you, quanticle!) is a real thing.

[Morst]

From my experience most of the time companies/teams didn't even try to implement Scrum. Like having multiple product owners, skipping meetings, inventing new meetings, product owners not attending sprint planing or developers not caring about the process at all. The product owner is a single point of failure. If he does not work well it is hard for a team to deliver. In most teams I worked so far team members haven't even read the Scrum Guide nor gotten any training and didn't care.

[dreamfactory2]

It's a great point. To my mind scrum is actually a compromise aimed at selling agile into waterfall organisations. Apart from the flaws of scrum itself (too much process/waste), the two really big blockers are that it requires organisational change but is applied at a project level, and that good agile project leads/TPM's are way rarer than the good developers everybody says are impossible to find.

[einrealist]

We fail because it is about people interacting with each other. We fail, because we were trained to work on our own and competitively. We fail, because we have trouble to change our mindset and have even more trouble to change the minds of others. This is why we will fail at alternatives to Scrum, too.

Scrum requires a different mindset. It requires us to work in a team with honesty and jointly in order to be successful.

Teams fail at Scrum because they are dysfunctional from the start, don't share the same mindset about their work and processes or don't embrace the ideas Scrum provides.

[RalfR]

In other words: Scrum would work in Utopia?

[einrealist]

Do you live in Utopia? How do you get around in your environment?

Scrum is not a solution that you buy off the shelf and just run in your company. It is a framework to manage work and scope in a team. And it acknowledges that we are individuals who have to interact with each other in order to achieve success. Both aspects are equally important and have to be addressed. Scrum will not make problems disappear. But it helps you to manage them in a transparent and controlled fashion.

Don't you live in an environment with rules (law) and frameworks (social culture)? Is that environment perfect? I guess not. That's why we deal with imperfections on a daily basis. Like we have to do when living Scrum.

[Domenic_S]

> If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?

Just because something's simple doesn't mean it's got buy-in. It fails because implementers fail to get buy-in from people with power, and those people insist on keeping their pet processes in place.