4 ms·

Agreed, and while it's become fashionable to trash on "agile", this sort of thing is why I still prefer it to alternatives. Basically "what do you want next?".

• illuminati1911 4y ago
  Problem is not the agile, but useless sinecure managers trying to rebrand "agile" as something in which projects don't need planning, can be completely chaotic and any requirements can be changed at anytime without affecting the deadline. "Hey we don't really need to make any decision ever or even know what we are doing. That's the great thing about agile!"
  • TameAntelope 4y ago
    Projects tend to need substantially less planning than people think.
    • justin_oaks 4y ago
      The joke at my previous job was "Months of development can save days of planning." The management in the company didn't plan anything and the meandering development process showed it. Please don't underplan. It's awful for morale to throw away work because of bad planning.
      • TameAntelope 4y ago
        Being willing to throw away work is the single most effective way I've seen at running an engineering org, both in terms of promoting innovation and in being able to quickly adapt to evolving customer needs as they get revealed. If your morale is harmed by throwing away work, that's something you should work on.
        • danielmarkbruce 4y ago
          At google it was repeated that Sergey Brin used to say "all work is throwaway work, it's only the time horizon which is in question".
          • cwillu 4y ago
            It's kind trite to say “much is explained”, but… that explains so much about google.
            • danielmarkbruce 4y ago
              It doesn't really. There is plenty of old code at google, he was just saying it to people who were too scared of doing work they might need to throw away. The promotion process explains way more of what I think you are getting at.
            • ratww 4y ago
              Throwing away code and throwing away products/features are completely different things, and only one of those is a real problem for end users.
        • gautamdivgi 4y ago
          It depends at which level you're at. If you're working at an infrastructure or firmware level, throwaway work can be expensive and time consuming. Re-architecture can also be time consuming. There are some parts you have to spend design cycles on, especially if you're doing a large project. It's not that you can't pivot, but the pivot takes a lot of time. At the very least have a set of System Features and System Guarantees that you will drive towards.
          • varjag 4y ago
            With embedded development it's entirely fine to iterate fast and throw away work, until the product is shipped. And in certain applications it is fine even after it is shipped.
        • 4y ago
    • illuminati1911 4y ago
      True, but usually in this kind of situations it's either zero planning or way too much planning and often the planning is also "wrong kind of" planning.
    • Spooky23 4y ago
      “Shit, the Oracle costs 10x more than the bullshit number we budgeted. Next sprint, refactor to SQLite.”
  • Spivak 4y ago
    > without affecting the deadline This might be a controversial take but if you have an actual deadline -- "product must cross the threshold of not shippable to shippable" as opposed to a cutoff date "product is at all times shippable but we need a date to say we're done refining" then agile is probably not the way to go. I've always structured projects like this as waterfall to your MVP then switch to agile. You have to get your PMs to agree to an (externally) unchanging design and feature set until you have something working to talk about and then you can ask what they want next. Even without a deadline I still try to follow this model but define the "MVP" as a "hello world" app but with functioning prod-ready infrastructure and ci/cd. So then I can go to the design meeting and say, "I have a blank canvas, what do you want on it?"
    • gedy 4y ago
      Yes that's fine if the company can determine what they want before setting dates, or asking for "estimates" (date commitments). Though the OP was talking about worse case of: date set, product/ux/etc continues (or starts) planning, eating well into deadline.
  • spaetzleesser 4y ago
    I think the dream is "get precise estimate without defined requirements". Also "an estimate is a commitment"
  • ngc248 4y ago
    Exactly ... I call that the frAgile methodology and managers seem to love that.
  • himinlomax 4y ago
    If what you're doing is a "project," then by definition it can't be agile. Agile is for products.