4 ms·

> Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones Or maybe they have identified Agile for what it i

> Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones Or maybe they have identified Agile for what it is: a snake oil methodology that's completely unproven, which sometimes works, sometimes doesn't and, regardless of the outcome is never blamed if the project fails. Bit like a religion.

pkaye 11y ago
In your experience, what kind of methodology do you think works?
- ThomaszKrueger 11y ago
  M'fcking programming. Never failed me.
joesmo 11y ago
This is likely the number one reason for rejecting agile: it has already failed. I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. What's worse, the process degrades into 30-60 minute "stand-ups" or "scrums" or whatever, eating into a good chunk of the day for absolutely negative gain (as it's mostly people talking about shit that's irrelevant to 90% of the team and wasting everyone's time because the "process" says they should). I've also seen it degrade into another reason for management to enforce deadlines in all places, including places that only employ deadlines when development is really behind schedule (as is all software development I've ever seen in the business world). And what are the advantages? Little Joe over there in the corner can feel brave enough to speak up about his problem once a day? Seriously? Is this a process for the socially inept? Is that what we're trying to solve here? Disrupting the coding flow? Allowing the manager to be even more lazy in his contact with the team by limiting it to a few minutes a day (closer to 30 than 5)? Having it replace those couple of hours you could have spent designing your app with a few months of 16 hour bug-tracking right before release? Oh, please ... I think it's time to acknowledge the process doesn't work, that anyone can come up with hundreds of points showing why it doesn't, and that it's time to ditch this resource-wasting process altogether.
- gregmac 11y ago
  > I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. > I think it's time to acknowledge the process doesn't work Sure, if you don't actually do it, it doesn't work. For example, you could say: "I've worked at over a dozen places claiming to be linux shops, but they don't have linux installed anywhere. I think it's time to acknowledge linux doesn't work." Does this mean that agile itself is bad? No, it can and does work. It's just much harder to do correctly than it seems (eg: it takes more than reading a book, putting a Kanban board up, and having a daily "standup" meeting).
  - joesmo 11y ago
    Here's a new methodology I invented (that's about as useful as agile): perfection. Do everything perfectly. However, no one has managed to implement this amazing new methodology in a way that works yet. It's so simple. So many have tried and failed. Surely it's not the perfection methodology that's at fault because that's perfect. It must be the idiots trying to implement it, who haven't actually implemented perfection, that are failing to implement perfection. If only they could implement perfection, they'd see how perfect perfection is! But I don't see perfection anywhere! WTF?
