Is Scrum Evil?

Question

At the last CITCON in Europe, we had a great session on “ Is Scrum Evil? ” Reading James Shore's message on “ The Decline and Fall of Agile ” brought this session back to mind.

These are serious doubts that people are deeply immersed in agility. For people on the side, judgments can be even harsher, as in this Agile Disease blog.

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

(It's not about what agile meant 5+ years ago, it's about its influence today. So it's not so much Scrum versus RUP, but more Scrum a new RUP?)

Answer 1

Personally. I think Scrum is easier to adopt for an old-scientific management style than any of the flexible methods. Scrums, which should take 30 minutes or less, turn into long-term state updates ... (now every day and all the time!)

Like most nimble things. I think the error lies in

• does not understand the principles of methodology ... leading to the following methods of blind faith and helplessness when they do not work.
• Do not adapt the methodology to the problem. Standardization is so tempting. Chasing Templatized solutions for all problems. “This is our new process. Everyone must comply.
• does not adapt to the realities of the earth and retrospectives.
• Fixative symptoms, not disease.

Good people will make good software (even without agility, SCRUM or something else) ... mediocre and lower people will release similar software even with their home-made variety of agility. However, people who make it flexible, as it was intended to ..., will lead to better products.

Update : JFYI .. Just found the ' Scrum Smells ' directory on Mike Cohn's website . Short, beautifully written and from the person himself.

Answer 2

I don’t know much about Scrum, and it’s definitely not enough to say whether it is “evil” (I also think that “evil” is too misusing and misleading anyway, but this is probably another discussion). But, as with almost anything, I think bigotry and fundamentalism are bad, even when the intention is good.

I am a little versed in XP and other “flexible” methodologies, and many of them have a lot of good ideas, but I always saw this as suggestions, not a formula, to follow methodically. My main concern for all development models is that they require skilled, smart, and self-motivated developers to work great, and since many of the best ideas are really sensible for intelligent people, this seems a bit overkill. You can even get a 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 “manifest” without common sense will not improve it.

The opposite of "mobility"; heavy bureaucratic systems; in fact, it can work better for mediocre developers than a system that requires the participation of the participants themselves; although it can hijack many creative and smart developers. The main problem is finding good people, not how to start a project ...

By the way: I personally like nimble ideas, and I use the ones that suit me, but I also see that it won’t work if my colleagues and I don’t manage well.

Answer 3

Some observations about the negative aspects of SCRUM in my experience:

A deceptive sense of detail.

SCRUM has so many special process details that it’s very easy to get stuck in the process, losing high-level goals (and then it becomes just a process of cult cargo). In addition, SCRUM generates a lot of artifacts, it is easy to mislead yourself, believing that this data set gives you more visibility during the development process than it actually is, and the huge amount of data probably prevents people from asking if they get the right information. .

For the application.

SCRUM is often mistakenly used as a general-purpose process for all situations where, like any process, it has only utility in rather narrow conditions.

Pressure for myopia

SCRUM encourages short-term work on specific tasks. Less clearly defined work (especially work that does not have artifacts already existing in the system), such as research or strategic planning, is at a disadvantage for getting the developer's time.

Invalid Credit

SCRUM is one of the most visible development processes, it helps to have a catchy name / brand, which means that often a successful project using SCRUM is likely to result in SCRUM getting a good loan amount than a successful project that uses the development process , which is less noticeable and does not have such a memorable name.

Fud

Those who train most in SCRUM are apparently the most blind defense against this, so much so that they try to scare people, thinking that even the slightest deviation from the true SCRUM path leads to a terrible "waterfall", to process. Given the huge multiplicity of various development processes, many of them with a lot of good qualities in themselves, this trend is quite ridiculous. In addition, there is an idea that the only way to be flexible is to use SCRUM (TM) or TDD (TM) or XP (TM), when in fact there are many ways to achieve development flexibility without any of these specific methodologies. The truth is that not one development process is a silver bullet, and the best development processes are really only gradually better than the best 2nd, 3rd, etc. The best processes.

Answer 4

Scrum is NOT a replacement for the actual management of engineering programs. Someone else needs to make sure the code is good, the project progresses according to the needs of the business, and the user experience comes out well. Scrum makes all non-essential things more important. It's all about how to look at the trees and completely abyss in the forest.

Another thing I hate about a fight is that fights are usually extremely painful meetings in which interesting things are not discussed - and the team is so sick of each other that interesting things are no longer discussed anywhere. This ensures that innovation and pleasure are imprinted during the development process. This leads to low-quality, boring software.

I lived with Agile and Scrum for a year, and saw how many other companies use it. I’m convinced that “we are agile” simply means “we don’t have the instincts or wisdom to develop software, so we just hear each other for 30 minutes a day and pretend that we are good at it.”

Well, yes, in my experience, the fight is evil. "Agile" is a great marketing word, but a terrible methodology.

Answer 5

It is interesting that I recently listened to a speech at a conference by Tim Bray, the theme of which was "how to survive in a credit crunch" (more or less), and his opinion was that flexibility is not only far from dead, it will be the only player time and it is a waterfall that is dead.

His reasoning for this seems to me completely clear and obvious that where there is no money, neither business nor the client will incur enormous upfront costs, when the failure approaches the terminal for the project, when they have the possibility of small iterative costs, the refusal is simply requires another iteration. You can argue all day about relative risk, but from experience I know that only flexibility gives the client a sense of security and control.

Of course, the agile sweep makes it a loaded weapon in the hands of a poor management team, and I have less time for things like XP and hourly scrum sessions, but this is not a failure of the flexible development principle. Of course, the SGS post gives a good idea that tougher methodologies may be better suited to mediocre developers and factory software, but I'm sure this doesn't apply to OP;)

