It is widely known in the software development industry that Agile values “working software” over “extensive documentation.” This leads to the common misconception that Agile does not believe in documentation. It is true that documentation in Agile does not always mean typing code descriptions or lengthy time consuming information that may come in handy sometime in the future. However, Agile does not condone little or no documentation—Agile encourages the “right” documentation.
Agile encourages “just enough” documentation as is required for the project. This documentation can be in the form of flip-chart notes or writing on a white board. Then, one could take pictures of the documentation with a digital device and store it for reference. Agile does not believe in documentation just because someone feels that each and every detail of the project has to be captured in writing in order to retain knowledge for the future. The aim of Agile is to be better and faster. “Just enough” documentation helps to save time and cost during the project development process.
However, for projects that demand descriptive documentation, such as projects related to armed forces and defense, Agile practitioners are required to document necessary data and information. When documentation adds value to the customer, it is accepted and worked on using the Agile methodology. Unacademy App for PC
Another misconception surrounding the Agile method is that this approach involves no planning. On the contrary, Agile involves planning as much as any traditional approach does. However, its take on planning is different from other methodologies; Agile focuses on getting started with familiar architecture and requirements rather than spending crucial time on setting up a long-term plan. The Agile manifesto emphasizes “responding to change” over “following a plan.” Owing to this value, an Agile team can adjust and accommodate changes in the project plan much better than other traditional teams. Along with planning, Agile also accepts its limitations in a blustery situation.
Agile planning is not a rigid structure but a progressive one. Laying out a strict plan before the initiation of a project may look organized, but is most likely to become a hindrance in the long run because plans tend to change as the team begins to learn from feedback and iterations. Agile planning is based on the project features and is systematically organized into iterations with a time frame of one to two weeks. Agile believes in implementing a short plan efficiently rather than wasting efforts on preparing an elaborate plan that may not be successful in the end.
All too often the nay Sayers ignore the “over” in the manifesto and replace it with instead. How wrong, the point in this article where it says “Agile encourages the ‘right’ documentation” can be used for all the points in the manifesto. It doesn’t say “instead of” it says “over”. Incorporate the intelligent use of tools not the diligent use of them.
David,Hope you are well. I agree that for Agile to be successful, it reriequs that the Developers are put directly in touch with the Users. I am not certain that Technical Authors are always the best go-betweens or even coordinators it depends of course of their abilities. A Technical Author will benefit from understand the users perspective and ensure that the perspective is reflected in materials prepared. For the software to meet requirements, a person is required that drills down into the true needs so that the software is developed to actually meet the true needs rather than developed to meet the perception of the needs. Agile introduces a considerable risk that the software that is developed is designed’ by the users. Users are not designers of software they are able to describe the problems they have, but not necessarily design the solution that best addresses these problems.