Skip to content

Why I Beat Up Agile Methodologies

There are so many other software development methodologies out there that are just such a pain of process that one might wonder why I pretty much only write about the deficiencies in agile methodologies. Aren’t there easier targets out there? The answer is yes, but then again, easy targets are no fun. I really do like agile. Frankly, agile methodologies agree with me more than any other “process” that I’ve encountered. The flexibility, the collaboration, the speed of development. All these things (and more) are cool and I like them. So why, you may ask, am I always saying how much I don’t like agile methodologies. Again, and again and again. The answer is simple. Agile methods have great potential. They could be the next great thing. But we have to nurture them and they have to mature before they will be more widely accepted. And what better way to grow and learn about what we are doing then questioning what we are doing. That is what I am doing. Don’t get me wrong, I really am not a fan of some of the specific techniques, but by questioning them, I’m not only pointing out where they could be deficient, but I am trying to emphasize that by definition we are allowed to adapt agile methods to our own purposes. Some would disagree with me on this last point and I suspect they are also the people who would disagree with me on my feelings about stand-up meetings, 100% pair programming and bullpen type work environments. But that is beside the point. Disagree with me all you like. The fact that I am even allowed to question how we are developing software and can be agile enough to change a technique when it is not working for me or the project I am working on is a great step forward. My goal for agile methodologies is to free ourselves from being slaves to process. Whether that will happen or not is another question, but agile methods have more potential for this than any methodology or group of methodologies I’ve encountered.

Without questions, we cannot have answers and without answers, nothing will ever change. So I question agile methods in the hopes of making it better in my own little way. I don’t even bother with the other crap that is out there.