4 ms·

I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

prerok 6mo ago
I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
- steinsgatezero 6mo ago
  Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
  - ryandrake 6mo ago
    A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.
t43562 6mo ago
Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th." "Oh, feature no 32 is going to take months and we realised that users can just...." "No"
- magicalhippo 6mo ago
  > "You're going to do agile .... and this list of features will be ready on September 20th." Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then. We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.
  - ezekiel68 6mo ago
    It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"
    - operatingthetan 6mo ago
      In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.
      - magicalhippo 6mo ago
        That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable. This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.
    - magicalhippo 6mo ago
      Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work. If the org focuses on the customers one can work together to find a way.
  - t43562 6mo ago
    What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect. When there's a time constraint one has to be able to winnow out the real must-haves from everything else.
    - magicalhippo 6mo ago
- mytailorisrich 6mo ago
  > "You're going to do agile .... and this list of features will be ready on September 20th." That's OK, the latter is not incompatible with the former. Agile vs waterfall is orthogonal with having to commit to deadlines to deliver features.
  - t43562 6mo ago
    Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not. Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it's possible and suggesting that if they shout and stamp a bit that it will somehow rescue the situation.
    - mytailorisrich 6mo ago
      Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.
codeduck 6mo ago
Ah yes, the old Agile-as-drunken-waterfall pattern
mpweiher 6mo ago
In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings. It's a farce.

prerok 6mo ago

I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.

steinsgatezero 6mo ago
Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
- ryandrake 6mo ago
  A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.

t43562 6mo ago

Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th." "Oh, feature no 32 is going to take months and we realised that users can just...." "No"

magicalhippo 6mo ago
> "You're going to do agile .... and this list of features will be ready on September 20th." Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then. We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.
- ezekiel68 6mo ago
  It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"
  - operatingthetan 6mo ago
    In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.
    - magicalhippo 6mo ago
      That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable. This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.
  - magicalhippo 6mo ago
    Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work. If the org focuses on the customers one can work together to find a way.
- t43562 6mo ago
  What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect. When there's a time constraint one has to be able to winnow out the real must-haves from everything else.
  - magicalhippo 6mo ago
mytailorisrich 6mo ago
> "You're going to do agile .... and this list of features will be ready on September 20th." That's OK, the latter is not incompatible with the former. Agile vs waterfall is orthogonal with having to commit to deadlines to deliver features.
- t43562 6mo ago
  Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not. Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it's possible and suggesting that if they shout and stamp a bit that it will somehow rescue the situation.
  - mytailorisrich 6mo ago
    Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.

codeduck 6mo ago

Ah yes, the old Agile-as-drunken-waterfall pattern

mpweiher 6mo ago

In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings. It's a farce.