I think the reason agile is weird is because there are two kinds of agile. There is the agile as a method, where we adopt a series of industry best practices and employ those tools to get things done. Whether a team adopts scrum, kanban, etc., the important thing is that they have a process, employ the process, and things get done. You do these things, tick off these boxes, and you get thing done.
Then there’s agile as a process (AaaP). You don’t adopt any specific methodologies, though you might, but instead you treat your methodology as something that’s constantly being developed and refined. AaaP is saying that you’ll never have a finished approach or methodology, but instead will constantly re-evaluate it. The idea is that there is no off-the-shelf approach that’s going to be perfectly usable with your team, and your specific set of problems, so you need to construct your own methodology by applying agile principles and delivering constant feedback.
The “agile as a process” version sometimes works. It’s based on the idea that if you put skilled people in a room and get out of their way, they’ll get things done. I think the challenge is one of scaling- that sort of “figure out and adjust” methodology works well for small teams, but for large teams or teams with high turnover or teams that have to balance priorities across 100 different software products, and thus are rarely dedicated to one product’s worth of tasks, it tends to blow up.
If “AaaP” sometimes works, “agile as a method” (AaaM) almost always doesn’t. My experience is that 90% of attempts to adopt scrum (what big companies love) devolve into “scrumfall” or just perversely take a waterfall and add more meetings to it. I think the article tends to touch upon a lot of those. I’ve done some Agile coaching, I’ve given them advice, they’ve paid me lots of money for the advice, and then they’ve gone off and ignored it because they want to continue letting their PMs micromanage teams.
I don’t think there’s any right answer, but I think there are a lot of wrong answers when it comes to methodology. What I appreciate about AaaP is that it promotes self-organization and works best with skilled teams- meaning that you’re 2/3s of the way around the 3-factor theory of human motivation: autonomy and mastery. Chuck purpose on top, and I think that’s a team that will succeed.
The best case for ‘scrumfall’ at big dumb corps is they actually assign product/project owners and task them with creating and prioritizing a back log. That goes a long, long way toward resolving the “not me” “not my responsibility” shit show so many of them have. Worst case is, as you said, don’t do anything different but have a stand up, and more meetings.
Agile in most large corps is “weird” because they’ve taken “Individuals and interactions over processes and tools” and paid a bunch of consultants to turn it into “process uber alles” specifically in the aim of making people meaningless and interchangeable.
I’d disagree that any process is better than no process. I think Agile has “won” because for all of the “Scrumfall” pitfalls, it does offer genuine - incremental, slower than we’d like, but genuine - improvements over what came before.
I think the reason agile is weird is because there are two kinds of agile. There is the agile as a method, where we adopt a series of industry best practices and employ those tools to get things done. Whether a team adopts scrum, kanban, etc., the important thing is that they have a process, employ the process, and things get done. You do these things, tick off these boxes, and you get thing done.
Then there’s agile as a process (AaaP). You don’t adopt any specific methodologies, though you might, but instead you treat your methodology as something that’s constantly being developed and refined. AaaP is saying that you’ll never have a finished approach or methodology, but instead will constantly re-evaluate it. The idea is that there is no off-the-shelf approach that’s going to be perfectly usable with your team, and your specific set of problems, so you need to construct your own methodology by applying agile principles and delivering constant feedback.
The “agile as a process” version sometimes works. It’s based on the idea that if you put skilled people in a room and get out of their way, they’ll get things done. I think the challenge is one of scaling- that sort of “figure out and adjust” methodology works well for small teams, but for large teams or teams with high turnover or teams that have to balance priorities across 100 different software products, and thus are rarely dedicated to one product’s worth of tasks, it tends to blow up.
If “AaaP” sometimes works, “agile as a method” (AaaM) almost always doesn’t. My experience is that 90% of attempts to adopt scrum (what big companies love) devolve into “scrumfall” or just perversely take a waterfall and add more meetings to it. I think the article tends to touch upon a lot of those. I’ve done some Agile coaching, I’ve given them advice, they’ve paid me lots of money for the advice, and then they’ve gone off and ignored it because they want to continue letting their PMs micromanage teams.
I don’t think there’s any right answer, but I think there are a lot of wrong answers when it comes to methodology. What I appreciate about AaaP is that it promotes self-organization and works best with skilled teams- meaning that you’re 2/3s of the way around the 3-factor theory of human motivation: autonomy and mastery. Chuck purpose on top, and I think that’s a team that will succeed.
The best case for ‘scrumfall’ at big dumb corps is they actually assign product/project owners and task them with creating and prioritizing a back log. That goes a long, long way toward resolving the “not me” “not my responsibility” shit show so many of them have. Worst case is, as you said, don’t do anything different but have a stand up, and more meetings.
Agile in most large corps is “weird” because they’ve taken “Individuals and interactions over processes and tools” and paid a bunch of consultants to turn it into “process uber alles” specifically in the aim of making people meaningless and interchangeable.
I’d disagree that any process is better than no process. I think Agile has “won” because for all of the “Scrumfall” pitfalls, it does offer genuine - incremental, slower than we’d like, but genuine - improvements over what came before.