8 ms·

More of the "No True Scotsman" apologia for why Agile fails so often. I especially liked this gem: >Team members reject Agile methodologies openly, as they do

by noarchy 11y ago

More of the "No True Scotsman" apologia for why Agile fails so often. I especially liked this gem: >Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones. I can't say I'd feel bad if a failed, Agile approach was not in my comfort zone.

DanielBMarkham 11y ago
As somebody who uses this argument, and somebody who cares about reasoned debate, I must disagree. Agile is not a standard. There is no class, there are no tests, and there is no governing body to determine whether you are agile or not. As such, it's just a marketing term around best practices in iterative and incremental development. Along with XP and the latest hotness in CI/CD/DevOps/etc, it's where you go to see how the cool kids are doing it. Since it's "cool stuff that works most of the time in hi-tech teams", the real question here is this: are you trying new stuff? If so, are you trying stuff that seems to work for a lot of people? If you are not, then, by definition, you are not "doing agile" (or however you want to phrase it). If you are, good for you! You still might suck, but at least you'll suck in different and interesting ways. So in this case the writer is correct. The "No True Scotsman" label does not apply. There are no Scotsmen to begin with. ADD: And of course the flip-side to my argument is also true. Don't get me started with the folks who think that simply because you're doing various Agile practices you should automatically be succeeding -- or the folks that think "if we were only doing Scrum the right way". I've had a lot of headaches there. Tools exist to get work done. If the work is not getting done, use a different tool. "Agile" is simply the sign over the place in the hardware store we go to get certain kinds of tools. We understand and apply tools expertly, but we do not do work by spending all of our time and energy being focused on tools. Instead, good tools allow us to focus our time and energy on the problem.
- noarchy 11y ago
  Of course it is a marketing term. There are enough people billing themselves out as Agile "coaches", or Scrum "consultants", that the marketing seems to be working. But if they aren't Scotsmen, they've done some great marketing to make people think that they are. So if you or your organization failed, it is because the wrong people were implementing it and/or you did it wrong.
  - DanielBMarkham 11y ago
    Here's an apt quote from HN a few years back regarding tools. https://news.ycombinator.com/item?id=2380679 https://news.ycombinator.com/item?id=2380679
    - noarchy 11y ago
      The excerpt from that post that I find most appropriate is, "Bad tools typically take longer to work with, and typically teach bad habits to get around their deficiencies." That's how many of us feel about Agile.
- incepted 11y ago
  > there is no governing body to determine whether you are agile or not Tell that to agile advocates who are always quick to point out that when a project using Agile fails, it's never Agile's fault, it's always because the team didn't apply Agile correctly. It's the text book definition of "No True Scotsman".
  - exelius 11y ago
    Those "agile advocates" are just trying to sell their own services to improve your "agile functioning". Shame on you for falling for it. Agile is so widespread at this point that "doing Agile wrong" isn't a reason teams fail. Most Agile teams fail for reasons outside the development process. Ineffective leadership, lack of experience, poor product focus, etc. These teams would have failed with a waterfall model too; it would have just taken longer to realize it.
    - noarchy 11y ago
      >Those "agile advocates" are just trying to sell their own services to improve your "agile functioning". Shame on you for falling for it. Agile is so widespread at this point that "doing Agile wrong" isn't a reason teams fail. To be fair, it isn't often the individual developer who "falls" for it. These management methodologies are imposed on them, and the developer has to learn to roll with it. You may not be in a position to determine whether or not a project manager was sent off for "Scrum master certification".
