[Ensorceled]

Red Flag #6: Key stake holders keep moving the goal posts.

If your goal moves from feature comparable but on a modern platform, to new features, to a complete reinventing of the product all without actually shipping ... you might be in trouble.

I had a rebuild go 6 months over. In the heated executive meeting at t+3 months I was called to defend my team and pointed out that the VP Product had just delivered “final” specs literally the day before. How could we be on track with development if PM is 3 months past “end of development” with design specifications. The fact that the specs were changing weekly because “we’re agile” is a whole other issue.

[whatshisface]

People sometimes complain about how developers like to "write the operating system and then a language" when it comes to handling every foreseeable permutation of what the program might every be desired to do, but we're all so used to unstable requirements that sometimes the metaphorical programming language research is the only thing that will be general enough to find a use next week.

[oneplane]

I almost had a few similar situations, but after pointing out that being agile doesn't just means changing requirements but also changing time paths or simply different deliveries after each change it got a whole lot clear what agile (and scrum) is good for, and what it's not good for (i.e. agile process but expecting waterfall results doesn't work).

[Cthulhu_]

> The fact that the specs were changing weekly because “we’re agile” is a whole other issue.

The article touches on that too; simplified it's stating that if you're not live within 6 months, you're doing waterfall.

[Ensorceled]

That’s not waterfall. Waterfall you don’t start dev before specs are final.

Waterfall isn’t just a synonym for “the wrong way to do it” :-)