Agile does not really works. It sometimes works, exceptionally, usually the more you try to do the by the book agile the worst it gets. Every single time they make agile reform, everything stats to suck and everything turns into ritualized micro management.
I'm all for criticizing agile etc if it doesn't work, but this is such a generic complaint.
What's "by the book" agile? Scrum? The things in the manifesto? Something that some rando Scrummaster said?
And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
It is generic, because it is the most common result of agile.
What's "by the book" agile? Scrum? The things in the manifesto?
Definitely scrum.
And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
Every single detail and aspect of your work is determined by someone or something else. You have zero individual autonomy, zero individual responsibility. And zero option to do something good or bad. "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.
Yeah, it is not one person telling you how to do things. It is that every aspect of work is decided by someone else or some committee. When you have one person telling you how to do things you at least can adjust to them and negotiate some space with them.
"Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.
See, this is already not "by the book" Scrum.
The team decides those things in a retrospective, and as long as they are releasing in a reasonable timely manner, it's alright.
If someone is being unreasonable and putting their foot down too much, then it's a management issue that doesn't have anything to do with Scrum. Either the person is a dictator, or they don't have authority and there's no management to put an end to it.
Scrum also doesn't work when the team is burning in a building on fire, but we don't blame Scrum for that.
I'm all for shitting on it, but those problems have been happening in companies for millenia. Scrum won't fix them, you gotta fix each separate problem by itself.
Three of the original signers of the Agile Manifesto are also the main people involved with creating XP[1][2][3].
The Agile Manifesto was just a bunch of people who were already doing XP, Scrum or some other lightweight process getting together and writing down the similarities between what they were doing. It's a blanket term invented to describe a variety of different processes, not an actual process.
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.
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.
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.
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.
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
Comments
Having clear requirements, good communications with key stakeholders and empower the enginees.
That sounds familiar... Oh ! That's where agile ideas come from! http://www.extremeprogramming.org/
That existed before agile.
Good on agile for restating what works and putting it in an fashionable, easy to understand framework, then.
But bad on agile for letting charlatans co-opt the term.
Agile does not really works. It sometimes works, exceptionally, usually the more you try to do the by the book agile the worst it gets. Every single time they make agile reform, everything stats to suck and everything turns into ritualized micro management.
I'm all for criticizing agile etc if it doesn't work, but this is such a generic complaint.
What's "by the book" agile? Scrum? The things in the manifesto? Something that some rando Scrummaster said?
And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
It is generic, because it is the most common result of agile.
Definitely scrum.
Every single detail and aspect of your work is determined by someone or something else. You have zero individual autonomy, zero individual responsibility. And zero option to do something good or bad. "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.
Yeah, it is not one person telling you how to do things. It is that every aspect of work is decided by someone else or some committee. When you have one person telling you how to do things you at least can adjust to them and negotiate some space with them.
See, this is already not "by the book" Scrum.
The team decides those things in a retrospective, and as long as they are releasing in a reasonable timely manner, it's alright.
If someone is being unreasonable and putting their foot down too much, then it's a management issue that doesn't have anything to do with Scrum. Either the person is a dictator, or they don't have authority and there's no management to put an end to it.
Scrum also doesn't work when the team is burning in a building on fire, but we don't blame Scrum for that.
I'm all for shitting on it, but those problems have been happening in companies for millenia. Scrum won't fix them, you gotta fix each separate problem by itself.
Three of the original signers of the Agile Manifesto are also the main people involved with creating XP[1][2][3].
The Agile Manifesto was just a bunch of people who were already doing XP, Scrum or some other lightweight process getting together and writing down the similarities between what they were doing. It's a blanket term invented to describe a variety of different processes, not an actual process.
[1] https://en.wikipedia.org/wiki/Kent_Beck
[2] https://en.wikipedia.org/wiki/Ward_Cunningham
[3] https://en.wikipedia.org/wiki/Ron_Jeffries
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.
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.
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.
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".
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.
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.
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