As I am sure you are well aware, companies have been purging themselves of what they now perceive to be niche roles not directly tied to the bottom line.
For the last years, I’ve seen a lot of criticism around Agile, but this is the first time somebody really understands Agile before criticising it. Awesome reflection.
as always, your view mirrors my work life so faithfully that it is moving. Looking at organizations from a sociological point of view is a novelty to me but it feels both refreshing and reassuring
FWIW, as one of the 17 people who doesn't agree on what iteration means, I think there's a lot of pragmatic truth here.
The manifesto we produced was idealistic (read "naive"). It assumed that an entire organization could somehow embrace its philosophy as we all kum ba yah'd our way towards *value*. When the inevitable impedance mismatch became apparent, half of the agile folks started selling solutions to management, and the rest pretended it didn't matter.
What followed was the inevitable degradation of the ideas and values of the manifesto. To me, that's a tragedy, because I still believe after 25 years that the original four values are meaningful.
Many of the advocates of "Agile" (which is not a noun...) claim that it is still valid, and that people are just doing it incorrectly. And, indeed, in the article you mention things such as "build, measure, build", which is common, but which is not what an agile team should be doing.
But I increasingly feel that those advocates are missing the point. The real question is "is it possible to follow the values of the manifesto in the real world?". And the answer is clearly "not very often."
My most watched talk on youtube is Agile is Dead, from 2015 (https://www.youtube.com/watch?v=a-BOSpxYJ9M). There I argue that we may as well abandon the word "Agile." But I also suggest that doesn't require us to abandon the values, too.
Since then, I've been pondering what that actually means; how is it possible to honor the manifesto's values while working in a decidedly Taylorist world?
I'm coming to the conclusion that individuals and teams can still greatly benefit from agility, but only when applied locally and pragmatically. My current belief is that this manifests as a drive for simplicity in a world that tries to make everything more complex.
The article got me thinking: What is most of the agilists pitfalls were actually overdoings of original solutions? E.g. "not planning ahead enough" originally was defying year-long plans with no flexibility, "believing too much in iterations" came from "all in once" large feature sets, "ignoring politics" was meant to get politics out of discussions that were technical in nature. / And at the same time, there are some hidden assumptions that were true in 2001 but might not have aged well: The original agilists had the technical experience, the project management skills, the solid understanding of how to design systems for the long run. If you do not have that, you build agile sandcastles.
Thank you, Charles, for both drawing into conscious awareness that which has been swirling around us for a while, and inspiring me to go and write about this mess myself... 👏
Excellent points, as always, Charles. I think there are some underlying factors you are hitting on: a lack of trust leaders have for their teams to have authority. Just like they want the consultants to make them look good, they don't want their teams to make them look bad. Suppose there is no trust in the individual contributors in an organization. In that case, research, authority to the team, or value described by anyone other than the leader is irrelevant in decision-making. Trust and cultural issues must be fixed in organizations where this occurs before that organization can succeed, regardless of agile or AI (the thing most lacking trust). Otherwise, it is like trying to cure cancer in a patient that has heart disease. The cancer cure isn't the problem.
I think Agile works well to create new things. When you are starting from scratch it's tremendously powerful to create working software quickly and iterate on it. It's exciting for everyone involved!
But it gets harder and harder to maintain or improve existing software, there's less excitement, more bugs have to get incorporated into sprints or iterations or whatever you call them. Each release is going to be less and less impactful for users. Technical debt starts to add up and slow everything down. Regression issues become a massive challenge. The lack of focus on documentation in those early stages creates huge barriers to onboarding new people.
What I've observed is that fewer companies are willing to tear things up to rebuild, because they've already invested in the development of what they have now. There's not obvious return for starting over when your software works...mostly. Lots of more mature organizations are waiting for the AI dust to settle before they commit to any major overhaul. Why would you need a dedicated scrum master when your developers work on bug fixes and tiny new features that take forever to implement?
For the last years, I’ve seen a lot of criticism around Agile, but this is the first time somebody really understands Agile before criticising it. Awesome reflection.
as always, your view mirrors my work life so faithfully that it is moving. Looking at organizations from a sociological point of view is a novelty to me but it feels both refreshing and reassuring
Thank you Federico
FWIW, as one of the 17 people who doesn't agree on what iteration means, I think there's a lot of pragmatic truth here.
The manifesto we produced was idealistic (read "naive"). It assumed that an entire organization could somehow embrace its philosophy as we all kum ba yah'd our way towards *value*. When the inevitable impedance mismatch became apparent, half of the agile folks started selling solutions to management, and the rest pretended it didn't matter.
What followed was the inevitable degradation of the ideas and values of the manifesto. To me, that's a tragedy, because I still believe after 25 years that the original four values are meaningful.
Many of the advocates of "Agile" (which is not a noun...) claim that it is still valid, and that people are just doing it incorrectly. And, indeed, in the article you mention things such as "build, measure, build", which is common, but which is not what an agile team should be doing.
But I increasingly feel that those advocates are missing the point. The real question is "is it possible to follow the values of the manifesto in the real world?". And the answer is clearly "not very often."
My most watched talk on youtube is Agile is Dead, from 2015 (https://www.youtube.com/watch?v=a-BOSpxYJ9M). There I argue that we may as well abandon the word "Agile." But I also suggest that doesn't require us to abandon the values, too.
Since then, I've been pondering what that actually means; how is it possible to honor the manifesto's values while working in a decidedly Taylorist world?
I'm coming to the conclusion that individuals and teams can still greatly benefit from agility, but only when applied locally and pragmatically. My current belief is that this manifests as a drive for simplicity in a world that tries to make everything more complex.
But that would be another thread... :)
Nice article: good thoughts, well presented.
Dave
Would you by any chance be interested in coauthoring a post on this topic?
Thank you for your thoughts. This is very helpful.
The article got me thinking: What is most of the agilists pitfalls were actually overdoings of original solutions? E.g. "not planning ahead enough" originally was defying year-long plans with no flexibility, "believing too much in iterations" came from "all in once" large feature sets, "ignoring politics" was meant to get politics out of discussions that were technical in nature. / And at the same time, there are some hidden assumptions that were true in 2001 but might not have aged well: The original agilists had the technical experience, the project management skills, the solid understanding of how to design systems for the long run. If you do not have that, you build agile sandcastles.
Thank you, Charles, for both drawing into conscious awareness that which has been swirling around us for a while, and inspiring me to go and write about this mess myself... 👏
You're welcome. Send me what you write!
Excellent points, as always, Charles. I think there are some underlying factors you are hitting on: a lack of trust leaders have for their teams to have authority. Just like they want the consultants to make them look good, they don't want their teams to make them look bad. Suppose there is no trust in the individual contributors in an organization. In that case, research, authority to the team, or value described by anyone other than the leader is irrelevant in decision-making. Trust and cultural issues must be fixed in organizations where this occurs before that organization can succeed, regardless of agile or AI (the thing most lacking trust). Otherwise, it is like trying to cure cancer in a patient that has heart disease. The cancer cure isn't the problem.
I think Agile works well to create new things. When you are starting from scratch it's tremendously powerful to create working software quickly and iterate on it. It's exciting for everyone involved!
But it gets harder and harder to maintain or improve existing software, there's less excitement, more bugs have to get incorporated into sprints or iterations or whatever you call them. Each release is going to be less and less impactful for users. Technical debt starts to add up and slow everything down. Regression issues become a massive challenge. The lack of focus on documentation in those early stages creates huge barriers to onboarding new people.
What I've observed is that fewer companies are willing to tear things up to rebuild, because they've already invested in the development of what they have now. There's not obvious return for starting over when your software works...mostly. Lots of more mature organizations are waiting for the AI dust to settle before they commit to any major overhaul. Why would you need a dedicated scrum master when your developers work on bug fixes and tiny new features that take forever to implement?
I don't want to favorite this, because I think there's a lot of brutal truth to it. Hmm...
So you feel conflicted?
Thank you my friend