Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Theory P methodologies like XP and Scrum constantly recalibrate expectations, so if the result is dissapointing, you are left blaming the inelasticity of space-time. An alternate version of this story had the protagonists choosing a methodology for a risky project: Choosing Waterfall was defecting and choosing Agile was coöperating."

I'm sorry, but measured against the number of times I've heard the phrase "Doing Agile Wrong", this sound disingenuous.



I've heard "Doing Agile Wrong" too, however I think what the post is talking about is when the participants accuse each other of doing it wrong, which is different than when an outsider says an entire project was done wrong.

So for example, if I say "We tried Scrum, and it didn't work," and some evangelist tries to defend the project and says "You did it wrong," that is not the same as when I say, "We tried Scrum, our Team was fine, but the Product Owner did it wrong and that's why we failed."

I can't speak to what you've heard, but I certainly have heard a lot of the former, to the point where I reply to all such discussions with a pointer to the No True Scotsman fallacy:

"Agile works."

"No it doesn't, we tried it and failed."

"You did it wrong."

Compare and contrast to:

"Scotsmen are cheap bastards, Ne'er would you catch one standing a round."

"Hamish just bought me a dram of Lagavulin."

"Hamish may have Scots parents, but he lives in Toronto. No True Scotsman would stand a round."


So if I'm reading this right:

If a project that uses Agile fails, the participants have no incentive to blame each other.

If a project that uses Waterfall fails, the participants have an incentive to blame each other.

Because Waterfall in the failure case gives people an incentive to blame each other, it's a poorer methodology than Agile.

If I haven't confused your argument, then the weakness is that you have not shown that Agile is a methodology in which people have no incentive (or ability) to blame each other if the project fails.


My claim is that if a project that uses Agile fails, the participants still have an incentive in dysfunctional cultures to blame each other, it's just that the structure of Agile makes it harder to blame individuals. So I am not claiming that A is better than W or W is better than A at shipping software, I am claiming that W is better than A at blaming people for failures.

I might have confused the issue by trying to draw a distinction between blaming the process from the inside and from the outside. My claim is that it is much easier to blame a process if you aren't a participant in a failing process. For this reason, it is easier to evangelize a new process of any type as a consultant or as a new face than it is if you are an old hand who may be accused of having been a cause of previous failures.

I think this second point is true of any process.


Can you explain how the structure of Agile makes it harder to blame individuals?


Perhaps we could pick a methodology and then imagine a project that "fails." Given this scenario, the challenge would be to find a way to blame the participants for the failure.

What promises do developers and stakeholders make to each other in the methodology? How do you define "failure" and given that definition, how do you establish a causal relationship between an individual and the result?


Well, the great thing about scrum planning is that you know exactly how long it will take and who to hold accountable.

http://marcin.floryan.pl/blog/2011/06/nightmare-agile




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: