423
Study finds 268% higher failure rates for Agile software projects
(www.theregister.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Jun 2024
423 points (94.5% liked)
Programming
16687 readers
210 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
Requirements ≠ Documentation. Any project with CLEAR requirements will be most likely to succeed. The hard part is the clear requirements, and not deviating.
The inability of management to conduct productive meetings is even more well-known than their inability to conduct a decent hiring process, and we all know how broken that is.
The study's sample and methodology are not linked so I suspect a huge bias, in that the projects succeeding sans-Agile have been successful without it long term, while the Agile projects chose Agile because they were unsuccessful pre-adoption — you don't adopt agile if you were already successfully delivering projects.
Yes, and daily standups are not a requirement of agile in any way. The whole point is people over process and adapting to change rather than following a plan so if standups aren't working you should stop doing them rather than following a rigid process!
💯
Agile is not an excuse to be stupid. If you need documentation then fucking do documentation. If your stand-ups suck then either change them or stop. You don't just do things "because agile".
Most companies I've worked for "do agile because agile" and everything revolves around agile. And you can't change this because they decide and they have the money.
I was going to say most of this, too. I’m a big adherent of BDD, which works well with agile. It clarifies what everyone is working on without getting weighed down in unnecessary minutiae or “documentation for paperworks sake”… it lives and evolves with the project, and at the end becomes both testing criteria and the measurement of success.
No gold likes on lemmy? So sad...
You can use whatever images you wish:-)
They are part of documentation, but not all documentation.
The difference is in exact wording Agile: the software shall properly authticate a user within our active directory.
Documention : user authentication will be provided by functions ”valisate username” as described in section 14,7 subsection 4, ”validate password” as described in section 16.2 and validate the correct pasword as described in section 23.4.Proper authication to the correct use group shall comply with the requirements in document 654689 section 64.7 subsection 17
Yes there is a difference and one is better....
So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.
The details on HOW to authenticate are ALSO documentation. Not all documentation describes functionality.
If you need documentation then do documentation. Nothing in the agile methodology tells you not to.
I think you're confusing documentation with specification.
Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.
Requirements drive the project. Documentation always lag behind the project.
If you write it down it is documentation. When requirements are written down, they are documented! Requirements are not the same thing as specifications either, but both are documentation!
You are saying that only technical documentation counts as documentation.
I think you're not getting the point.
It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.
https://en.wikipedia.org/wiki/System_requirements_specification