4 ms·

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

by 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.
    - AussieWog93 4y ago
      This is something I've come across in my own experience. If you don't actually have any experience in the problem space, the best thing you can do is make something that just barely works, then scrap it. Then all the unknown unknowns become known unknowns and you can actually create good solutions to it. All planning is a waste if you don't even know where the speed humps will lie.
      - brigandish 4y ago
        It's basically a variation of Chesterton's fence[1]. There's a lot of hubris in thinking one could write a piece of code better than someone else if one has never attempted to write that piece of code, especially when never even having done anything like it at all. [1] https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterton's_fence https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterto...
        _0ffh 4y ago
        Yeah, like to do the job properly you need someone who's done the same job before. Become that someone by exploratorily building the thing you want to build before you seriously build it.
      - Dudeman112 4y ago
        >All planning is a waste if you don't even know where the speed humps will lie. If that's the place where someone is, they should be conferring with someone else who knows something instead of trying to fly solo Blindly going through problem spaces is how you waste your life taking wrong approaches
    - HWR_14 4y ago
      It depends on why you throw the work away. If it's because of issues that should have been apparent with minimal planning, it's disheartening. Obviously, throwing away work is important in general. But consider a project to do taxes that gets thrown away because legal says it's a law taxes be done by hand, that an accountant said used the wrong tax code or that marketing comes back and says it has to be a desktop app. If that doesn't kill your morale, I don't know what to say. Meanwhile, by all means discover that no one likes typing numbers on a phone so you have to refocus on taking pictures of receipts and wage stubs and text recognizing them.
      - vanviegen 4y ago
        Creating the 'typing numbers on a phone' version of the app is relatively trivial, so probably worth doing first. You only want to do the AI version if you're really sure that you need it, or you can afford it and it doesn't delay more important things.
        HWR_14 4y ago
        I think you are focusing too much on the example, which was chosen to try to explain my point. Obviously it has to be a simple problem with simple issues to be easily discussed in a public forum.
      - TameAntelope 4y ago
        If you worked on a project for any amount of time that wasn’t put in front of users (who would catch obvious mistakes like what you describe), you aren’t taking your job seriously and have bigger problems than feeling bad about throwing away code.
        HWR_14 4y ago
        The point here is that programmers are assigned tasks, do them, and the management (whose job is to put it in front of users) is failing at that leading to wasted efforts. Although I should point out that 2/3 of the examples would not have been caught by a user, because they are compliance related.
- 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.

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.
  - AussieWog93 4y ago
    This is something I've come across in my own experience. If you don't actually have any experience in the problem space, the best thing you can do is make something that just barely works, then scrap it. Then all the unknown unknowns become known unknowns and you can actually create good solutions to it. All planning is a waste if you don't even know where the speed humps will lie.
    - brigandish 4y ago
      It's basically a variation of Chesterton's fence[1]. There's a lot of hubris in thinking one could write a piece of code better than someone else if one has never attempted to write that piece of code, especially when never even having done anything like it at all. [1] https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterton's_fence https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterto...
      - _0ffh 4y ago
        Yeah, like to do the job properly you need someone who's done the same job before. Become that someone by exploratorily building the thing you want to build before you seriously build it.
    - Dudeman112 4y ago
      >All planning is a waste if you don't even know where the speed humps will lie. If that's the place where someone is, they should be conferring with someone else who knows something instead of trying to fly solo Blindly going through problem spaces is how you waste your life taking wrong approaches
  - HWR_14 4y ago
    It depends on why you throw the work away. If it's because of issues that should have been apparent with minimal planning, it's disheartening. Obviously, throwing away work is important in general. But consider a project to do taxes that gets thrown away because legal says it's a law taxes be done by hand, that an accountant said used the wrong tax code or that marketing comes back and says it has to be a desktop app. If that doesn't kill your morale, I don't know what to say. Meanwhile, by all means discover that no one likes typing numbers on a phone so you have to refocus on taking pictures of receipts and wage stubs and text recognizing them.
    - vanviegen 4y ago
      Creating the 'typing numbers on a phone' version of the app is relatively trivial, so probably worth doing first. You only want to do the AI version if you're really sure that you need it, or you can afford it and it doesn't delay more important things.
      - HWR_14 4y ago
        I think you are focusing too much on the example, which was chosen to try to explain my point. Obviously it has to be a simple problem with simple issues to be easily discussed in a public forum.
    - TameAntelope 4y ago
      If you worked on a project for any amount of time that wasn’t put in front of users (who would catch obvious mistakes like what you describe), you aren’t taking your job seriously and have bigger problems than feeling bad about throwing away code.
      - HWR_14 4y ago
        The point here is that programmers are assigned tasks, do them, and the management (whose job is to put it in front of users) is failing at that leading to wasted efforts. Although I should point out that 2/3 of the examples would not have been caught by a user, because they are compliance related.
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.