Jason Yip has been one of my favorite bloggers for a long time. This morning I caught a post from Jason Yip called More
thinking about "Agile" vs "Waterfall." He echoed something that I've thought ever since I moved over from a Waterfall shop to Agile shops about five years ago.
Be careful about saying that Waterfall is more disciplined. The waterfall
model is simple and structured but the "discipline" is in following prescribed
steps as opposed to "discipline" in thinking. The second kind of discipline is
by far the more important.
Agile development, assuming that you're doing it competently, is far more disciplined in the small, day to day activities than we were in my old waterfall shop and all the waterfall shops that I've consulted in. In the waterfall, we had a lot of one time quality gate processes and intermediate documents to deliver, but very little useful guidance on how to perform the actual development work (requirements, development, testing). An Agile process, and I'm thinking about XP in specific here rather than the typical watered down Scrum, has a lot of impact on how you write code (Test Driven Development, simple design, YAGNI, pair programming, Continuous Integration), requirements (user stories, iteration planning, acceptance tests), and testing. I don't go to meetings very often, and I rarely produce documentation beyond Wiki pages, but my daily work is far more disciplined than it was in my previous life in a formal Waterfall project.
Waterfall discipline is the external discipline of intermediate deliverables and process ceremony. Agile discipline has to be internalized by the members of the team and realized through their behavior and daily activities. For better or worse, Agile has far more impact on the way you work than traditionalist waterfall processes.
The best of Agile is when you throw away process ceremony that adds little or no value, and concentrate really hard on the things that do add quality and productivity to your project. Of course there's no cookie cutter process plan to follow because "what adds value" is a bit different from project team to project team, but if it was easy we wouldn't make the big bucks.