Dr. Andrew Makar is an IT program manager and is the author of the Microsoft Project Made Easy series. For more project management advice, visit the website TacticalProjectManagement.com.
When I first started researching agile software development as an alternative to traditional waterfall development, I had a lot of preconceived notions. A lot of these thoughts were based on the agile myths I heard about over the years. Almost a decade ago, I recall laughing with a colleague when we asked a vendor about their COTS software development process and they responded with “extreme programming”. After seeing agile in action, I’m not laughing any more--and I realize learning the truth behind these myths helps identify alternative methods to successfully delivering software.
Agile Myth No. 1: Agile is just an excuse to code with no documentation
The truth is, agile software development incorporates the right amount of documentation that is required for the project. The agile team adopts the principle of developing documentation as late as possible and ensures there is an actual need for the documentation other than requiring it for a checklist. During a project’s iteration and release cycles, the project team will be allocated half an iteration or more to “release hardening” near the end of a release. The purpose of this release is to create the necessary documentation to support the project.
By adopting the concept of deferring documentation as late as possible, the project team can focus on creating a working