deanCommie 11y ago
Presuming that the approach in this situation is a failed one. I've encountered extreme resistance from devs who have already made their mind about Agile ("just let me write some fucking code") and fought against the leanest of agile principles ("Hey, how about we try to only plan for 2-3 weeks ahead, aim to have something demoable, and then have a retrospective to see what we could do differently next time around?" "Pass.") Fact is, too many developers think their job is to write code. It's not. It's to solve a customer problem. And if that problem can be solved with code, great. But since 99% of the time the customer doesn't know what their problem is, doesn't know how to explain it, or will change their mind once they see it, that is why agile principles were declared - to help developers deal with this challenge.
- VLM 11y ago
  >that is why agile principles were declared - to help developers deal with this challenge. I've noticed that in practice everyone benefits from agile except the devs... The managers have new and extremely elaborate play acting to perform, dominance to new authority to vigorously enforce, and extensive new paperwork and reports and whiteboards to shuffle. The snake oil salesmen obviously love selling snake oil. The marketing and HR folk have a new feature nobody can deny they use because nobody knows what it is, its like being "customer focused" or "empowered", it means nothing and sounds nice therefore everyone does it. Customer svc has a great excuse, well, sure you have a bug, but now we have agile so surely there will never be any bugs in the future. The customers are told things will get better because of Agile and when things invariably get better for whatever reason, it was because of the wise application of agile and their wisdom in selecting an agile supplier. But what do the actual devs get out of it? Nothing, really. Everything that happens around a plastic christmas tree is really cool and fuzzy and happy and the best thing to ever happen and the nicest time of the year and watch us drinking cups of eggnog while you stand there as a plastic christmas tree. And that's nice ... for everyone around the christmas tree. But with some empathy for the point of view of the plastic christmas tree itself, all the foolishness related to christmas, is kinda irrelevant to itself in it's tree-i-ness. The plastic christmas tree is having a lot of things done to it and around it but it is not affected in any way.
exelius 11y ago
I absolutely disagree. There is no "True Scotsman" argument against Agile, IMO because there is no such thing as "true Agile". The best description I've heard of Agile is that it is the bare minimum amount of project management you can do on a project and still be successful. Beyond that, it's all about what works for each team. The entire f-ing point of Agile is that it's a generic framework you can adapt to many different business contexts. But there are still common reasons Agile methodologies fail. I don't know how many of these are really failures of "Agile" or just common mistakes that new teams in general make. But it doesn't really matter, because the two situations are often inextricable from each other.
- Glide 11y ago
  I concur wholeheartedly. I've had people claim that they do agile. No retrospectives or any kind of feedback loop in their processes. No modification of work tracking either. All of that customization was from the top. Basically breaking several core tenets right there... But I digress. We really need to accept that delivering is difficult to do. Creating new teams is a _hard_ thing to do. Delivering a project on time when the team wasn't formed at the beginning and had no input into the timeline is difficult. No matter what methodology you use there are things that can kill the project.
- noarchy 11y ago
  >There is no "True Scotsman" argument against Agile, IMO because there is no such thing as "true Agile". If Agile is so nebulous as a concept that it can't be defined (only vaguely described, at best), then perhaps it cannot fail. But it also cannot succeed, as it apparently doesn't exist. There may be teams for whom these management methodologies work, and good for them. I am genuinely curious about how much the success or failure of these methods have been studied.
  - exelius 11y ago
    Agile can be defined, but at its core, Agile is a set of best practices that by definition can be ignored. It's a collection of optional components that can produce a functional process when cobbled together in the right way. But figuring out what works for a team is often a lot of trial and error, so a skilled "Agile practitioner" can help you look at what has worked for you, what hasn't, and suggest things to try. And you're right; when defined this way, Agile cannot fail. Agile isn't a magic bullet for your development team - at its core, Agile is a method by which dev teams can more or less self-organize around a set of generally agreed-upon processes. But it's up to each Agile team to develop those processes themselves. I have yet to see an Agile team fail because their Agile process failed. I have seen Agile teams fail because the team was too inexperienced to provide their own direction. I have seen Agile teams fail because the dev lead wanted to play dictator. I've seen Agile teams fail because their business counterparts kept changing the requirements and demanding impossible things of the dev team. I've never seen an Agile team fail because they couldn't figure out how to assign user stories or because they had no concept of release management. Sure, those things might be a disaster, but usually (after enough times going through some painful manual process) some developer steps up and says "Hey, I think I know a better way we can do this..." And those problems almost never endanger releases because Agile teams are by their very nature empowered to solve problems. Sure, the solution may have been inefficient and non-repeatable, but it worked.

