Tamer Zeyad SadiqAssistant Cost Manager| Turner & TownsendRiyadh, Ar Riyad, Saudi Arabia
As the event yesterday for Agility organization, the disadvantages for agile approach are documentation the poor quality!!!! what is reason?? Saving Changes...
You mean that on agile developments the system documentation is often poor? Yes that is often the case in my experience, developers tend to leave it, perhaps using the reason that the development is not finished yet/ they are too busy with the next sprint & will do it later. Saving Changes...
Saurabh TyagiProject Manager| Pratham SoftwareJaipur, Rajasthan, India
The general misconception is that in Agile no documentation is required or try to create a very basic documentation (Mostly in the form of Jira stories). Due to this mindset, the quality of documentation already goes down. Moreover, developers, they are already no interested in creating the documentation so they try to avoid doing it or do it in a very bad taste. Developers try to remove the technical debt rather than doing the documentation. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Unfortunatelly this conference contributes to general confusion. Let me write here objetive reasons just in case you want to make additional research. 1-suppose you are talking about software products. Then, while Agile is not about software only, the best source of information and the guide to follow is the Manifesto for Agile Software Development. As its name stated is for software, an implementation of Agile in that domain. If you read it, you will find the statement "That is, while there is value in the items on the right, we value the items on the left more." at the end of the statements. One of the statements said: "Working software over comprehensive documentation". But because a lot of reasons lot of people said "no documentation". That is wrong. On the other side, Agile is based on quality so if quality is not achieved then you are not working into Agile environments. BUT definition of quality is about the organization, not about Agile, and to do that you need to define "client". For example, if you take one of the most cited methods which is DSDM you will find documentation deliverables on it. 2-Agile is a practices that you can use into any environment (like Lean for example) if and only if the environment is ready for that (enteprise architecture) AND if and only if the product characteristics shown that it fits. For example, few people know that knowledge management is key for Agile. One of the impacts of team dynamics is knowledge is inside "the head" of the team members. So, if you will create a product that will evolve in the future and it is not for scratch, taking into account that into Agile environments written documentation is the minimun amount, do you will take the risk? what happend if you work into an environment where high people rotation is in place? Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Unfortunately, there are those that will misinterpret the Agile Manifesto. Saving Changes...
Tamer Zeyad SadiqAssistant Cost Manager| Turner & TownsendRiyadh, Ar Riyad, Saudi Arabia
I think something missed right??? Saving Changes...
Poor quality documentation which doesn't meet minimal needs is a sign of doing agile not being agile. If anything, as we shift from project to product or value-stream centric models, the need for high quality, maintainable documentation for those products or value-streams is more important as it will be consumed over multiple releases.
The key is minimal sufficiency and not getting hung up on the how...
Kiron Saving Changes...
Sunil ChitreFounder | CEO| Blue Sun Development LLCRound Rock, Tx, United States
Low quality or insufficient documentation isn't limited to agile. I've had to completely scrap other people's code for lack of documentation telling me what they were trying to do in it. It was simply quicker to start over from nothing than spend time figuring out what they'd done and fix it.
When I learned to write code, it had to be done by hand. Documenting what you were doing was easy to include and grade for. Now that many tools allow you to select a construct and drop it in place, documenting why you chose that construct over other options is often left out.
The same thing happens at other levels of documentation. If it's not a formal deliverable that the team is measured against, the amount and quality of documentation will depend on the whims of individuals. Saving Changes...
