Used to be a fan of agile and the wisdom of the crowd, but now I’m not so sure. If the team majority aren’t experienced then the experienced people make suggestions are voted down.
I’m fast becoming anti-agile now

Agile doesn't work in reality because neither management nor customers are agile. They misunderstand agile as throwing any planning out of the window and think that the resulting chaos will achieve their fixed price, fixed scope expectations.

The whole idea was that the scope is not fixed so that the customer may end up with only 80% of what he actually needs, but that is a lot better than 100% of what doesn't really fit his needs.

And even that doesn't cover the agile architecture rot and tech debt piling up because covering user stories as performance metrics invariably means duct taping some Frankenstein shit together.

@Fast-Nop at one time I would’ve disagreed with you, because looking back a few companies ago we were doing agile really well. Failing fast, somehow keeping on top the the tech debt and having a really good relationship with the business and realising between us that for example when we got 80% done we didn’t actually need the last 20% at all.
But everyone on the team was very experienced and they listened to each other.

Now, I think I agree with you. There’s mountains of tech debt and it’s because we are just doing one story after another without any consideration of how things fit together.
And lots of lesser experienced people thinking they’re industry experts. Lots of kicking the can down the road for the next set of developers to sort out.
Fuck all best practices going on because they’re “not needed”. Blah blah

@TrevorTheRat In my company, we come from the other extreme, software with process-heavy waterfall - with the usual risks of detecting issues late in the process.

I got the customers into half-agile. We discuss the requirements as drafts, and I implement a quick and dirty test software with only basic version control involved. That software is throw-away so that I don't care about architecture issues. No further processes required because it's "for test use only." Then they test that with real physics and stuff involved, but not to verify the software - just for validating their requirements.

Only then, we start with all formal processes. This ensures that the waterfall will run through smoothly, and I can make the real software with proper architecture considerations. I got management on both sides sold on this scouting approach via "getting the project risk under control."

@Fast-Nop that sounds like a good sensible approach to me.

If your team aren't experienced enough to make sensible decisions then it'll never go well, however you're working. Waterfall based development won't save you there.

the bigger the team the worse agile becomes. another issue is what you said, no one properly knows how it should be done or just have no idea how important the few formalities are (frequent meetings and such). agile shouldn't be about removing all formalities, it's meant to reduce them, and if you don't keep things going it turns into complete chaos

@Fast-Nop prototyping really helps with the late problems. there's a lot of different process types and people only know two at most. different things work in different situations, and it takes some insight to figure out what is better for the team