[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".