3 ms·

I guess it would all hinge on what exactly is meant by “we developed a process that worked for us based on agile core principles.” The risk of No True Scotsman

by mlthoughts2018 8y ago

I guess it would all hinge on what exactly is meant by “we developed a process that worked for us based on agile core principles.” The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile, even though it may (likely) have nothing to do with anything that could be said to resemble Agile.

dragonwriter 8y ago
> The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile That's more consistent with the Agile Manifesto than calling any of the concrete development methodologies that come out of the Agile community “Agile” merely because they emerge from that community. Choosing the process that works in practice for your team in their concrete situation is pretty much the whole of the Agile Manifesto. The failure of the Agile community is that it has almost no literature or body of knowledge oriented toward how you do that, just a bunch of concrete development practices without tools for adapting them or choosing among them. OTOH, tools operationalizing essentially the values of the Agile Manifesto do exist in the Lean community. (Which is why I sometimes, when feeling particularly snarky, call Lean “Agile, but for engineers” or “Agile, but usable”.)
- mlthoughts2018 8y ago
  If this is true, it means Agile has no definition, it’s a vacuous term. If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work. It reminds me of a great LessWrong quote, “If you can explain every outcome equally well, you have zero knowledge.”
  - dragonwriter 8y ago
    > If this is true, it means Agile has no definition, it’s a vacuous term. No, it's just the definition is not in the space you (and to be fair, lots of other people) seem to want it to be in. > If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work. “Whatever works” is definitely a thing; however, the kind of thing it is, as you note, is not a tool for predicting what will work. “Agile”, though, while not that kidnd of tool, is not exactly “whatever works”, either (and here I'm talking about the Manifesto; it's worth noting that the Manifesto, the Agile community, and the concrete methods labeled as “Agile” are not precisely in alignment); it is a critique of (accusation against? hypothesis about?) the status quo at the time it was written attributing its disappointing performance in finding what works to three errors: (1) Failing to recognize that what works, at the level development practices were generally recommended, is not a universal across software development, but a function of the particular members of the team and their relations, which not only vary between efforts, but vary over time within one effort. (2) Prioritizing written artifacts of the development process more than is justified by their utility to software development. (3) Preference for arms-length negotiation and implementation to collaborative involvement of the customer with the development effort.
    - mlthoughts2018 8y ago
      No, really, it would mean the term is literally vacuous, as in an actual tautology, Agile succeeds because Agile is defined to be whatever has succeeded. It’s not really possible to disagree on it.

dragonwriter 8y ago

> The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile That's more consistent with the Agile Manifesto than calling any of the concrete development methodologies that come out of the Agile community “Agile” merely because they emerge from that community. Choosing the process that works in practice for your team in their concrete situation is pretty much the whole of the Agile Manifesto. The failure of the Agile community is that it has almost no literature or body of knowledge oriented toward how you do that, just a bunch of concrete development practices without tools for adapting them or choosing among them. OTOH, tools operationalizing essentially the values of the Agile Manifesto do exist in the Lean community. (Which is why I sometimes, when feeling particularly snarky, call Lean “Agile, but for engineers” or “Agile, but usable”.)

mlthoughts2018 8y ago
If this is true, it means Agile has no definition, it’s a vacuous term. If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work. It reminds me of a great LessWrong quote, “If you can explain every outcome equally well, you have zero knowledge.”
- dragonwriter 8y ago
  > If this is true, it means Agile has no definition, it’s a vacuous term. No, it's just the definition is not in the space you (and to be fair, lots of other people) seem to want it to be in. > If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work. “Whatever works” is definitely a thing; however, the kind of thing it is, as you note, is not a tool for predicting what will work. “Agile”, though, while not that kidnd of tool, is not exactly “whatever works”, either (and here I'm talking about the Manifesto; it's worth noting that the Manifesto, the Agile community, and the concrete methods labeled as “Agile” are not precisely in alignment); it is a critique of (accusation against? hypothesis about?) the status quo at the time it was written attributing its disappointing performance in finding what works to three errors: (1) Failing to recognize that what works, at the level development practices were generally recommended, is not a universal across software development, but a function of the particular members of the team and their relations, which not only vary between efforts, but vary over time within one effort. (2) Prioritizing written artifacts of the development process more than is justified by their utility to software development. (3) Preference for arms-length negotiation and implementation to collaborative involvement of the customer with the development effort.
  - mlthoughts2018 8y ago
    No, really, it would mean the term is literally vacuous, as in an actual tautology, Agile succeeds because Agile is defined to be whatever has succeeded. It’s not really possible to disagree on it.