4 ms·

Agile does Not work

4 points by jrs235 10y ago

bdcravens 10y ago
The most entertaining part: scrolling through the list of commenters and seeing how many list their title as "Agile Coach", "Scrum Master", etc.
- jrs235 10y ago
  If IT isn't working then you're not really doing IT. You must be doing something else. No true Scotsman!
  - evoik 10y ago
    Sounds like "if it doesn't work you're not praying hard enough".
    - jrs235 10y ago
      At first glance I read "if it doesn't work you're not paying enough".
dragonwriter 10y ago
Agile isn't a thing you do, and it isn't a thing that works or doesn't work. Its very little more than the recognition that what works is highly specific to the group and task, coupled with specific warnings against practices that were commonly and harmfully adopted as one-size-fits-all straightjackets at the time the manifesto was written. Particular methodologies -- like Scrum, which is often conflated with Agile -- may or may not work (and, more particularly, may or may not be ideal for certain classes of project), but that's a very different issue. OTOH, I think that Agile has a critical problem which is revealed by the fact that people confuse it with various methodologies (particularly Scrum) -- it is so nebulous that no one actually considers the manifesto to be a thing, and everyone just accepts whatever canned, one-size-fits-all methodology some book or consultant sold them (usually Scrum or a derivative, though I remember when people who said "Agile" were more likely to really mean "XP") is what Agile is, which is fundamentally the kind of mindset Agile was a reaction against. Because Agile -- the manifesto itself -- contains no clear actionable recommendations, just value statements, everyone with a concrete methodology to sell once Agile became a popular buzzword just decided to sell their methodology as Agile.
- dalke 10y ago
  How do you tell if something is agile? If we drop the word "agile", what would we lose? For that matter, couldn't we just call it "software engineering"? The goal of engineering is to choose from different possibilities to come up with a cost-effective solution. I came of age as a professional software developer in the 1990s, before the Agile Manifesto. I was (and still am) in the RAD school of thought. Steve McConnell's "Rapid Application Development" was one of the big software engineering books of the era. It certainly doesn't promote a "one-size-fits-all straightjacket", so I don't recognize your statement as reflecting my understanding of the pre-Agile era. I have also read a lot of accounts of software development pre-Agile Manifesto, from the Mac development to the game software described at http://www.filfre.net/ http://www.filfre.net/ to the first web browsers. I don't recall any of them using a waterfall model or any of its variations. This is also a bit of a hot button for me. All too often I see people arguing, ahistorically, that first there was waterfall and then there was agile. I am one of the skeptics that Wikipedia describes at https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model as saying "the waterfall model is a false argument used purely to market alternative development methodologies."
  - dragonwriter 10y ago
    > How do you tell if something is agile? If the thing is not a person's high-level framework for decisionmaking about the process of making software in a particular group, its easy, its not "Agile" in the sense of the manifesto. If it is such a framework, its Agile iff it applies the values in the manifesto as its guiding principles. > If we drop the word "agile", what would we lose? Very little. I think that one of the big problems of the manifesto is that, while it really was a reaction to a common (then and now) cargo cult approach to software development methodology and, secondarily, particular elements of particular methodologies that were commonly adopted with that approach in certain domains at the time the manifesto was written, it wasn't any kind of fundamental revelation or new approach. (And, arguably, articulated the issue it addressed less well than numerous other sources that also argued that the method of work itself should be subject to a continuous and critical review for fit to the particular team and goals, and not adopted based on generalized lore.) > I came of age as a professional software developer in the 1990s, before the Agile Manifesto. I was (and still am) in the RAD school of thought. Steve McConnell's "Rapid Application Development" was one of the big software engineering books of the era. It certainly doesn't promote a "one-size-fits-all straightjacket", so I don't recognize your statement as reflecting my understanding of the pre-Agile era. The methods of any of the various methodologies in the RAD tradition can be applied as one-size-fits-all straightjackets just as much as any other methodologies (at the time the manifesto was written, they were trendy enough that it was probably happening then just as it is now common with supposedly "agile" methods like Scrum, and just it had previously been -- and still was, in some domains -- with various waterfall methods.) > I have also read a lot of accounts of software development pre-Agile Manifesto, from the Mac development to the game software described at http://www.filfre.net/ http://www.filfre.net/ to the first web browsers. I don't recall any of them using a waterfall model or any of its variations. I'm not sure why you think this is relevant to the post you are responding to, which doesn't mention the waterfall model or any of its variants or suggest any particular relevance of them. (And I also think it suggests a certain bias, because certainly government/enterprise software was still then -- and in many cases is still now -- often built on methods that are commonly referred to as waterfall models [in the case of government, often with institutional mandates that approximate the stages of the waterfall model.]) > This is also a bi of a hot button for me. All too often I see people arguing, ahistorically, that first there was waterfall and then there was agile. Its not ahistorical to argue that the cluster of methodologies typically labeled "agile" (which they shouldn't be) are, in fact, newer than the cluster labeled waterfall models. It would, of course, be grossly inaccurate to assert that there was nothing in between; iterative models (RAD, spiral model, etc.) were in between, both chronologically and conceptually. Its true that the iterated models often get ignored, kind of like Generation X in Boomers vs. Millenials discussions. > I am one of the skeptics that Wikipedia describes at https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model as saying "the waterfall model is a false argument used purely to market alternative development methodologies." Actual documented methodologies in the group labeled "waterfall models" do, in fact, exist and were widely accepted at one point, and had not been generally displaced (though there were newer models challenging them) at the time the agile manifesto is written. The idea of the waterfall model as a concrete methodology is a bit mythical, but things like the Structured System Analysis and Design Method certain did exist (and descendants of that approach are still being used in real institutions.) Asserting that waterfall models are a pure strawman that exist only to sell "agile" models is false as a matter of readily verifiable fact.
dalke 10y ago
In modern use, "agile" means little more than "not waterfall". As such, it's hard to tell if agile works because sprinkling even a little bit of agile dust on a project means it's "agile." Then again, I come from a RAD background, and I don't like how the rich description of different models and approaches, like what Steve McConnell described in "Rapid Development", had mostly devolved into a more ambiguous "agile." On a bit of a tangent, I came across papers from industrial process management that made a similar complaint about Toyota's continuous improvement method. Quoting from the introduction to http://freyssenet.com/?q=node/748 http://freyssenet.com/?q=node/748 : > With this book I hope we are able to show that Toyotism or ‘lean production’ as presented in the bestseller The Machine that Changed the World by Womack, Jones and Rose (1991), is not, as they seem to claim, the only possible industrial organization of the future. http://www.design4change.com/LinkedDocuments/Torslanda%20to%20Uddevalla%20via%20Kalmar.pdf http://www.design4change.com/LinkedDocuments/Torslanda%20to%... calls it a "humanistic alternative" and "Socio-technical", and "Reflective production". Do these alternatives also apply to software development? Would they even better? The agile software people I've talked to have never heard of these alternatives.

4 points by jrs235 10y ago

The most entertaining part: scrolling through the list of commenters and seeing how many list their title as "Agile Coach", "Scrum Master", etc.

jrs235 10y ago
If IT isn't working then you're not really doing IT. You must be doing something else. No true Scotsman!
- evoik 10y ago
  Sounds like "if it doesn't work you're not praying hard enough".
  - jrs235 10y ago
    At first glance I read "if it doesn't work you're not paying enough".

dragonwriter 10y ago

Agile isn't a thing you do, and it isn't a thing that works or doesn't work. Its very little more than the recognition that what works is highly specific to the group and task, coupled with specific warnings against practices that were commonly and harmfully adopted as one-size-fits-all straightjackets at the time the manifesto was written. Particular methodologies -- like Scrum, which is often conflated with Agile -- may or may not work (and, more particularly, may or may not be ideal for certain classes of project), but that's a very different issue. OTOH, I think that Agile has a critical problem which is revealed by the fact that people confuse it with various methodologies (particularly Scrum) -- it is so nebulous that no one actually considers the manifesto to be a thing, and everyone just accepts whatever canned, one-size-fits-all methodology some book or consultant sold them (usually Scrum or a derivative, though I remember when people who said "Agile" were more likely to really mean "XP") is what Agile is, which is fundamentally the kind of mindset Agile was a reaction against. Because Agile -- the manifesto itself -- contains no clear actionable recommendations, just value statements, everyone with a concrete methodology to sell once Agile became a popular buzzword just decided to sell their methodology as Agile.

dalke 10y ago
How do you tell if something is agile? If we drop the word "agile", what would we lose? For that matter, couldn't we just call it "software engineering"? The goal of engineering is to choose from different possibilities to come up with a cost-effective solution. I came of age as a professional software developer in the 1990s, before the Agile Manifesto. I was (and still am) in the RAD school of thought. Steve McConnell's "Rapid Application Development" was one of the big software engineering books of the era. It certainly doesn't promote a "one-size-fits-all straightjacket", so I don't recognize your statement as reflecting my understanding of the pre-Agile era. I have also read a lot of accounts of software development pre-Agile Manifesto, from the Mac development to the game software described at http://www.filfre.net/ http://www.filfre.net/ to the first web browsers. I don't recall any of them using a waterfall model or any of its variations. This is also a bit of a hot button for me. All too often I see people arguing, ahistorically, that first there was waterfall and then there was agile. I am one of the skeptics that Wikipedia describes at https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model as saying "the waterfall model is a false argument used purely to market alternative development methodologies."
- dragonwriter 10y ago
  > How do you tell if something is agile? If the thing is not a person's high-level framework for decisionmaking about the process of making software in a particular group, its easy, its not "Agile" in the sense of the manifesto. If it is such a framework, its Agile iff it applies the values in the manifesto as its guiding principles. > If we drop the word "agile", what would we lose? Very little. I think that one of the big problems of the manifesto is that, while it really was a reaction to a common (then and now) cargo cult approach to software development methodology and, secondarily, particular elements of particular methodologies that were commonly adopted with that approach in certain domains at the time the manifesto was written, it wasn't any kind of fundamental revelation or new approach. (And, arguably, articulated the issue it addressed less well than numerous other sources that also argued that the method of work itself should be subject to a continuous and critical review for fit to the particular team and goals, and not adopted based on generalized lore.) > I came of age as a professional software developer in the 1990s, before the Agile Manifesto. I was (and still am) in the RAD school of thought. Steve McConnell's "Rapid Application Development" was one of the big software engineering books of the era. It certainly doesn't promote a "one-size-fits-all straightjacket", so I don't recognize your statement as reflecting my understanding of the pre-Agile era. The methods of any of the various methodologies in the RAD tradition can be applied as one-size-fits-all straightjackets just as much as any other methodologies (at the time the manifesto was written, they were trendy enough that it was probably happening then just as it is now common with supposedly "agile" methods like Scrum, and just it had previously been -- and still was, in some domains -- with various waterfall methods.) > I have also read a lot of accounts of software development pre-Agile Manifesto, from the Mac development to the game software described at http://www.filfre.net/ http://www.filfre.net/ to the first web browsers. I don't recall any of them using a waterfall model or any of its variations. I'm not sure why you think this is relevant to the post you are responding to, which doesn't mention the waterfall model or any of its variants or suggest any particular relevance of them. (And I also think it suggests a certain bias, because certainly government/enterprise software was still then -- and in many cases is still now -- often built on methods that are commonly referred to as waterfall models [in the case of government, often with institutional mandates that approximate the stages of the waterfall model.]) > This is also a bi of a hot button for me. All too often I see people arguing, ahistorically, that first there was waterfall and then there was agile. Its not ahistorical to argue that the cluster of methodologies typically labeled "agile" (which they shouldn't be) are, in fact, newer than the cluster labeled waterfall models. It would, of course, be grossly inaccurate to assert that there was nothing in between; iterative models (RAD, spiral model, etc.) were in between, both chronologically and conceptually. Its true that the iterated models often get ignored, kind of like Generation X in Boomers vs. Millenials discussions. > I am one of the skeptics that Wikipedia describes at https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model as saying "the waterfall model is a false argument used purely to market alternative development methodologies." Actual documented methodologies in the group labeled "waterfall models" do, in fact, exist and were widely accepted at one point, and had not been generally displaced (though there were newer models challenging them) at the time the agile manifesto is written. The idea of the waterfall model as a concrete methodology is a bit mythical, but things like the Structured System Analysis and Design Method certain did exist (and descendants of that approach are still being used in real institutions.) Asserting that waterfall models are a pure strawman that exist only to sell "agile" models is false as a matter of readily verifiable fact.

dalke 10y ago

In modern use, "agile" means little more than "not waterfall". As such, it's hard to tell if agile works because sprinkling even a little bit of agile dust on a project means it's "agile." Then again, I come from a RAD background, and I don't like how the rich description of different models and approaches, like what Steve McConnell described in "Rapid Development", had mostly devolved into a more ambiguous "agile." On a bit of a tangent, I came across papers from industrial process management that made a similar complaint about Toyota's continuous improvement method. Quoting from the introduction to http://freyssenet.com/?q=node/748 http://freyssenet.com/?q=node/748 : > With this book I hope we are able to show that Toyotism or ‘lean production’ as presented in the bestseller The Machine that Changed the World by Womack, Jones and Rose (1991), is not, as they seem to claim, the only possible industrial organization of the future. http://www.design4change.com/LinkedDocuments/Torslanda%20to%20Uddevalla%20via%20Kalmar.pdf http://www.design4change.com/LinkedDocuments/Torslanda%20to%... calls it a "humanistic alternative" and "Socio-technical", and "Reflective production". Do these alternatives also apply to software development? Would they even better? The agile software people I've talked to have never heard of these alternatives.