1. 4
  1.  

  2. 12

    No! Every new sprint is a mini waterfall and the stakeholders secretly still treat your sprints as grant tasks.

    1. 1

      What is a grant task?

      1. 2

        I have a feeling “grant” was meant to be Gantt.

        1. 1

          Yeap, it was a typo - sorry about that.

    2. 9

      I haven’t deeply researched the history of project methodologies, but I’d be unsurprised if the belief that “all we did was waterfall until Agile came along” isn’t true. Pretty much every OOP book I’ve read from like 1980-1995 talks about how it works with an “Incremental model”, where you deliver short term wins continuously and constantly reevaluate customer requirements.

      1. 9

        You might find this thread helpful. Turns out iterative development was the norm, waterfall was an illustration of what wasn’t done, and one guy used that to con folks for money on top of DOD’s top-down management. Then, the world changed for the worst. That’s the story so far.

        1. 4

          Nothing I’ve read from programming books since the 1970s suggests that Waterfall was “the way” that software was developed. I’ve also not researched this deeply, but I don’t think Waterfall was ever taken seriously. Everything I read talks about the importance of testing intertwined with implementation, in some form, when developing software. Furthermore, there was always talk of iteration to get APIs to be better. The key difference from the early days is that those cycles were longer, which gives the appearance of Waterfall in action.

          1. 3

            I think our understanding of classical engineering is partially shaped by the agile industrial complex.

            Nowadays if you attend a Scrum training somewhere you get a trainer who typically never worked in a classical engineering project. Yet they have learned the story that classical engineering was waterfall and that no project was succesful ever and that every developer suffered. So they perpetuate this story. Since they don’t know stuff, they just randomly talk about waterfall/classical methods/v-model as if they were all the same. This portrayal of classical methods has shaped our mental model so much, that it also shaped how classical engineering is implemented.

            I have an older colleague who always dies a little every time a 30-something agile consultant starts lecturing people on the perils of classical engineering and the gospel of agility. “If the V-Model was waterfall, it would be the ’'-Model”.

            Bertrand Meyers article I also found interesting on this http://se.ethz.ch/~meyer/publications/methodology/agile_software.pdf . Especially his defense of requirements documents IIRC.

            Maybe this is a general thing to remark about adoption of ideas here. It is always a good idea to read and study the primary and early sources for ideas. Quite often, ideas deteriorate while they are adopted. Most material on user stories is a very shallow remainder of the ideas that Cohn wrote down in the 2000s in his book. The same goes for the original “waterfall paper”, the agile manifesto, even the scrum guide (ever realized it does not mention agile once, it does not mention story once?). I’d be actually curious about historic, alternative frameworks/processes that were created at the same time but that were not widely adopted and have silently vanished. I think a lot of wisdom could be found.

            1. 2

              Do requirements documents need to be defended?

              If you have no requirements document, how do you know when you’ve fulfilled your contractual obligations?

              1. 1

                You probably don’t have contractual obligations. You’re probably building internal software and the requirements could change for those on some sprint-like basis. And that’s okay.

                Essentially you just have a tight iteration loop and all is well.

                1. 1

                  Well, many agile consultants will tell you they are the devil and not agile. (They are not agile if you set requirements in stone at some point). When in fact, user stories (advocated as the alternative) are just a different flavour of requirement engineering.

                  Personally I think writing a large requirements document upfront might be a bit risky if you already fear that your project is based on risky assumptions. On the other hand in the Scrum-hamster wheel, it is sometimes hard for the team and the PO to think for a bit and come up with a better solution than the lowest hanging fruit.

                  I have bad experience with requirements documents when customers commissioned software development, because often they were too detailed and kind of outlined problems the user didn’t have. Then I would have favoured a more agile approach.

                  In SaaS contexts, I would have loved to have a well-maintained requirements document at times, especially when parts of the system were rewritten or exchanged

            2. 2

              From the picture of the process of Agile in the article, I see: Design, Develop, Test, Deploy. But where is verification? Poof, gone.

              Typically I say that there are two kinds of validation (“does the software posses certain qualities?”): testing and verification. The former is established empirically (user tests, examples, etc.) the latter established mathematically (through proof and reasoning).

              Testing essentially establishes that software has the intended functionality; after succesful testing, there should not be any confusion over what the software does, i.e. no misunderstanding over that the software provides certain functionality.

              Verification essentially explores unknown consequences, not foreseen by testing. But only by rigorous argumentation, one can explore all possibilities in which problems may lie hidden. After succesful verification, there should not be any junk in the software, i.e. no unexpected behaviors.

              Both phases provide essential information for clear and consise documentation.

              Agile vs waterfal discussions seem to attack a strawman, while not providing any useful information to conmplete the verification phase.

            3. 3

              No. People just adjusted “agile” to mean whatever they want it to mean, and now you have to ask how the whole process works when interviewing a company which says it follows “agile” processes.

              This isn’t necessarily the fault of the people doing this, of course, but more-so the fault of agile being so poorly defined without excessive research that it is often misunderstood.

              1. 1

                I’ve heard the term “agile-lite” thrown around, which as best I can tell, is a euphemism for “not agile at all”.

                1. 1

                  To be fair, “agile” is a euphemism for that as well nowdays :D :D

              2. 2

                I haven’t deeply researched the history of project methodologies, but I’d be unsurprised if the belief that “all we did was waterfall until Agile came along” isn’t true. Pretty much every OOP book I’ve read from like 1980-1995 talks about how it works with an “Incremental model”, where you deliver short term wins continuously and constantly reevaluate customer requirements.

                1. 1

                  This article cites some interesting trends. I need to read a bit more carefully to see where they’re getting their data.