I think you may be getting too attached to the article’s title. James didn’t say that all teams using Scrum/agile/whatever will fail, he didn’t even say that most of them will. He said “a lot”.

If you can choose a good team to work with you are lucky but in most cases people don’t have an option.

I’m not, of course, advocating that we should ignore the problem. My entire point is very simple: he’s taking something that is clearly a case of 80/20 reality and turning into an argument about an entire age (so to speak) of development. At least to me, the point is kind of moot. Of course if you take a process designed for one thing and try to pass as another thing you’ll have problems. Of course, it’s a problem that most people adopting Scrum/Agile will have. Of course there’ll be people selling it as a silver bullet. Been there, done that. See Peopleware and The Mythical Man-Month for similar arguments.

About the non-obviousness of the need of engineering processes, I don’t think you can use a mailing list to demonstrate the point. I’d say that would only prove Sturgeon’s law. At the point I’m currently in my career, I’ve been avoiding to work with people that don’t get this and that’s it. Not all people will have this opportunity, but you can always find ways to exercise you engineering muscles. Leave the non-obviousness to the failing companies.

Anyway, I’m not a professional software developer and I’m not a consultant so it’s very probable I’m just not getting James’ point. I can live with that.

I don’t think you got the spirit of his post. It’s a rant and this means that it will contain bombastic yet vague claims that are mostly useful to catch your attention.

Also I don’t think James blames Scrum, he blames people that use Scrum and forget that software engineering is about… err… engineering. An iterative and collaborative process is great but lack of engineering won’t get you anywhere.

As a professional software developer and a consultant I can tell you that it is not obvious that you can’t take engineering practices out of development processes. Five minutes in any mailing list will show you so.

And I still don’t get your argument about “a fact that applies to any market and methodology and philosophy”. He didn’t say it is a problem that happens only with agile processes, he said it is a problem agile processes have! If this is a problem other fields or techniques have too that does not mean we should ignore the problem with the agile community/field/methodology/whatever.

What I was trying to say is that James has taken a fact that applies to any market and methodology and philosophy and passing it as a specific problem with Agile and Scrum. It simply doesn’t make sense. Even if Scrum were to blame for problems in the Agile model, James arguments wouldn’t apply.

And don’t forget those teams doing Daily Meetings as pure Status Meetings.

Here’s a story… Project Manager command and one talk. And that one talks to the project manager, not to the team. And no knowledge sharing, just strait talk. And the PM asks percentage done of the task and also recommends one extra hour from the person, to help task completion.

It’s crazy. Like James said.

“But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.”

One I was watching a presentation and a person in the audience asked to the presenter… “Hey, isn’t this bad, I mean, people doing all this mess in their companies and teams?”

And the presenter said:

“Well, it’s very bad, but thanks to them I have a job. :-)”

I’m not sure I understood your comment. The fact that you need your car fixed doesn’t mean you can’t get a better car to start with -or use your car properly.

@Colin

I think Uncle Bob didn’t get the point. As James commented the text is a rant.

@Lachlan

Good questions.

1) I don’t think James’ text is about specific practices from any methodology. I see his warning as “you can’t remove engineering practices from an agile project”, what is something I totally agree with.

2) Don’t try to make of agile software development a generic project management toolset. We already have one and it doesn’t work well for software development.