Programming

It’s more about poor planning vs good planning. Of course a project with good planning is more likely to deliver in time.

It’s just to that poor planners tend to use “agile” as an excuse for their poor planning.

Right off the bat i read

One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation."

You need clearly defined requirements to write a good user story. Documentation comes after.

However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. "We don't need a test team because we're Agile" is a cost-saving abdication of responsibility.

Precisely, once once have i worked in a company where agile was properly implemented and, yes, user stories were well documented and discussed before being developed. All others are just waterfall in disguise, or Fragile™.

However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. "We don't need a test team because we're Agile" is a cost-saving abdication of responsibility.

In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates. ®

Random trademark symbol. What's the registered trademark here? The dot? "advocates"?

Agile went through the mgmt human centipede and now it's an unrecognizable broken system built on conflated ideas. I bet a good number of those projects are 'agilefall' anyways.

I've literally never actually seen a self proclaimed "agile" company at all get agile right.

If your developers are on teams that are tied to and own specific projects, that's not agile.

If you involve the clients in the scrum meeting, that's not agile.

If your devs aren't often opening PRs on a variety of different projects all over the place, you very likely aren't agile.

If your devs can't open up a PR in git as the way to perform devops, you aren't agile.

Instead you have most of the time devs rotting away on the sane project forever and everyone on "teams" siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because "they worked on it so they knpw how it works"

Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.

Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.

Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.

A really helpful metric, to be honest, of agile "health" at your company is monitor how many distinct repos devs are opening PRs into per year on average.

A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.