So, since I started my first internship (2012) I've been warned against the dark-lord cascade. Agile is our salvation to evil. Any who dares to question this will be burn at the stake.
The funny thing is that I have never try cascade. I've been told to avoid it... but that's all.
I'm wondering if we - the dev community - will come back to cascade strategy, once agile evangelists retire. WDYT?
Top comments (5)
I think it rather depends on the project itself. I doubt they build space rockets using a trial and error agile methodology. On the other end of the spectrum, when you don't exactly know what your audience exactly wants, quick iterations, prototypes and feedback are great. Such "not clearly outlined" projects are fairly typical in IT. However, if something rather big, involving several teams is built, the sudden changes and short cycles typical to agile methodology become drawbacks. All the devs will just cringe their teeth and shout "What, the other teams APIs/components/modules changed again?! Duh, we have to change everything too! This lack of proper planning makes so much work go down the drain!". Agile is also a vague term. Many people interpret it differently. Although I agree to it's original principles in the manifesto, it kind of evolved on it's own. Sometimes, it's more like navigating on sight vs planning the path beforehand. Also, it's rarely purely agile or purely cascade, but often somewhere in between.
about this:
Actually I think I've never applied (those same agile concepts) the same way through different teams/companies. Agree
Somewhere in between. We really have poor memory in technology field so the tendency is to go back and forth with what we learn and unlearn.
Take a processs framework that evolved from waterfall, for example and added the good parts of "agile" and extreme practices: RUP. In practice, what you have in RUP is iterations, at the end of which you get a "releaseable" increment of a product/system/solution. And in each of these iterations you do a little bit/refine everything by doind a little bit of all the disciplines that are part of the sdlc (requirements, analysis, design, code, testing). Sounds like anything you heard of ? It's been around since around the 2000s btw, and I remember it whenever someone complains about not having enough design, or requirement details during scrum sprints.
I endorse this:
my point is:
I've been warned, but since I think I haven't suffered it on my skin (I think), maybe we endup coming back to it