• @[email protected]
    link
    fedilink
    10
    edit-2
    13 days ago

    Agile strikes me as … the same thing as everything else: Good until it’s mis-applied, usually by taking it to an extreme…

    Much like how Object Oriented Programming gets flak from some, Agile has many ways to abuse the concept. That does NOT make it a bad idea over all, it just means it’s not a magic silver bullet.

    Hint: There are no silver bullets. Let alone magic silver bullets.

    • @[email protected]
      link
      fedilink
      English
      212 days ago

      One of the bullet points of agile as I understand it is “do less documentation”. My previous boss was big on agile, and we were already barely documenting anything, so…

      • @[email protected]
        link
        fedilink
        212 days ago

        Yea… That’s definitely one of the dumber points of Agile. Only wise if you’re writjng too much as is.

        • @[email protected]
          link
          fedilink
          English
          212 days ago

          That was my assumption, too. He also liked to seize on the idea that every sprint must produce something useable… Which I take to mean “give your client something to poke at and test, not a diagram” and he took to mean “every sprint must produce something useful to the client, that they can immediately put into production”.

          • @[email protected]
            link
            fedilink
            212 days ago

            I mean, where else is a customer going to poke at a new feature but production? Can save even more time by doing all the testing there! Such a wise manager …

      • @[email protected]
        link
        fedilink
        1
        edit-2
        12 days ago

        Well that part can be totally fine. It is absolutely in no way what so ever an indication of something fishy if they’re giving the data and procedure they computed the number with.

        Statistics can and often do produce specific numbers. Who knew!?

    • @[email protected]
      link
      fedilink
      12
      edit-2
      13 days ago

      What percentage of places that claim to be agile have even a single decision maker that has read the agile manifesto?

      I’m going to say, generously, 3%.

      • clif
        link
        fedilink
        913 days ago

        I like to tell new hires : “we claim to do agile but we really don’t… Like everybody else”

        • @[email protected]
          link
          fedilink
          5
          edit-2
          13 days ago

          I actually don’t think I disagree with you in principle. I had the chance to talk shop with Kent Beck, and honestly, I don’t think he would either.

          Honestly, I can sum it up pretty succinctly:

          “Use some common fucking sense”

          I don’t think you should HAVE to read that. But, I’m routinely disappointed.

          So, I love the Agile Manifesto, because instead of saying “Use your fucking head” to my managers who claim to be agile, I can much more diplomatically say “What does the agile manifesto say about that?”

  • AutoTL;DRB
    link
    fedilink
    English
    413 days ago

    This is the best summary I could come up with:


    Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it’s cracked up to be.

    One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.

    “Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.”

    A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

    One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”

    In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.


    The original article contains 501 words, the summary contains 175 words. Saved 65%. I’m a bot and I’m open source!

  • @CancerMancer
    link
    412 days ago

    They say knowing the requirements before you start loads to a higher chance of success. Agile projects are more likely to fail because you’re more likely to use Agile when you don’t have a clear map of the requirements and want to be able to pivot quickly. Working as intended I would think.

    All that is assuming your shop actually knows what Agile means and isn’t just doing Waterfall with stand-ups.

    • @[email protected]
      link
      fedilink
      2
      edit-2
      12 days ago

      Yeah they seem to be implying that the “opposite” of agile is getting a good set of requirements, which is… optimistic.

  • Scratch
    link
    English
    212 days ago

    Right. Because you start early, get an mvp into market and see what works. If nothing works, you should have spent the bare minimum time and money getting there. But if it succeeds, you are there long before waterfall. Collecting market share and metrics.

    That’s the dream, at least.

  • @[email protected]
    link
    fedilink
    012 days ago

    “One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.”

    I want to know the specifics of how we got to the point where the statement above needs studies to validate it and how this has become news for anyone.

  • @Paragone
    link
    -18 days ago

    As the real gurus of Agile point-out,

    most of the nuveau methods/processes were ideological,

    but agile had engineering-requirements, too ( test-1st develoopment, e.g. )

    Which makes it much superior to all the ideology-but-no-engineering-hardening methods.


    As they also pointed-out, you NEED disciplined individuals & teams to make it work.

    IF you don’t have effective & driven-by-quality/integrity-of-work teams, agile isn’t the right method for you.


    I’d go further:

    I’d say that both waterfall & agile ( Wysocki’s book on project-management identifies that Traditional is the poorest match for reality, Agile’s best, & Extreme is research whereas Emertxe is where you’ve got a solution, but don’t know what it’s for, yet ( like Post-it notes glue, before sticky-notes were invented ) )

    both waterfall & agile are mis-apprehensions of what’s required.

    Until you understand the required architecture, you can’t make the right architecture-choices, right?

    So, why not make a prototype agilely, until one has a proper domain-model, an executable toy-prototype which demonstrates all the key functions, & then when you’ve got the working, executable model, then you understand the architecture required, and only then do you switch from agile-prototyping to building-out the real, hardened thing…

    Just seems sane, to me, but I’m just some idiot with a bit of thinking, not a working … anything, really.