In the small breadth of my career so far I can say that every project of the waterfall ultimately became unsuccessful moving when foo gets into the bar, and only the agile (fully covered) received support from all sides at the end of the project. Is this a prejudice in favor of what has always done better?

Summary: I strongly disagree. Agile is the future.

Answer 6

First, accept SCRUM for what it is, a set of management methods to facilitate collaboration between developers and a business partner. As a set of managerial practices, they are usually easy to implement and follow and provide almost immediate benefits to the project.

SCRUM is not a set of engineering practices. A team without a set of engineering practices is a team that cannot support delivery. SCRUM alone is not enough. The agile team practicing SCRUM will begin to lose speed. Without good engineering practice, such as XP, the code base becomes more difficult to change the longer the project takes.

Thus, SCRUM itself will provide short-term benefits and may create a false sense of value. SCRUM without engineering practices like XP will soon become a rescue project. SCRUM is an excellent set of control methods requiring an excellent set of technical solutions that must be executed in parallel.

Answer 7

As F. Brooks said, “there is no silver bullet,” and flexible processes do not depart from this and cannot be applied to all types of projects.

Moreover, Scrum and agile processes are more than a set of practices, there are fundamental principles. If practicing can be easy without these principles, it can lead to disaster. And checks and adapts the process continuously , the process will be completed in accordance with the needs.

Obviously, Scrum suffers from [mis-] projects using Scrum and failing. It's unavoidable. But we saw that Waterfall projects failed, we saw unsuccessful RAD projects, we saw unsuccessful RUP projects, what does he teach us about these processes?

I personally believe that Agile processes have reached their level of maturity, but are not sure if this means that they have begun to decline.

Answer 8

You will provide software and religion without borders - Code Complete .

Choose and mix practice based on what suits your current project. Do not introduce methodology into religion. Remember that we are all from different worlds . Steve McConnell has been advising this for many years - his book Rapid Development provides a catalog of practices with guidance on whether they are appropriate for your project. The book won the Jolt Award in 1997, and Steve McConnell was extremely respected , so this is the time he caught.

Eric Sink put it like this (tongue on the cheek):

I admit that there are very good things in the literature of wisdom created by the Agile movement. But Agile is no different from other major religions such as Christianity or Buddhism. You can learn about some great principles and practices, but formally becoming a member is a decision that should not be made lightly.

