In conversation with our head of audit, I was explaining how our agile methodology is actually a lot more rigorous than old-school project management. We are also less formal. The two are hard to distinguish at first. Let me give a couple of examples.
We are more rigorous. If we start to move our timeboxes around, our whole paradigm falls apart. If we unexpectedly discover that a feature is going to take too long to test, we push it to the next iteration instead of moving the iteration end date out. If we don’t do this, we need to re-write the release plan, re-estimate tasks, re-do resource plans and (where I work at least) replan priorities for other projects, as well as generating the same set of documentation for these other projects. This is all waste work: work that does not bring us closer to client-valued features deployed and working in production. It’s also typically the thin end of the wedge: pretty soon our teams spend more time on documentation that on getting value-adding software working flawlessly in production.
We are less formal because all documents that we use are supportive not directive. I don’t demand people use a certain Excel template for a release plan. Thinking about certain attributes for each feature and for each iteration add value in our experience, and in teams that are starting up I strongly recommend (and yes, even enforce) this. But I don’t really care how our teams record this information. I have been down the path of only checking that everyone is using the same Word template or Excel sheet and mistaking that for real value — and I won’t be going down that path again.