2 ms·

I disagree. Everyone does iterative development, always, but it comes disguised as waterfall/scrumfall/kanban/whatever. The product is developed using waterfal

I disagree. Everyone does iterative development, always, but it comes disguised as waterfall/scrumfall/kanban/whatever. The product is developed using waterfall and then it gets put in front of a stakeholder, who has changed their mind in the time between the initial spec and the delivery. So another, smaller, waterfall is created. This is iterative development. And it always happens, because no-one gets product development right first time. We'd actually benefit from realising this. Which was the point of Agile - that you can change course during development and so develop the right thing through iteration. But Agile is (by definition) unpredictable. So you end up with this half-arsed solution that pretends to be predictable (except what it predicts is only the first iteration) and pretends to be Agile (except changing course is impossible) as the article says.

The_Colonel 3y ago
I think this ignores two major constraints - the "waterfall mindset" was about stakeholders (customers) believing they can get a finished product in a fixed timeline for a fixed price. What happened then was that after the delivery, the stakeholder was wildly unhappy with the result and demanded re-work, but that would be unplanned and un-budgeted. Many ugly arguments and finger pointing would ensue, which could repeat in several "iterations". The other thing which doesn't align with agile was that the stakeholder usually didn't participate in the development. They weren't reviewing the progress, they were typically waiting for the finished product to be delivered.
- marcus_holmes 3y ago
  This is what I mean. Everyone does iterative, it's just that a lot of people don't realise it's iterative so do it badly.
atoav 3y ago
Two things: 1) You can end at the first iteration and call it a day. The only reason nobody does that is because they don't benefit from an unhappy customer 2) If you have experience, nothing stops you from putting some iterations into the waterfall. As you said the need for feedback rounds should be no surprise. Traditionally the downside to waterfall was that the distance between those iterations was too big. But smaller iterations and partly prototypes is nothing that wouldn't be allowed in waterfall if you'd like to do it. And if you find a PM that doesn't do the reasonable thing "because the methodology won't allow it" they are probably a bad PM.
- xwolfi 3y ago
  For me the goal of Agile, especially in giant 100+ yo organization, is to tell people that it's less important to fit the plan than to fit the need of the external stakeholder. Who cares if 6 months ago some important managing director signed off on a useless feature nobody wants anymore: kill it now and move on, we're agile. This is literally the only way I've seen used agile in big orgs: in words only, and it's liberating: we stop spinning endlessly between useless features as the clients move on faster than us, now we can actually skip a beat and go faster, and screw the paper pushers bemoaning that "everything changes". Because yes, everything changes.

The_Colonel 3y ago

I think this ignores two major constraints - the "waterfall mindset" was about stakeholders (customers) believing they can get a finished product in a fixed timeline for a fixed price. What happened then was that after the delivery, the stakeholder was wildly unhappy with the result and demanded re-work, but that would be unplanned and un-budgeted. Many ugly arguments and finger pointing would ensue, which could repeat in several "iterations". The other thing which doesn't align with agile was that the stakeholder usually didn't participate in the development. They weren't reviewing the progress, they were typically waiting for the finished product to be delivered.

marcus_holmes 3y ago
This is what I mean. Everyone does iterative, it's just that a lot of people don't realise it's iterative so do it badly.

atoav 3y ago

Two things: 1) You can end at the first iteration and call it a day. The only reason nobody does that is because they don't benefit from an unhappy customer 2) If you have experience, nothing stops you from putting some iterations into the waterfall. As you said the need for feedback rounds should be no surprise. Traditionally the downside to waterfall was that the distance between those iterations was too big. But smaller iterations and partly prototypes is nothing that wouldn't be allowed in waterfall if you'd like to do it. And if you find a PM that doesn't do the reasonable thing "because the methodology won't allow it" they are probably a bad PM.

xwolfi 3y ago
For me the goal of Agile, especially in giant 100+ yo organization, is to tell people that it's less important to fit the plan than to fit the need of the external stakeholder. Who cares if 6 months ago some important managing director signed off on a useless feature nobody wants anymore: kill it now and move on, we're agile. This is literally the only way I've seen used agile in big orgs: in words only, and it's liberating: we stop spinning endlessly between useless features as the clients move on faster than us, now we can actually skip a beat and go faster, and screw the paper pushers bemoaning that "everything changes". Because yes, everything changes.