by noarchy 11y ago

DanielBMarkham 11y ago

As somebody who uses this argument, and somebody who cares about reasoned debate, I must disagree. Agile is not a standard. There is no class, there are no tests, and there is no governing body to determine whether you are agile or not. As such, it's just a marketing term around best practices in iterative and incremental development. Along with XP and the latest hotness in CI/CD/DevOps/etc, it's where you go to see how the cool kids are doing it. Since it's "cool stuff that works most of the time in hi-tech teams", the real question here is this: are you trying new stuff? If so, are you trying stuff that seems to work for a lot of people? If you are not, then, by definition, you are not "doing agile" (or however you want to phrase it). If you are, good for you! You still might suck, but at least you'll suck in different and interesting ways. So in this case the writer is correct. The "No True Scotsman" label does not apply. There are no Scotsmen to begin with. ADD: And of course the flip-side to my argument is also true. Don't get me started with the folks who think that simply because you're doing various Agile practices you should automatically be succeeding -- or the folks that think "if we were only doing Scrum the right way". I've had a lot of headaches there. Tools exist to get work done. If the work is not getting done, use a different tool. "Agile" is simply the sign over the place in the hardware store we go to get certain kinds of tools. We understand and apply tools expertly, but we do not do work by spending all of our time and energy being focused on tools. Instead, good tools allow us to focus our time and energy on the problem.

noarchy 11y ago
Of course it is a marketing term. There are enough people billing themselves out as Agile "coaches", or Scrum "consultants", that the marketing seems to be working. But if they aren't Scotsmen, they've done some great marketing to make people think that they are. So if you or your organization failed, it is because the wrong people were implementing it and/or you did it wrong.
- DanielBMarkham 11y ago
  Here's an apt quote from HN a few years back regarding tools. https://news.ycombinator.com/item?id=2380679 https://news.ycombinator.com/item?id=2380679
  - noarchy 11y ago
    The excerpt from that post that I find most appropriate is, "Bad tools typically take longer to work with, and typically teach bad habits to get around their deficiencies." That's how many of us feel about Agile.
incepted 11y ago
> there is no governing body to determine whether you are agile or not Tell that to agile advocates who are always quick to point out that when a project using Agile fails, it's never Agile's fault, it's always because the team didn't apply Agile correctly. It's the text book definition of "No True Scotsman".
- exelius 11y ago
  Those "agile advocates" are just trying to sell their own services to improve your "agile functioning". Shame on you for falling for it. Agile is so widespread at this point that "doing Agile wrong" isn't a reason teams fail. Most Agile teams fail for reasons outside the development process. Ineffective leadership, lack of experience, poor product focus, etc. These teams would have failed with a waterfall model too; it would have just taken longer to realize it.
  - noarchy 11y ago
    >Those "agile advocates" are just trying to sell their own services to improve your "agile functioning". Shame on you for falling for it. Agile is so widespread at this point that "doing Agile wrong" isn't a reason teams fail. To be fair, it isn't often the individual developer who "falls" for it. These management methodologies are imposed on them, and the developer has to learn to roll with it. You may not be in a position to determine whether or not a project manager was sent off for "Scrum master certification".

deanCommie 11y ago

Presuming that the approach in this situation is a failed one. I've encountered extreme resistance from devs who have already made their mind about Agile ("just let me write some fucking code") and fought against the leanest of agile principles ("Hey, how about we try to only plan for 2-3 weeks ahead, aim to have something demoable, and then have a retrospective to see what we could do differently next time around?" "Pass.") Fact is, too many developers think their job is to write code. It's not. It's to solve a customer problem. And if that problem can be solved with code, great. But since 99% of the time the customer doesn't know what their problem is, doesn't know how to explain it, or will change their mind once they see it, that is why agile principles were declared - to help developers deal with this challenge.