- dragonwriter 11y ago
  > I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. Agile is, if it is anything, a set of values for selecting what you do, not a set of things you do. And a weakness in the Agile literature is that there is a lot that talks about things you could do (and a lot of it conflicts), but there is a lot less about how you make the values of the Agile manifesto concrete in selecting and adapting what you do (while its not specifically "Agile", there's a lot written on this that is applicable in an Agile context in the Lean methods literature -- Lean and Agile are directed at largely similar values, but Lean has stronger roots in process engineering and seems to have more focus on understanding why things work and how you know that they work.)
  - joesmo 11y ago
_dark_matter_ 11y ago
>they have identified Agile for what it is: a snake oil methodology that's completely unproven Is this a common line of thought? I recently started working for a company that follows Agile and I thought it was generally accepted as the "next step" so to speak in software development. I didn't know that there was any resentment for it. Care to elaborate? Do others feel this way as well?
- scarmig 11y ago
  Agile would be good if it existed as described and was a stable organizational mode. In reality, every "Agile" place I've worked for really uses Agile-for-name-value-only, which amounts to daily half-hour long status reports on what you did yesterday and project deadlines that come from on high that have to be ratified pro forma by the engineering team. Yes, I know that's not true Agile. Just like the USSR wasn't true socialism! Agile can never fail, it can only be failed.
  - BurningFrog 11y ago
    Do you also reject democracy because all brutal dictatorships call themselves The Democratic Republic of X?
    - scarmig 11y ago
      Yes.
- techterrier 11y ago
  It's certainly preferable to team of analysts spending 6 months writing specs, then engineers spending 12 months writing code, then 2 years spent testing and fixing things only to find out that while that's all been happening the internets been invented and the original product has no purpose.
  - ssmoot 11y ago
    Anecdotal, but I've never been witness to a project where requirements changed so drastically it led to failure. I've seen MANY "Agile" projects where effectively no analysis was done however. Which then reliably leads to failure. EDIT: To add: If the success metric you're using is: From the client's perspective, do they get what they asked for, when they were promised, for the price they agreed to? Then I've seen a majority of "Waterfall" like projects succeed. And the ones that don't typically "fail fast" in the analysis phase. I've never seen an Agile project meet that bar. By the time they're canned they're usually already way over budget and while a team might imagine they've "delivered value" the projects are (IME) canned specifically because it became evident they would most likely be handed over to another vendor and the delivered version scrapped entirely at some point. I also find it frustratingly comical that projects are routinely compared to assembly line work (Toyota assembly line philosophies) when they have a lot more in common with the design and development phases of car production. Agile in the small perhaps, but overall an incredibly structured process with a lot of planning and analysis. Unless you want a car launch 3 years late that costs 50% more than you promised. Nobody wants an "Agile" car (unless you've already set aside your deposit for a Tesla Model 3 I suppose ;-) ). If I were a client, there's no way I'd ever give a anything bigger than a low six figure project to an Agile shop. For a process intended to lower risk, I've only seen it do the opposite.
dragonwriter 11y ago
Agile isn't a methodology, so it can't be a snake oil methodology. However, it's also not a set of quantifiable, unambiguously decidable metrics for evaluating a set of methodological choices, either, so a lot of different methodologies, some of them snake-oil, get sold as Agile (and some which aren't snake-oil get sold in a way which obscures the actual indications for use, which turns then into effectively snake-oil even when they have, underneath, something fundamentally sound.)
baconner 11y ago
I can appreciate where your comment probably comes from - it's absolutely been oversold at many organizations and there's an industry of scrum trainers and the like that oversell it. Against the standard of perfection no methodology works and none ever will I think. Software development is messy and complicated and difficult to put in a box. Still agile doesn't claim to be a silver bullet. It's a loose collection of ideas about how to adapt to change and communicate better during development. Its just about strategies to contain the mess. Thats it. On my teams I've seen great benefits from some things like sprint reviews but it has not magically produced high quality code or made customers love every product. We didn't try to saddle it with that expectation though. For me its enough that it's less painful than gigantic specs that are never quite correct but more visble than everyone just winging it and it gives us some checkpoints to tweak the process regularly to improve the way we work. That's an improvement imo. If you treat it as a religion then yes it's going to be a big disappointment. The same is true for any methodology.

pkaye 11y ago

In your experience, what kind of methodology do you think works?

ThomaszKrueger 11y ago
M'fcking programming. Never failed me.

joesmo 11y ago

This is likely the number one reason for rejecting agile: it has already failed. I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. What's worse, the process degrades into 30-60 minute "stand-ups" or "scrums" or whatever, eating into a good chunk of the day for absolutely negative gain (as it's mostly people talking about shit that's irrelevant to 90% of the team and wasting everyone's time because the "process" says they should). I've also seen it degrade into another reason for management to enforce deadlines in all places, including places that only employ deadlines when development is really behind schedule (as is all software development I've ever seen in the business world). And what are the advantages? Little Joe over there in the corner can feel brave enough to speak up about his problem once a day? Seriously? Is this a process for the socially inept? Is that what we're trying to solve here? Disrupting the coding flow? Allowing the manager to be even more lazy in his contact with the team by limiting it to a few minutes a day (closer to 30 than 5)? Having it replace those couple of hours you could have spent designing your app with a few months of 16 hour bug-tracking right before release? Oh, please ... I think it's time to acknowledge the process doesn't work, that anyone can come up with hundreds of points showing why it doesn't, and that it's time to ditch this resource-wasting process altogether.

gregmac 11y ago
> I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. > I think it's time to acknowledge the process doesn't work Sure, if you don't actually do it, it doesn't work. For example, you could say: "I've worked at over a dozen places claiming to be linux shops, but they don't have linux installed anywhere. I think it's time to acknowledge linux doesn't work." Does this mean that agile itself is bad? No, it can and does work. It's just much harder to do correctly than it seems (eg: it takes more than reading a book, putting a Kanban board up, and having a daily "standup" meeting).
- joesmo 11y ago
  Here's a new methodology I invented (that's about as useful as agile): perfection. Do everything perfectly. However, no one has managed to implement this amazing new methodology in a way that works yet. It's so simple. So many have tried and failed. Surely it's not the perfection methodology that's at fault because that's perfect. It must be the idiots trying to implement it, who haven't actually implemented perfection, that are failing to implement perfection. If only they could implement perfection, they'd see how perfect perfection is! But I don't see perfection anywhere! WTF?
