Is Scrum Evil?

Question

At the last CITCON Europe we had a great session on the topic "Is Scrum Evil?" Reading James Shore's blog post on "The Decline and Fall of Agile" brought this session back to mind.

These are serious doubts being raised by people deep deep into agile. For people on the outside the judgements can be even more harsh, as in this blog post "The Agile Disease".

What is your current view of Scrum and/or Agile and its current influence on software development?

(This isn't about what agile meant 5+ years ago, this is about its influence today. So it isn't so much Scrum vs. RUP but more is Scrum the new RUP?)

Answer 1

I don't know much about Scrum, and definitely not enough to tell if it's "evil" (I allso think "evil" is overused and misleading term anyway, but that's probably another discussion). But as with allmost anything, I think fanatism and fundamentalism is bad even though the intentin may have been good.

I know a little about XP and other "agile" methodologies, and there's a lot of good ideas in many of these, but I've always regarded it as suggestions not a formula to follow methodically. My main concern about all development model, is that require skilled, intelligent and self-motivated developers to work perfectly, and since many of the best ideas really is common sense for intelligent people, it seems a bit overhyped. You can even get cowboy style, "code and fix" to work if all the developers are good and disciplined. But any methodology will fail with a mostly incompetent crew, and blindly following some "manifesto" without common sense will not make it better.

The oposite of "agile", heavy bureacratic systems, may actually work better for mediocre developers, than a system that recuire self-driven participants; though it may drive away many creative and intelligent developers. The main problem is finding good people, not so much how to run the project...

BTW: I personally like the agile ideas, and use the ones that suits me, but I allso see that it would not work if I and my co-workers weren't good at managing ourself.

Answer 2

Some observations about negative aspects of SCRUM in my experience:

A misleading sense of detail.

There are so many specific process details in SCRUM that it's very easy to get mired in process while losing track of the high level goals (and then it becomes just a cargo cult process). Also, SCRUM generates a lot of artifacts, it's easy to mislead yourself into believing that this plethora of data gives you more visibility into the development process than it actually does, and the sheer quantity of data probably discourages people from asking whether they're getting the right information.

Over application.

SCRUM is often mis-applied as a general purpose fix-all process for every situation when, like any process, it only has usefulness within a fairly narrow set of circumstances.

Pressure for short-sightedness

SCRUM encourages short-term work on concretely defined tasks. Less well-defined work (especially work that doesn't have artifacts already existing in the system) like research or strategic planning is at a disadvantage in getting developer time.

Misplaced credit

SCRUM is one of the most visible development processes, it helps that it has a catchy name/brand, which means that often a successful project that uses SCRUM is more likely to result in SCRUM receiving a good amount of the credit than a successful project that employs a development process which is less noticeable and doesn't have such a catchy name.

FUD

Those most trained in SCRUM seem to be the most blindly defensive of it, going so far as to try to scare people into thinking that even the slightest deviation from the one-true-SCRUM-way leads to the dreaded "waterfall" process. Given the enormous multiplicity of different development processes, many of them with plenty of good qualities all their own, this tendency is pretty ridiculous. Also, there is this idea that the only way to be agile is to use SCRUM(TM) or TDD(TM) or XP(TM), when in reality there are many ways to achieve development agility without any of these specific methodologies. The truth is that no development process is a silver bullet, and the best development processes are really only incrementally better than the 2nd, 3rd, etc. best processes.

Answer 3

Interestingly, I recently listened to a conference speech from Tim Bray who's topic was "how to survive the credit crunch" (more or less) and his view was that agile is not only far from dead, it will be the only player for a while and it's waterfall which is dead.

His reasoning on this seems perfectly clear and obvious to me that where money is tight no business nor client is going to commit itself to huge upfront costs where failure is near terminal for a project when they have the option of small iterative costs where failure just mandates another iteration. You can argue all day about relative risk, but I know from experience that only agile provides the client with a feeling of security and control.

Certainly the sweep of "agile" makes it a loaded gun in the hands of a bad management team, and I have less time for things like XP and hour-long scrum sessions, but that's not a failing of the principle of agile development. Certainly SGS's post makes a good point that more rigid methodologies can be better suited to mediocre developers and factory-line software, but I'm sure that doesn't apply to the OP ;)

In the small-ish breadth of my career thus far I can say that every single waterfall project has ultimately become a botched agile one when the foo hits the bar, and only the agile ones (fully embraced) have had the support of all parties at the end of the project. Is it bias to favour the thing which has always done better?

Summary: I strongly disagree. Agile is the future.

Answer 4

I don't think scrum is "evil", but I do think that any pure implementation of a methodology will have its shortcomings. The goal is to take one or more methodologies that are attractive to a team and apply those features to your process. In my experience any pure approach becomes too rigid and will not satisfy the needs of all stakeholders in a project.

Answer 5

I think it can be useful in certain circumstances. But I think that SCRUM, or any other methodology, must be an instrument for us, and not the other way.

When it starts to create more problems than it solves, it's not worth the time.

If after using it, you are improving your time estimations, your team is more conscious about their targets, you detect delays sooner and are able to react to them, then scrum is serving you.

But when you find you have to spend lots of time just trying to make the puzzle assigning tasks to developers and making it fit in your iteration time, when you have to make a time estimation about a task that is not even well defined, when you have to make how much will it cost to implement a technology you don't even know yet, etc... just so management can have a pretty iteration chart, then it's a complete waste of time (and of course money). In fact it's a source of frustration, it makes developing harder, and management close to impossible because it cannot generate good data, no matter how hard you try.

Answer 6

Personally.. I think Scrum is easier to accept for the old-scientific-style of management than any of the agile methods out there. Scrums that should take 30 mins or less morph into long-running status updates of yore... (now daily and standing!)

As with most things agile.. I think the fault lies in

• not understanding the principles behind the methodology... leading to following listed practices on blind faith.. and helplessness when they don't work
• not adapting the methodology to the problem at hand. Standardizing is just so tempting.. chasing Templatized solutions for all problems. 'this is our new process. Everyone shall comply.'
• not adjusting to ground realities and retrospectives.
• Fixing symptoms rather than the disease.

Good people will make good software (even without agile, SCRUM, or whatever)... mediocre and lower people will churn out similar software even with their home-grown variety of agile. However people doing agile as it was meant to.. will result in better products

Update: JFYI..Just found a catalog of 'Scrum smells' on Mike Cohn's site. Short , nicely written and from the man himself.

Answer 7

As F. Brooks said, "there is no silver bullet", and Agile processes do not depart from this and cannot be applied for all kinds of project.

Moreover, Scrum, and agile processes, are more than a set of practices, there are underlying principles. If applying the practices can be easy, without those principles, it can lead to a disaster. And by inspecting and adapting the process continuously, the process will ends fitting one's needs.

It's obvious Scrum is suffering from projects [mis-]using Scrum and failing. It's unavoidable. But we saw Waterfall projects failing, we saw RAD projects failing, we saw RUP projects failing, what does it teach us about those processes ?

I personally think Agile processes have reached their maturity level, not sure this means they started to decline.

Answer 8

Interestingly the is scrum evil link doesn't give a particularly negative viewpoint in my opinion:

e.g. “Scrum is evil because…” when it fails, all the people involved think that all of agile is no good (it poisons the well for agile)

The point in that article seems to be that getting focussed on 'the process' rather than the goal is the problem. This applies to any methodology.

Similarly the Decline and Fall post is saying that blindly applying a process (particluarly SCRUM with its management focus) without backing it up with good engineering practices doesn't make sense.

I think the point is that you cannot take any process at face value and attempt to copy it blindly (or worse just the parts that you want to) and expect it to work. Every situation is different and without clear thought, good practices and talented, motivated people you are going to struggle.

Answer 9

Scrum is NOT a replacement for actual software engineering management. Somebody still has to make sure that the code is good, the project is progressing according to business needs, and the user experience is coming out well. Scrum makes all the unimportant stuff seem more important. It's all about peering at the trees and totally missing the forest.

The other thing I hate about scrum is that scrums tend to be extremely painful meetings in which interesting things are not discussed -- and the team gets so sick of each other that interesting things stop being discussed anywhere. It makes sure that innovation and fun get stamped out of the development process. It leads to low-quality, boring software.

I lived with "Agile" and "Scrum" for a year, and have seen many other companies use it. I'm convinced "we do agile" simply means "we don't have any instincts or wisdom about software development, so we just hear each other talk for 30 minutes a day and pretend that we are good at this."

Ok, yes, in my experience, scrum is evil. "Agile" is a great marketing word, but a terrible methodology.

Answer 10

I don't think its evil but I think it can be misapplied. Two examples come to mind. If your working on a mature product that has run smoothly using waterfall for the last 10 years I don’t think the benefits of Scrum are worth the retraining all the developers in a new process. I also think Scrum will fail if the proper team or training isn’t in place. If you have a lot of experienced developers on a team then Scrum will work if management buys into it. Trying to run a new project with interns and Scrum methodology didn’t work very well though since there was not a lot of training and the interns weren’t experienced enough to stay on task with out constant supervision.

Answer 11

Scrum is a reaction to degenerate Waterfall. In its original form, Waterfall had feedback to the prior step at each level. When that is missing, it gets very easy to fail badly. This has been amply demonstrated by the huge fraction of giant IT projects which fail utterly with no benefit to those who pay the fees.

In my view, Scrum introduces two really valuable differences from undegenerate Waterfall, testing both ideas and partial results with stakeholders like customers and end users, possibly via use of surrogates, and very short cycles which take advantage of seeing where you are going by facing reality early and often. That is, collaborate with your customers, and watch what you're doing and how well it is working.

Still, if you crave most effective paths to glory, you actually need to start with the organization's highest quality-goals in measurable form and use that understanding for choosing the next step (sprint if you like) by estimating its effect on progress toward those goals. Tom Gilb (see Gilb.com) gives detailed methods in his "Competitive Engineering" handbook though his much older "Principles of Software Engineering Management" is much easier to read through from cover to cover.

His admonition to select and adapt from among the flood of great ideas he offers is a great strength of his approach.

Answer 12

Scrum is not evil, but people can be. If a team don't understand the principles [[1]] beyond the practices, they will fail and of course, they will blame Scrum, or any other Agile Methodology they think they are using.

People may want to use Scrum, they can read a lot and may understand how to use, but the problem is that most people don't understand why they are using. They just think that using Scrum will make them look better and customers will love.

The road to Agile is full of pain and hard work. It's not easy at all. It's a cultural change, a new mindset if you prefer[[2]].

That's why I think that before learning Scrum, extreme programming or any other Agile Methodology people should read about Lean Thinking[[3]]. The principles we need to understand are available in there.

References:

[[1]] - http://www.agilemanifesto.org/principles.html

[[2]] - http://www.mrbool.com/articles/viewcomp.asp?comp=7480

[[3]] - http://www.lean.org/

Answer 13

Thou shalt render Software and Religion asunder - Code Complete.

Pick and mix practices based on what suits your current project. Don't make a methodology into a religion. Remember we are all from different worlds. Steve McConnell has been advising this for years - his book Rapid Development gives a catalogue of practices with guidance on whether they suit your project. The book won a Jolt Award in 1997, and Steve McConnell is hugely respected, so it's time it caught on.

Eric Sink put it like this (tongue in cheek):

I'll admit that the body of wisdom literature produced by the Agile movement has some very good stuff in it. But Agile is no different from any other major religion like Christianity or Buddhism. You can learn some great principles and practices there, but formally becoming a member is a decision that should not be made lightly.

To be fair Alistair Cockburn's Agile Software Development also advices pragmatic selection of practices, but IMHO some of the other agile gurus are too evangelical. Others put it more strongly.

Answer 14

First, accept SCRUM for what it is, a set of management practices to facilitate collaboration between development and the business partner. As a set of management practices, they are typically easy to implement and follow and provide nearly almost immediate benefit to a project.

SCRUM is not a set of engineering practices. A team without a set of engineering practices is a team that will not be able to sustain delivery. SCRUM by itself is not sufficient. An agile team only practicing SCRUM will begin to lose its velocity. Without proper engineering practices, e.g., XP, the code base become more difficult to change the longer the project runs.

So, SCRUM by itself will provide a short term benefit and may create a false sense of value. SCRUM without engineering practices such as XP, will soon become a project in need of rescue. SCRUM is an excellent set of management practices in need of an excellent set of engineering practices that must be practiced in parallel.