4 ms·

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 g

• 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
    I am in agreement with most of your response. I want to follow up on a couple of points. > "I'm not sure why you think this is relevant to the post" Well, it's not. It's a response to the comment concerning "practices that were commonly and harmfully adopted". I want to soften that from "commonly" to "sometimes". However, it's hard for me to really justify that. Agile comes out of government/enterprise. That's clear from the manifesto, which refers to "contract negotiation", and where the principles refer to "the customer's competitive advantage". Neither are really relevant to, say, the end-user games that I mentioned earlier, or to software one writes for oneself for fun. Within government/enterprise organizations then and now, I agree that many use various modified versions of waterfall and, as you say, straight-jacketed methodologies. What I don't know is, how many software projects in the 1990s were using heavy-weight processes, vs. ones which would be now called agile? (Or a third category of none-of-the-above?) For example, in the mid-1990s I worked for an academic research group of ~20 people, and we distributed the source and binaries for free so I also did some support for external users. There was no emphasis on processes and tools, nor comprehensive documentation, nor contract negotiation. Most users were within a few tens of meters from me, there was close collaboration, and I could do several build/releases per day if needed. According to the manifesto, I was agile, yes? But that approach was also not uncommon for other research or in-house software, and it wasn't much different from the software development process at the startup I joined in Palo Alto a couple of years later (during the dot-com era), or the places I worked at or consulted at since then, all doing scientific research support software development. By count, and perhaps even by budget, were there more of these small-scale agile-like projects than there were heavy-weight government/enterprise projects? If so, then waterfall would have been relatively uncommon in practice. > "Asserting that waterfall models are a pure strawman that exist only to sell "agile" models is false as a matter of readily verifiable fact." I do not argue that waterfall is a pure strawman, rather that many agile proponents present the dichotomous choice of "waterfall" vs. "agile", and use that comparison to market an alternative, agile method as the alternative method. (I like your Boomers/Gen.X/ Millennials example - slackers represent!) This isn't a strawman, but ... I don't have a word for it. Choosing the weakest opponent, propping it up by always talking about it, showing you're approach is better, than concluding you are best. Laurent Bossavit has written much about this, but I couldn't find the one I remember reading before, so I'll quote https://www.infoq.com/articles/bossavit-agile-ten-years-on/ https://www.infoq.com/articles/bossavit-agile-ten-years-on/ > The most dangerous distortion of all is the notion, sadly prevalent today, that Agile consists of a handful of competing "brands" of processes: Scrum versus Extreme Programming versus Lean or Kanban. In the interest of pushing this or that brand, the interesting details of our young history are papered over.