I think it's a management strategy to keep developers under constant pressure with feet close to the fire. There is always something to do, report, meet, discuss in a formalized way, damn everything else. Even if you didn't do much this week you still have to report something. Do this two weeks in a row and your already on the naughty list. Doesn't matter if your tenure was stellar so far.
In my experience the only ones loving it are of course management, and highly vocal and relatively young developers who seek refuge in arbitrary procedures and fake structure.
As others said, it's also a way to try to treat developers as assembly line workers, which can be replaced at any time. Doctors or lawyers have no such thing. Nor any other engineering profession that I know of.
Software development is a realm of snake oil salesman, move fast - break things philosophy, and no unions. So no wonder we get this kind of crap shoved down our throats. And just like with any mass of people, a certain percentage will absolutely adore it.
And I think it's a good way to communicate how the team works.
If you want new features, you talk to the product owner and they'll add it to the backlog - at a priority they choose.
You don't barge into the team's area demanding "just this one quick fix", there's a clear process to get your stuff in the queue.
If your workplace already works like this, you don't need agile, scrum or any other method with a fancy name. Keep doing what you're doing.
Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.
> Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.
How does it do that? If the sales guy sold feature X to a client you're going to have to build it -- Scrum be damned. Some process is going to get in the way of making money? I don't think so.
That's why it only works properly when there is FULL buy-in from the C-level down.
EVERYONE in the company must acknowledge that there is a clear process on how to get new features implemented and randomly barging into the team space demanding features is not it.
But I don't need Scrum to get buy in of non-shitty processes from the C-level down. I have that already without Scrum. Clearly people are doing Scrum that is awful. So it's neither a necessary nor sufficient property of Scrum itself.
I agree that not having management/sales directly involved in low-level development planning is a good. But that's not Scrum.
> As others said, it's also a way to try to treat developers as assembly line workers
Yes, a constant reminder that, even if you are highly paid cog in the machine, you are still a cog that can be replaced at any moment.
Because, you know, real decisions about what the product have to be made by a businessy dude, while developers are relegated to playing with their ci/cd and expensive toys. I guess what pisses me off the most is the patronizing attitude. All these methodologies scream: 'I don't trust you, so I will flood you with process where I can micromanage you'.
In my experience the only ones loving it are of course management, and highly vocal and relatively young developers who seek refuge in arbitrary procedures and fake structure.
As others said, it's also a way to try to treat developers as assembly line workers, which can be replaced at any time. Doctors or lawyers have no such thing. Nor any other engineering profession that I know of.
Software development is a realm of snake oil salesman, move fast - break things philosophy, and no unions. So no wonder we get this kind of crap shoved down our throats. And just like with any mass of people, a certain percentage will absolutely adore it.