Why does Scrum never get blamed?

Hi P.Ross,

Because Scrum is just like a rule of sport. It is not prescriptive. The rule never fails, it is the people who is playing the game that fail. I love the game of soccer but it wouldn't be fair if I say the rule of soccer fails when my favorite team lost. Just like any game of sport, the success of the project using Scrum will depend on the strategy put in place. Scrum is intentionally designed to have many blank spot so organisations can put in their strategy within this framework. Scrum never fails, but Scrum also never succeeds. That is quite fair to me.

Hi Joshua,

When we talk about that the rules are never wrong. I don't think that entirely fair because you can't apply football rules when you are playing basketball although they are both considered a ball game. The same as you can't apply the Scrum rules to an organisation where they have waterfall rules.

And when we talk about prescriptive. Waterfall doesn't have much rules. It just say that we need to work in phases. So instead of 1team, you have all these specialised teams. So it's more that their strategy isn't working then saying that waterfall isn't working.

Pablo

Waterfall is very generic however scrum lets you employ your own strategy into it thus helping you work in different ways.

http://www.agiledistributed.com/

> How come when a waterfall project fails its because of waterfall and
> when a Scrum project fails its not because of Scrum?

Scrum projects do fail because of Scrum. One of the agile tenets is "Fail Early, Fail Fast". That's harder to do in waterfall projects, so waterfall has a poor reputation while Scrum has a rather better one.

Hi P.Ross,

I think you already mentioned it and I am not sure why you disagreeing with me. When an organisation wants to play Scrum they either play Scrum by the book or they don't. So if Scrum rules cannnot be applied then you cannot say that Scrum has failed them because they are not (or cannot) playing the game by the book. And when an organisation is not playing the game by the book it is either cheating or they are playing some other game that is not Scrum.

Waterfall itself as a methodology is quite a failure in itself. Spending exhaustive time in the beginning to get the requirement right and leaving testing at the end is quite a failure. Winston Royce already mentioned himself on his original paper that leaving testing at the end is not a good idea. But saying that, Waterfall is good when all of the requirements is very well understood. The problem is, I rarely find any project where the requirements is very well understood these days.

I have seen many Scrum projects fail and fell into pieces. But it is not because of Scrum, it is either because:
- the organisation is not playing the Scrum rule by the book
- business vision is not clear
- incapable team to execute the vision into realisation

Yes this can also happen in Waterfall projects, but Scrum just makes it more apparent and earlier. And when business can see these failures earlier they have succeed to get away from bigger failures.

I often see people blaming scrum: you never heard: "scrum is good but not working for us", "we tried it but our people need more directive" etc.. This all seems to blame scrum and then the solution most of the time is to go back to waterfall, v-modell or any other thing they have done before.

And to Pablo: YOu brought it to the point, applying football rules to a basketball game does not work, but if you do so, is it the fault of the football rules, that they do not fit to what you want?

I often see people blaming scrum: you never heard: "scrum is good but not working for us", "we tried it but our people need more directive" etc.. This all seems to blame scrum and then the solution most of the time is to go back to waterfall, v-modell or any other thing they have done before.

And to Pablo: YOu brought it to the point, applying football rules to a basketball game does not work, but if you do so, is it the fault of the football rules, that they do not fit to what you want?

I often see people blaming scrum: you never heard: "scrum is good but not working for us", "we tried it but our people need more directive" etc.. This all seems to blame scrum and then the solution most of the time is to go back to waterfall, v-modell or any other thing they have done before.

And to Pablo: YOu brought it to the point, applying football rules to a basketball game does not work, but if you do so, is it the fault of the football rules, that they do not fit to what you want?

And, i'm really sorry for triple posting but it see,s that my connection made problems.

Br,

Hi Philipp,

What I see and hear a lot is the following:

- Apply Scrum within an organisation. [apply football rules to basketball]
- If it doesn't work, change the organisation. [if the football rules doesn't work with basketball, change basketball]

"Scrum is good but not working for us" indicates that the company is not working with Scrum. Perhaps there's a reason? Perhaps there is another Agile or non Agile methodology that works better. Why is it that we truly believe that Scrum is the answer to everything and if it isn't, well, than there is something wrong with your organisation process.

Infact the Austratralians modified the rules of football and created Australian rules football, and they love it. :-)

@P. Ross I can understand your point of view. When waterfall fails, it's because of waterfall. When Scrum fails, it's not because of Scrum. When discussing scrum vs. traditional project management this type of argumentation is very common, which is unfortunate.
You can succeed or fail regardless or project methodology, but to me it's obvious that a waterfall approach is often doomed to fail, even if it's executed properly. It's just not well suited for software development in a rapidly changing world.

@P. Ross: I think there started a problem by getting popular with agile methods or specially scrum. It's sold as silver bullet even as it is not intended to be one. And there is a hardline I really agree with: if you want to do scrum, then do scrum and not partly scrum or something else. This is often misinterpreted with "do scrum everything else is wrong". But the message is "do scrum everything else is not scrum"

A good post on this is http://agile.dzone.com/articles/apologetic-agile-development?mz=123873-…

Looking through the scrum guide, how often do we find any comparison to waterfall, classic projects, non-agile way?

One of major good thing about Scrum is that you get the results within 1/2/3/4 weeks and who says sprint doesn't fails or team doesn't have Not Done work in their sprint. The difference is that everyone get to know about the failure early and get engaged to make it successful for next sprint. If you have failed in 1-2 sprint out of 50 sprints people still forget about it but if your project fails after 6 months or a year then everyone will remember it :-)

I have a unique perspective, since I use Scrum for Infrastructure. It's a "Failure is not an option" environment, so it's evaluation, retrospective, and do it again. "Witch hunts" on who or what to blame have existed since before the Great Pyramids, and that type of retrospective only serves one purpose, to save your neck (literally for the Great Pyramids' builders). If you work in an environment where the word BLAME is tossed around frequently, find a different place to work; Scrum is a team concept, and the team succeeds or fails, not a single individual, and definitely not a framework/methodology.