To be fair, Alistair Cockburn Agile Software Development also advises pragmatic selection of practices, but IMHO some of the other flexible gurus are too gospel. Others have expressed it more strongly .

Answer 9

I think this may be useful in certain circumstances. But I think that SCRUM or any other methodology should be a tool for us, and not another way.

When he begins to create more problems than he solves, it is not worth the time.

If after use you improve your time estimates, your team is more aware of your goals, you will find delays earlier and be able to respond to them, then the fight serves you.

But when you find that you need to spend a lot of time just trying to make the puzzle a task for developers and make it suitable during an iteration, when you need to make a time estimate about a task that is not yet defined, when you need to do how much the implementation will cost technology that you don’t even know about, etc. .... so that management can have a rather iterative diagram, then this is a complete waste of time (and, of course, money), in fact, it is a source of frustration, it makes development harder to manage It is almost impossible, because it cannot generate good data, no matter how hard you try.

Answer 10

Interestingly, being a cruel evil link does not give a particularly negative point of view in my opinion:

eg. "Scrum is evil because ..." when he fails, all the people involved think that all the moving ones are not good (he poisons the well for the flexible)

The point in this article seems to be that the problem is focused on the "process", not the goal. This applies to any methodology.

Likewise, a Decline and Fall post says that blindly applying a process (especially SCRUM with its focus of control) without the support of its good engineering practices makes no sense.

I think the point is that you cannot take any process at face value and try to copy it blindly (or, worse, the parts you want) and expect it to work. Each situation is different without a clear thought, good practice and talented, motivated people with whom you are going to fight.

Answer 11

Scrum is a reaction to a degenerate waterfall. In its original form, Waterfall had feedback from the previous step at each level. When this is not enough, it becomes very easy to fail. This is convincingly evidenced by the huge share of gigantic IT projects that do not fully benefit those who pay fees.

In my opinion, Scrum presents two really important differences from an unidentified waterfall, testing both ideas and partial results with interested parties such as customers and end users, possibly using surrogates and very short cycles that use what you see when faced with reality early and often. That is, collaborate with your customers and see what you do and how well it works.

However, if you crave the most effective paths to fame, you really need to start with the highest quality goals of the organization in a measurable way and use this understanding to choose the next step (sprint if you want), evaluating its impact on progress towards these goals. Tom Gilb (see Gilb.com) provides detailed methods in his Competitive Engineering manual, although his much older Software Management Principles are much easier to read from screen to cover.

His exhortation to choose and adapt from the stream of great ideas that he offers is the great strength of his approach.

Answer 12

Scrum is not evil, but people can be. If the team does not understand the principles [ 1 ] outside of practice, they will fail and, of course, they will blame Scrum or any other Agile methods that they think they use.

People may want to use Scrum, they can read a lot and they can figure out how to use it, but the problem is that most people don’t understand why they use it. 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 is not easy. These are cultural changes, new thinking, if you prefer [ 2 ].

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

Literature:

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

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

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

Answer 13

I don’t think the fight is “evil”, but I think that any pure implementation of the methodology will have its drawbacks. The goal is to adopt one or more methodologies attractive to the team and apply these functions to your process. In my experience, any clean approach becomes too harsh and does not satisfy the needs of all interested parties in the project.

Answer 14

I do not think this is evil, but I think it may be misused. Two examples come to mind. If you are working on a mature product that has been running smoothly using a waterfall over the past 10 years, I do not think that the benefits of Scrum deserve the retraining of all developers in the new process. I also think Scrum will fail if the appropriate team or training is not in place. If you have many experienced developers on the team, then Scrum will work if management buys into it. Trying to launch a new project with the help of interns and the Scrum methodology did not work very well, since there was not much training, and the interns were experienced enough to remain on the task without constant supervision.

Answer 15

Yes ... SCRUM is evil. The only reason management cope with this in the first place is hype. This is a video with humor.

http://www.youtube.com/watch?v=nvks70PD0Rs

John