RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
Agile is and was never intending for anti or no documentation.
it all depends how it is implemented and practiced in a Development environment. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
This is not a myths. This is because people do not read the Manifesto for Agile Software Development. The Manifesto clear state: "That is, while there is value in the items on
the right, we value the items on the left more". Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Some seem to twist 'over' to mean instead of. Saving Changes...
Any time there is a transformational movement, myths and misconceptions will flourish.
With documentation, it should always be minimally sufficient to meet regulatory (or other compliance) requirements, to create shared understanding between stakeholders and to support ongoing evolution of the product or solution.
Other myths:
- Agile is just about delivering faster
- Agile doesn't require design or architecture
- Agile means no more titles - everyone does everything
- We have to be colocated
- It's only for software development
- Teams (and organizations) can self-organize without support
- You need to deliver value from sprint 1
- Agile = sprints
- If you are doing daily standups, you are being agile
Thanks to all of you for sharing your points. Well noted down it. Saving Changes...
Al TaylorI.T. Contractor| IndependentWaterloo, Ontario, Canada
savvy PMs and teams have been creating the right amount of documentation for many years....unfortunately I have seen teams forced to create a document where the only value is satisfying an audit requirement
Yesterday at Agile Montreal we had a similar discussion.
The myth or bad application is that "Agile doesn't need to be managed it self manage"
Vincent
...
1 reply by SHADAV MOHAMMAD ANSARI
Jan 11, 2019 12:28 AM
SHADAV MOHAMMAD ANSARI
...
Hi Vincent- Thanks for sharing your view.
Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
For me Agile is about getting the stakeholders together as often as possible and reaching a face to face agreement on what document is to be produced, Who will produce it , how will it be reviewed and who needs a document and whether that document is needed on this particular project. There has to be a clear discussion and clarification on why a document is needed OR why it is not justifiable to produce a particular document and this must be agreed with the Team and stakeholders.
lay it out clearly as a task on the Kanban Board with a person responsible. It sets up clear accountability and no one in the project team can challenge about lack of awareness and significance of or agreement on that particular document
There are some documents like User Requirements, System Support Plans, Solution Architecture documents, Project management plans which are non negotiable. You can absolutely be flexible in the format and presentation but everyone must know that these are to be produced and where they exist and they make sense to whichever team that will need to use them.
if the auditors require evidence that a Business Process or software affects people's lives or could pose a litigation threat and the organisation may get periodically audited for it, such documentation absolutely must be produced without exceptions, regardless of whether you are running an Agile or Waterfall project BUT with the agreed level and complexity of information needed.
Contrast this approach to a disjointed model where a BA produces a word document with 150 requirements and then asks 15 reviewers to give their comments and the document keeps travelling endlessly through reviews and after finalization of the document, you find that some requirements are no longer relevant!! That's what they mean when they say "Working software over comprehensive documentation". Produce what will absolutely impact the day to day function of the application in terms of design, requirements , architecture, testing and document it and don't waste time over documenting those bits that will never be used.
savvy PMs and teams have been creating the right amount of documentation for many years....unfortunately I have seen teams forced to create a document where the only value is satisfying an audit requirement
I think somebody should come up with a way to breed a very large shrimp. That way, you could ride him, then, after you camped at night, you could eat him. How about it, science?
