[midasz]

What if the requirements are super clear but they change? When do you find out and what happens then? I've personally never had a project where the requirements were 100% clear and stayed exactly the same. Even when writing a v2 of an existing project from the ground up things tended to be unclear and subject to change.

[nudgeee]

The point is to use what ever works best for your team, not blindly follow some process that may or may not necessarily work for you.

Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.

[lll-o-lll]

Sounds like you need a process that can be flexible, able to respond to change, some might say… agile ;-)

I kid, but I think the early proponents of Scrum and similar were trying to achieve a loose framework to do exactly what you’re talking about. The modern incarnations of these can be horrific, but the original intent was always to empower teams to make their own process. Ahh well.

Like so many good ideas (democracy, constitutions), you only really know how well they function once people are actively trying to subvert them. Scrum et.al. have failed in the face of corporatocracy. I honestly don’t know if decentralised structures (i.e. teams empowered to run themselves), can ever survive in large corporates. Which is a pity. Cities grow, but companies die. You have to jump off the dying colossus to find the new company that hasn’t yet succumbed.

[whstl]

The modern variations of Scrum and Agile exist to empower certain people to rule over teams without having to do much, if any, work.

The team is self-organizing but person X is the decision maker in the process.

There is an engineering manager, but they will get overruled by person X more often than not.

The framework is simple, but person X will add new rules.

Agile/Scrum says people must understand the domain, but person X is the only one talking to stakeholders since engineers are "not people persons".

[lll-o-lll]

> The modern variations of Scrum and Agile exist to empower certain people to rule over teams without having to do much, if any, work.

I don’t think that’s why they exist, but I do think the structure is not robust to a large number of dysfunctions. This one included.

[oneshtein]

> What if the requirements are super clear but they change?

You need to communicate with stakeholders then, to change requirements, explain mistakes, set new goals, and reprioritize tasks. Agile (SCRUM/Kanban/etc.) are designed with frequently changing requirements in mind. In SCRUM, this is done at sprint review/sprint planning stage. In Kanban, it's continuous process.

[saiya-jin]

Well then requirements were not 'super clear', they were simply incorrect and it doesn't matter in which way. A very bad start of any project, since beginning you are already putting out flames left and right