dragonwriter 11y ago
> I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. Agile is, if it is anything, a set of values for selecting what you do, not a set of things you do. And a weakness in the Agile literature is that there is a lot that talks about things you could do (and a lot of it conflicts), but there is a lot less about how you make the values of the Agile manifesto concrete in selecting and adapting what you do (while its not specifically "Agile", there's a lot written on this that is applicable in an Agile context in the Lean methods literature -- Lean and Agile are directed at largely similar values, but Lean has stronger roots in process engineering and seems to have more focus on understanding why things work and how you know that they work.)
- joesmo 11y ago

_dark_matter_ 11y ago

>they have identified Agile for what it is: a snake oil methodology that's completely unproven Is this a common line of thought? I recently started working for a company that follows Agile and I thought it was generally accepted as the "next step" so to speak in software development. I didn't know that there was any resentment for it. Care to elaborate? Do others feel this way as well?

scarmig 11y ago
Agile would be good if it existed as described and was a stable organizational mode. In reality, every "Agile" place I've worked for really uses Agile-for-name-value-only, which amounts to daily half-hour long status reports on what you did yesterday and project deadlines that come from on high that have to be ratified pro forma by the engineering team. Yes, I know that's not true Agile. Just like the USSR wasn't true socialism! Agile can never fail, it can only be failed.
- BurningFrog 11y ago
  Do you also reject democracy because all brutal dictatorships call themselves The Democratic Republic of X?
  - scarmig 11y ago
    Yes.
techterrier 11y ago
It's certainly preferable to team of analysts spending 6 months writing specs, then engineers spending 12 months writing code, then 2 years spent testing and fixing things only to find out that while that's all been happening the internets been invented and the original product has no purpose.
- ssmoot 11y ago
  Anecdotal, but I've never been witness to a project where requirements changed so drastically it led to failure. I've seen MANY "Agile" projects where effectively no analysis was done however. Which then reliably leads to failure. EDIT: To add: If the success metric you're using is: From the client's perspective, do they get what they asked for, when they were promised, for the price they agreed to? Then I've seen a majority of "Waterfall" like projects succeed. And the ones that don't typically "fail fast" in the analysis phase. I've never seen an Agile project meet that bar. By the time they're canned they're usually already way over budget and while a team might imagine they've "delivered value" the projects are (IME) canned specifically because it became evident they would most likely be handed over to another vendor and the delivered version scrapped entirely at some point. I also find it frustratingly comical that projects are routinely compared to assembly line work (Toyota assembly line philosophies) when they have a lot more in common with the design and development phases of car production. Agile in the small perhaps, but overall an incredibly structured process with a lot of planning and analysis. Unless you want a car launch 3 years late that costs 50% more than you promised. Nobody wants an "Agile" car (unless you've already set aside your deposit for a Tesla Model 3 I suppose ;-) ). If I were a client, there's no way I'd ever give a anything bigger than a low six figure project to an Agile shop. For a process intended to lower risk, I've only seen it do the opposite.

dragonwriter 11y ago

Agile isn't a methodology, so it can't be a snake oil methodology. However, it's also not a set of quantifiable, unambiguously decidable metrics for evaluating a set of methodological choices, either, so a lot of different methodologies, some of them snake-oil, get sold as Agile (and some which aren't snake-oil get sold in a way which obscures the actual indications for use, which turns then into effectively snake-oil even when they have, underneath, something fundamentally sound.)

baconner 11y ago

I can appreciate where your comment probably comes from - it's absolutely been oversold at many organizations and there's an industry of scrum trainers and the like that oversell it. Against the standard of perfection no methodology works and none ever will I think. Software development is messy and complicated and difficult to put in a box. Still agile doesn't claim to be a silver bullet. It's a loose collection of ideas about how to adapt to change and communicate better during development. Its just about strategies to contain the mess. Thats it. On my teams I've seen great benefits from some things like sprint reviews but it has not magically produced high quality code or made customers love every product. We didn't try to saddle it with that expectation though. For me its enough that it's less painful than gigantic specs that are never quite correct but more visble than everyone just winging it and it gives us some checkpoints to tweak the process regularly to improve the way we work. That's an improvement imo. If you treat it as a religion then yes it's going to be a big disappointment. The same is true for any methodology.