“Agile” still considered harmful

This comment was posted on an earlier item entitled "Agile" considered harmful. I thought it was interesting enough to deserve a little more visibility than it would have as a comment, so I’m highlighting it in a separate post, along with my reply.

START

Anoymous Coward permalink
I think the problem with the people considering agile harmful are the ones working in organizations requiring some guarantees – something quite common in business setups.

LOL, as if there are some "organizations" that don’t need projects to be successful.

Sorry, I can’t agree with your article. Every time I’ve worked with the product of an agile development effort in the field, it’s been a cobbled together, non-orthogonal disaster.

Here’s a “user story” fo you… I’M A field engineer AND I WANT gee, a matching delete function to go with this new upload function after I just sent this 1.2GB ISO file up to the system.

Oops. Gee, how did that make it past the scrum?

Maybe because all the fields in the test cases in Rally are blank except for the “PASS” status line.

IMHO Agile is the development paradigm of the ADD generation. "Let’s get ~something~ out there quick and let the customer figure it out. Worst case, we can always ssh in & fix it in the database. Then we can not record the defect because we’re busy fighting 100 other different fires of the same ilk, each lovinging put out in their own hand-crafted way. No need to document defects…I already edited the code on the bus home from work. We’re good!"

Please, don’t tell me that "that team didn’t implement Agile correctly". In and of itself, IMHO agile encourages bad practices, the main one being, "it will never be perfect so don’t bother trying". You might as well try driving the speed limit on the highway.

Agile ~might~ be good fo developing rapid prototypes, not actual products that are "guaranteed" to work.

END

Hello, Roy.

You are not alone in your experiences and observations with “agile” projects and their typical results. I suspect your comment expresses a view shared by many.

Something I find interesting about your comment is that you think you disagree with what I wrote. That’s the sort of thing that makes me wish I had taken more psychology courses in school.

I’m not about to suggest “that team didn’t implement Agile correctly.” I will suggest, however, “that team didn’t implement software correctly.” Most teams don’t. Some believe “agile” will magically correct for that. It won’t. Neither will other sets of practices that many people (maybe you, too?) assume or believe believe “cause” good software to emerge.

Responsibility for quality falls on those who create the product. Responsibility for choosing appropriate tools and using them properly likewise falls on them. Same goes for a plumber, electrician, or surgeon. Can’t blame that faulty wrench forever. Sooner or later, you have to question the person’s skills. GIGO.

Regarding the observation that “agile” encourages bad practices, I will suggest that “agile” doesn’t include any magical protections against bad practices. The difference between “agile” and traditional methods is that “agile” never claimed it would do so. That one point may well be the single most revolutionary aspect of “agile” thinking: There are guidelines, but no guarantees. Other methodologies pretend they can guarantee good results. They can’t. They never could.

Many commercially-sold methodologies claim (or their salespeople claim) that if you follow them faithfully, the result will be good software. After decades of dismally poor results in the software field, people are so desperate to believe in magic that they buy. After a few failures, they buy another; hope springs eternal. Eventually they get around to trying “agile,” and their results are the same as always. Is that surprising? Is it hard to foresee? Is it logical to believe that merely by attaching a buzzword to the failures you’ve solved the problem?

One of the factors that makes “agile” difficult for the majority of teams is simply that it requires team members to know what sound software development means, and to be disciplined about applying that knowledge. “Agile” leaves teams free to choose with regard to those matters. Whose fault is it if a team doesn’t have the skills to choose wisely? Software development is a bit like life itself: What you get out of it is proportional to what you put into it.

A matching delete function to go with the upload function? Yeah, obviously. Empty test cases? Yeah, pretty stupid. What does that have to do with “agile” as such? Nothing. The reason I say “agile” may be considered harmful is that people take far too much comfort in the buzzword. It’s only a word. You still have to do the work. That’s why I won’t say that team didn’t do “agile,” I’ll just say they didn’t do the work.

I might add that if they blame a buzzword for poor results, then they’re going to do the same thing on their next project, regardless of methodology. They’ll go through their whole careers blaming methodologies, managers, companies, customers, colleagues, and anyone else who happens to be handy for their poor results. Anyone, that is, except the one common demoninator in all their adventures.

There’s a lot of badly-designed, badly-written software out in the world. Very, very little of it was developed using “agile” methods. If you’re looking for root causes, keep looking. I’m looking, too, and I’ve discovered I have to look far beyond “agile” to find them.

At the risk of sounding a bit unfriendly, I’ll point out that your choice of words indicates you do not understand the thing you are vilifying. You say that “agile” might be useful for building a prototype. Wrong. A prototype is a throw-away proof-of-concept artifact. “Agile” methods call for incremental delivery of the actual solution, not for prototyping. There are other methodologies that include prototyping. Also: Scrum != “agile”, Rally != “agile”, working alone on the bus != “agile”, jamming untested code into production != “agile”, ignoring opportunities for improvement because it will never be perfect != “agile”. If you’re going to criticize something, at least find out what it is first. Are you mixed up about other fundamentals, as well? My guess is you probably are. Your comments would be more compelling if you understood “agile” development. As it is, you sound as if you are just whining about bad software and looking for a scapegoat. Okay, congratulations, you’ve got a scapegoat. Now what? How can you use that to improve the art of software development?

Where you and I differ is that I do understand how “agile” works in detail. I have moved beyond it precisely because I understand the mechanisms and the effects of the various techniques and practices commonly associated with the word, “agile,” and I no longer find value in the word. I do find value in sound software development practices tailored to each situation. Some of those come from the “agile” school of thought. I’m not going to throw out the baby with the “agile” bathwater.