Very loosely, "product dev" projects have concrete deliverables, deadlines, and high cost of change (updates). So therefore are ameniable to PMI-ish critical path like methodologies. (Avoiding the evergreen unresolvable sophistry wrt "waterfall".)
The original motivation for "agile" was to protect the dev team from terrible customers (clients). Those who cannot or will not commit to requirements, actively resist any kind of formalism, have no clue what "done" even means.
Meaning most IT (data processing) efforts. And now most web stuff.
"Agile" is totally rational in those unwinnable situations. Because the dev team would always have something to show for their suffering. Lessening the likelihood of being the scapegoat come the inevitable failure.
Unfortunately, "agile" became a fad, a belief system, an identity. Curtailing any kind of introspection. Only in the last few years have we been able to have calm, frank discussions about "agile". Mostly because some of its progenators have broken ranks and done mea culpas.
> Very loosely, "product dev" projects have concrete deliverables, deadlines, and high cost of change (updates).
Why? A web based product can iterate, for example. We see the most experimentation in places like Amazon, where they're constantly deploying updates and experiments. Why should such a product have a high cost of change?
Back when we burned CD-ROMs, distributing updates like bug fixes involved non-trivial effort.
Today, libs/packages and apps are somewhere between "agile" and PMI.
FWIW, for web stuff, I'm very interested in "test into prod" methodology. Neither agile or critical path; its something new. First popularized by the gilt.com fella (IIRC). But haven't yet found any teams (to join) that bold.
But you can still evolve APIs; breaking changes can occur much less than normal changes. And even then you can version them and run old and new in parallel if you want. I don't see why that would be slow.
I also don't see why making things in a way that's hard to change suddenly makes something amenable to agile.
I have never advocated for "agile", for any purpose. Ironically, IMHO "agile" is silly make work (ceremony) and too heavy weight. I was just trying to steelman the original justification for "agile" methods.
The PMI based processes my prior teams used had minimal communication and project mgmt overhead and very little drama. I see no reason why IT / web projects shouldn't be similarly managed. It's just that PMI is now like a lost art.
I only mentioned "test into prod" because I'm very curious about its methodology innovations. I think it would have better modeled and explained some of my prior experiences.
For instance, one of my teams would live code and then commit to prod changes while we were talking with our customers (for immediate verification and so forth). Almost zero overhead or ceremony.
We just came up with that system intuitively and couldn't really explain ourselves to others. (We had one senior VP in particular who reacted very negatively to our processes.) If we had the "test into prod" narrative, maybe things would have gone better.
Very loosely, "product dev" projects have concrete deliverables, deadlines, and high cost of change (updates). So therefore are ameniable to PMI-ish critical path like methodologies. (Avoiding the evergreen unresolvable sophistry wrt "waterfall".)
The original motivation for "agile" was to protect the dev team from terrible customers (clients). Those who cannot or will not commit to requirements, actively resist any kind of formalism, have no clue what "done" even means.
Meaning most IT (data processing) efforts. And now most web stuff.
"Agile" is totally rational in those unwinnable situations. Because the dev team would always have something to show for their suffering. Lessening the likelihood of being the scapegoat come the inevitable failure.
Unfortunately, "agile" became a fad, a belief system, an identity. Curtailing any kind of introspection. Only in the last few years have we been able to have calm, frank discussions about "agile". Mostly because some of its progenators have broken ranks and done mea culpas.