Agile Methodologies

When people read my blogs and articles, or take my courses, some respond with "We don't need to do that. We're an agile shop.". When I hear that I immediately think, "Do you know what an agile methodology is?". Look up "agile" in the dictionary. All it means is "Quick to respond".


I am a proponent of agile methodologies for software development. The classic waterfall model, as taught in a number of Project Management courses, does not work and never has. It assumes you can complete every step in a project completely and never have to revisit it. Nonsense! That's not how we build stuff. We build as a series of iterations with each iteration building upon the last.


I remember a few Project Managers from my past trying to impose a waterfall methodology on a project, and it never worked. Caused nothing but problems and unhappy customers.


The problem is that many people, especially developers, believe that an agile methodology allows them to do whatever they want, get feedback from the client and then change it, over and over and over again, until it is what the client wants. Throw Project Management out the window. Talk about the long way to get to somewhere, rework after rework after rework.


Why then do some instructors continue to teach the waterfall method as if it's the only way to develop software? Because that's what they were taught and they can't get beyond that.

I continue to teach about the Requirements, Design, Development, Testing and Deployment Phases of a project, not because they need to be done in that order completely, but because they all require different skills, tools and techniques to accomplish and have different best practices. It's just a good way to divide up the material. Don't assume it means that you must do the 5 phases in order with no overlap. Just doesn't work.