Yeah, Agile isn’t really at fault here. If done right - if you’ve got a scrum master, a proper product owner, proper planning and backlog grooming, etc. - it works really well. The problem is some companies think Agile is just “give the devs some pie-in-the-sky hopes and dreams, let 'em loose, and if they don’t give half a dozen execs exactly what they want (despite their massively conflicting ideas on what they want), cancel the project.”
In one the worst “poor planning” projects I’ve been in the product owner just kept sneaking in new “high priority” issues to the top of the backlog throughout the sprint. I don’t think we had a single sprint where we ended up with fewer open issues in the backlog than when we started.
Needless to say, he was the main reason why I quit.
Absolutely
It’s so management can say “your velocity was down 15% this sprint” and not feel bad about it instead of saying “work more”
It’s plausible deniability for demanding unpaid overtime
Yeah, Agile isn’t really at fault here. If done right
This is what ticks me off about the “Agile” brand, it’s chock full of no true Scotsman fallacy (if a team failed while doing “Agile”, it means they weren’t being “Agile”).
I can appreciate sympathizing with some tenets as Agile might be presented, but the popularity and consultancy around it has pretty much ruined Agile as a brand.
Broadly speaking, any attempt to capture nuance of “best practices” into a brand word/phrase will be ruined the second it becomes “popular”.
This isn’t a case of No True Scotsman. There really is a right way and a whole lot of wrong ways to do Agile development. Any team that calls itself an Agile team that doesn’t actually follow the processes properly is doing it wrong and will fail.
That doesn’t mean any team that’s doing it right will succeed, but it’s like riding a horse: If you only climb halfway up the horse and try to hold on while at a 90-degree angle, it’s not going to work, and it would be stupid to declare that the concept of horse-riding is broken. No, it’s not broken, you’re just an idiot who thought you could ride a horse while only halfway up, clinging desperately to its side.
Any team that calls itself an Agile team that doesn’t actually follow the processes properly is doing it wrong and will fail.
I mean, this statement is also weird, to imply that not following Agile implies failure. I’d say it’s quite possible for a team to “falsely” execute on Agile and still pull off success. However, if that story is prominent and successful, no one is going to make a peep about it not being “true Agile”, they’ll only do that when it’s a failure.
But really this detail is beside the point, that people want to use ‘Agile’ as shorthand for good methodology, but it’s the way of the world that any shorthand that is popular will get co-opted and corrupted to the point of uselessness. You end up with various “interpretations” and so the meaning is diluted.
Now at a glance, this may seem an innocuous scenario, ok, Agile doesn’t “mean” anything specific in practice because of people abusing it to their objectives, but it still carries the weight of “authority”. So if you have a criticism like “there’s way too many stupid pointless required fields in our Jira implementation, and there’s a super convoluted workflow involving too many stakeholders to walk a simple ticket to completion”, then you get chastised because “our workflow is anchored in Agile, and you can easily see online that Agile makes success, so you obviously don’t understand success”. You can try to declare “Individuals and interactions over processes and tools”, but then they’ll say “oh, but the stuff on the right is valuable, and it’s used to facilitate the interactions between people”. Thanks to Atlassian marketing, for a lot of the corporate world if you implement it in Jira, then it is, by definition, “Agile” and your peons can shut up because you are right.
Basically, things get ruined by trying to abbreviate. You may be able to cite the Agile manifesto as something specific enough yet still short, though it’s still wishy washy enough to not be able to really “win” an argument with someone when deciding how you are going to move forward.
Agreed. The problem is people mistake “zero planning and structure” to mean “agile”. Of course it fails.
Agile to me was always mini waterfall. You always know who’s doing what, why, and what success looks like on a 2 week sprint horizon. When you see people on a sprint without a clear understanding of what they are doing over the next couple of weeks - then you know your project is in trouble for sure.
I don’t have much direct experience working in agile since I tend to work on the business side but I can tell you that the term agile is WAY overused. So many projects are described as agile when they are just waterfall with more steps. Leaders love to say they are working in agile because it sounds ‘techy’ and cool, but I don’t think they fully appreciate what it is vs other methods. I wonder if a lot of the failed projects described in the article are some of those agile in name only kind of things.
A more proper title would be “study finds 268% higher failure rates for poorly planned software projects”.
“Agile” as a word is mostly an excuse of poor planners for their poor planning skills.
Yeah, Agile isn’t really at fault here. If done right - if you’ve got a scrum master, a proper product owner, proper planning and backlog grooming, etc. - it works really well. The problem is some companies think Agile is just “give the devs some pie-in-the-sky hopes and dreams, let 'em loose, and if they don’t give half a dozen execs exactly what they want (despite their massively conflicting ideas on what they want), cancel the project.”
In one the worst “poor planning” projects I’ve been in the product owner just kept sneaking in new “high priority” issues to the top of the backlog throughout the sprint. I don’t think we had a single sprint where we ended up with fewer open issues in the backlog than when we started.
Needless to say, he was the main reason why I quit.
In my experience it’s just kanban, but make the devs feels guilty between sprints for not meeting their goals.
Absolutely It’s so management can say “your velocity was down 15% this sprint” and not feel bad about it instead of saying “work more” It’s plausible deniability for demanding unpaid overtime
This is what ticks me off about the “Agile” brand, it’s chock full of no true Scotsman fallacy (if a team failed while doing “Agile”, it means they weren’t being “Agile”).
I can appreciate sympathizing with some tenets as Agile might be presented, but the popularity and consultancy around it has pretty much ruined Agile as a brand.
Broadly speaking, any attempt to capture nuance of “best practices” into a brand word/phrase will be ruined the second it becomes “popular”.
This isn’t a case of No True Scotsman. There really is a right way and a whole lot of wrong ways to do Agile development. Any team that calls itself an Agile team that doesn’t actually follow the processes properly is doing it wrong and will fail.
That doesn’t mean any team that’s doing it right will succeed, but it’s like riding a horse: If you only climb halfway up the horse and try to hold on while at a 90-degree angle, it’s not going to work, and it would be stupid to declare that the concept of horse-riding is broken. No, it’s not broken, you’re just an idiot who thought you could ride a horse while only halfway up, clinging desperately to its side.
I mean, this statement is also weird, to imply that not following Agile implies failure. I’d say it’s quite possible for a team to “falsely” execute on Agile and still pull off success. However, if that story is prominent and successful, no one is going to make a peep about it not being “true Agile”, they’ll only do that when it’s a failure.
But really this detail is beside the point, that people want to use ‘Agile’ as shorthand for good methodology, but it’s the way of the world that any shorthand that is popular will get co-opted and corrupted to the point of uselessness. You end up with various “interpretations” and so the meaning is diluted.
Now at a glance, this may seem an innocuous scenario, ok, Agile doesn’t “mean” anything specific in practice because of people abusing it to their objectives, but it still carries the weight of “authority”. So if you have a criticism like “there’s way too many stupid pointless required fields in our Jira implementation, and there’s a super convoluted workflow involving too many stakeholders to walk a simple ticket to completion”, then you get chastised because “our workflow is anchored in Agile, and you can easily see online that Agile makes success, so you obviously don’t understand success”. You can try to declare “Individuals and interactions over processes and tools”, but then they’ll say “oh, but the stuff on the right is valuable, and it’s used to facilitate the interactions between people”. Thanks to Atlassian marketing, for a lot of the corporate world if you implement it in Jira, then it is, by definition, “Agile” and your peons can shut up because you are right.
Basically, things get ruined by trying to abbreviate. You may be able to cite the Agile manifesto as something specific enough yet still short, though it’s still wishy washy enough to not be able to really “win” an argument with someone when deciding how you are going to move forward.
Agreed. The problem is people mistake “zero planning and structure” to mean “agile”. Of course it fails.
Agile to me was always mini waterfall. You always know who’s doing what, why, and what success looks like on a 2 week sprint horizon. When you see people on a sprint without a clear understanding of what they are doing over the next couple of weeks - then you know your project is in trouble for sure.
I don’t have much direct experience working in agile since I tend to work on the business side but I can tell you that the term agile is WAY overused. So many projects are described as agile when they are just waterfall with more steps. Leaders love to say they are working in agile because it sounds ‘techy’ and cool, but I don’t think they fully appreciate what it is vs other methods. I wonder if a lot of the failed projects described in the article are some of those agile in name only kind of things.
An even better title would be “‘Study’ by firm pushing new technique finds old technique is bad.”