Just for the record documentation has its place, especially early on during say version 1 of an application, but it’s no substitute for software that actually works and thus fulfills the requirements. The reason I say documentation has its place in the early stages of an application, is that is when it is most accurate, and over time it becomes less and less accurate as developers make changes and the documentation remains the same. I can hear the screaming now; the developers are supposed to update the documentation as they make changes aren’t they? Sure, in an ideal world, but you and I know this just isn’t true.
The authors of the Agile Manifesto were just trying to emphasize that the most important thing when developing software is that it actually works. I have led many projects that required extensive documentation, only to find out later that no one was reading it or could even find it. In fact most of the time it was the high level architectural diagrams that had the most value and could stand the test of time, at least time that is measured in months. Being agile in software development means being able to frequently release new functionality; with the idea being that delays in releasing working software only postpone value being delivered. If you wait for extensive documentation to be developed before releasing software you will always be late to the party.
I often see the conflict come into play when an organization has three separate entities involved in the creation and release of software. These organizations are Q/A Testing, Developers, and Business Analysts, with the most conflict occurring between the Testing organization and the Developers. The more deep rooted problem is a lack of agility and lack of automated testing tools. You probably encountered some of this in the form of “You need to finish all the functionality before promoting it to the Q/A or Staging environment, so I don’t have to retest everything”. Let’s be real with each other, a lot of organizations think they are doing agile development, when all they are doing is wrapping Scrum around their waterfall processes.
This is all about what is most valuable, and the point of software development is to create working software that meets the needs of the organization.
I would love to hear your feedback.
AgileMethods.blog 