I happened on this older post when browsing John Goodpasture’s site. I found your criticisms measured and reasonable. Architecture, scaling, and communication beyond a small team all require additional weight and ceremony. I hope the discussions can be a little more civil than name calling. I haven’t figured out how to get the trackback working yet, but I discuss some of this at the process revolution http://billnichols.wordpress.com/2011/05/12/agile-weaknesses/

1. Since you are more a waterfall kind of person, I bet you have hard figures: how many projects fail when using agile vs how many projects fail when using waterfall methods?

2. In your ridiculous example my Scrum team is not allowed or not able to talk with the customers. Any idea where the hell your waterfall team is going to get their requirements from? And if you magically find a piece of paper where all the customer requirements are written down, how the hell are you going to make sure that your team making no errors in mis-interpreting all the requirements?

3a. Yes, it is better for a team if they can talk with each other.
3b. If some smart-ass manager came up with the most brilliant idea to out-source parts of the project leading to scattered teams, Agile doesn’t fail harder then waterfall. Conference meetings allow you to keep in touch with each other, and in the end, the scattered Scrum team still communicates better then a scattered waterfall team.

4. Typical Scrum teams exist of 7-9 members. Make more teams, and you don’t have a problem. Make huge Scrum teams, and you run into the same problems as huge waterfall teams, so again, ridiculous statement.

5. Agile is not weak on architectural planning. Waterfall is weak on architectural planning. Write a “waterfall-like” architecture up-front and you’ll get the most useless, over-flexible, unnecessary complex architectures. Do some research about the biggest wastes in software development, and see how much software is written under the flag of “future extensions” and “future requirements”, which will be maintained by your dear developers… for no reason at all. How about referring to that as waste.

6. Clearly you never have been in an Agile or Scrum team. How about we do sprint planning meetings, which is all about descoping. There we decide what we REALLY need to implement, and shift-delete all nice2haves. Further more, of course it’s possible to have a project plan in Agile. And what totally kicks is the following: our plans do make the deadlines.

7. Completely bogus again. Regardless of waterfall or Scrum, there is no such thing as first time right software. The good thing is, that using Scrum you only have to refactor small parts, where typical waterfall projects can start over from scratch.

8. Ok, this was almost getting close. Sure we can’t give an estimation of a complete project being ready. What we can give, is a deadline for the most important features needed first. What a typical waterfall project can do, is give a deadline when the complete project is ready and fail to make the date. Djeeze, I wonder what the “senior-management” prefers.

9. We don’t have a Hero culture, your waterfall teams have that problem. Further more, we don’t waste 70% of our valuable time writing documents nobody will ever read.

10. Nope, we don’t run into that problem. But then, our project only counts 250 men.

I never read so much BS in article. What a shame you never are properly introduced with Scrum.

e.g. My general point is while Agile is easy to appreciate it is initially difficult to implement in a new teams unlike other methodologies. Agile confuses people at the top and cause those in the middle to struggle to implement.

But I think the biggest issue with the article is that it is filled with false comparisons. Suppose you move into a fourth-floor office in a building with no elevator. Compared to people in a building with an elevator, you’ll be out of breath more often. Since we know that being out of breath is a sign of being out of shape, the elevator riders could naively think that they are more fit than you. But really, your stairs are just exposing a problem that remains hidden for the other group.

That’s exactly the sort of false comparison that happens here. For example, all software projects can benefit from interaction with users, and feedback from business stakeholders. Agile projects, though, take better advantage of available contact, and make it obvious where the project could benefit. If you force an Agile team into a vacuum and give them a giant spec, they’ll still deliver, and do it better than the waterfall team. But they’ll be correctly cranky about it.

The same sort of mistake is made with the points on refactoring, estimation, and collocation. Both Agile and Waterfall teams struggle with the right architecture, with good estimates, and with optimal collaboration. But only Agile methods makes those problems obvious early, so they can be fixed quickly.

It’s disappointing to me that an article like this could be written in 2010; apparently Agile knowledge still lags well behind Agile popularity.

I see Agile as a set of guidelines, we don’t have to use all of them (it’s not always possible, for instance when business have no time to work with development team) to be agile. The one which we use we have have to adopt and tweak to make sure that the team is as efficient as possible.