VLM 11y ago
>that is why agile principles were declared - to help developers deal with this challenge. I've noticed that in practice everyone benefits from agile except the devs... The managers have new and extremely elaborate play acting to perform, dominance to new authority to vigorously enforce, and extensive new paperwork and reports and whiteboards to shuffle. The snake oil salesmen obviously love selling snake oil. The marketing and HR folk have a new feature nobody can deny they use because nobody knows what it is, its like being "customer focused" or "empowered", it means nothing and sounds nice therefore everyone does it. Customer svc has a great excuse, well, sure you have a bug, but now we have agile so surely there will never be any bugs in the future. The customers are told things will get better because of Agile and when things invariably get better for whatever reason, it was because of the wise application of agile and their wisdom in selecting an agile supplier. But what do the actual devs get out of it? Nothing, really. Everything that happens around a plastic christmas tree is really cool and fuzzy and happy and the best thing to ever happen and the nicest time of the year and watch us drinking cups of eggnog while you stand there as a plastic christmas tree. And that's nice ... for everyone around the christmas tree. But with some empathy for the point of view of the plastic christmas tree itself, all the foolishness related to christmas, is kinda irrelevant to itself in it's tree-i-ness. The plastic christmas tree is having a lot of things done to it and around it but it is not affected in any way.

exelius 11y ago

I absolutely disagree. There is no "True Scotsman" argument against Agile, IMO because there is no such thing as "true Agile". The best description I've heard of Agile is that it is the bare minimum amount of project management you can do on a project and still be successful. Beyond that, it's all about what works for each team. The entire f-ing point of Agile is that it's a generic framework you can adapt to many different business contexts. But there are still common reasons Agile methodologies fail. I don't know how many of these are really failures of "Agile" or just common mistakes that new teams in general make. But it doesn't really matter, because the two situations are often inextricable from each other.

Glide 11y ago
I concur wholeheartedly. I've had people claim that they do agile. No retrospectives or any kind of feedback loop in their processes. No modification of work tracking either. All of that customization was from the top. Basically breaking several core tenets right there... But I digress. We really need to accept that delivering is difficult to do. Creating new teams is a _hard_ thing to do. Delivering a project on time when the team wasn't formed at the beginning and had no input into the timeline is difficult. No matter what methodology you use there are things that can kill the project.
noarchy 11y ago
>There is no "True Scotsman" argument against Agile, IMO because there is no such thing as "true Agile". If Agile is so nebulous as a concept that it can't be defined (only vaguely described, at best), then perhaps it cannot fail. But it also cannot succeed, as it apparently doesn't exist. There may be teams for whom these management methodologies work, and good for them. I am genuinely curious about how much the success or failure of these methods have been studied.
- exelius 11y ago
  Agile can be defined, but at its core, Agile is a set of best practices that by definition can be ignored. It's a collection of optional components that can produce a functional process when cobbled together in the right way. But figuring out what works for a team is often a lot of trial and error, so a skilled "Agile practitioner" can help you look at what has worked for you, what hasn't, and suggest things to try. And you're right; when defined this way, Agile cannot fail. Agile isn't a magic bullet for your development team - at its core, Agile is a method by which dev teams can more or less self-organize around a set of generally agreed-upon processes. But it's up to each Agile team to develop those processes themselves. I have yet to see an Agile team fail because their Agile process failed. I have seen Agile teams fail because the team was too inexperienced to provide their own direction. I have seen Agile teams fail because the dev lead wanted to play dictator. I've seen Agile teams fail because their business counterparts kept changing the requirements and demanding impossible things of the dev team. I've never seen an Agile team fail because they couldn't figure out how to assign user stories or because they had no concept of release management. Sure, those things might be a disaster, but usually (after enough times going through some painful manual process) some developer steps up and says "Hey, I think I know a better way we can do this..." And those problems almost never endanger releases because Agile teams are by their very nature empowered to solve problems. Sure, the solution may have been inefficient and non-repeatable, but it worked.