one former employer purportedly did agile but it was a top-down autocracy, which is completely incompatible with agile. (i was ostensibly a product owner, but the CEO set our development priorities with only superficial consideration for customer feedback.)
you cannot both dictate and empower at the same time, and empowerment (via agile) is typically the loser in that fight.
that's how i see agile "failing" most often, before it even has a chance.
Agile is a culture about project management methodologies, which unfortunately is extremely resistant to actually adopting methodology that reflects it's overt cultural values. Largely, IMO, this is because the agile community has been very bad at operationalizing the “over” statements in the Manifesto into mechanisms by which the right side items are subordinated to the left side items. This results in (for the first statement in the Manifesto) either dysfunctional interaction and demotivated people from constant conflict resulting from the absence of processes and tools, or the adoption processes and tools in a manner which does not respect people and interactions, merely because someone has labelled the tools “Agile”.
There is no perfect, but one that is fragile to external business realities is probably worse than one that is resilient to it.
(In my company, the problem with agile was that the sales people would insist on always adding some extra tool for a fixed price. We had no choice but to abandon agile.)
What does that have to do with agile? That seems to be a problem that would occur, and be problematic, independent of development methodology.
> We had no choice but to abandon agile.
Seems to me you should have abandoned the offending sales people.
agile seeks to benefit from the intrinsic motivation of each team member to create something beyond any single member’s capabilities in exchange for empowerment.
when a manager doesn’t understand this principle, that leads to failure (as in your case as well). i don’t know of any systems that can self-correct for this kind of external mis-judgement.
I mean... there's no correct application of waterfall. The whole waterfall process comes from a paper as an example of how not to run an engineering project.
It's only for not well understood problems that it fails so completely. In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall.
However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems.
The same is true for many other real life "waterfall" processes, like buildings, or bridges.
Or if the problem is that well-understood, there's an off-the-shelf solution so good nobody seriously thinks about re-implementing it.
> However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems.
Exactly. That's barely software development. That's using fully-commoditized components in well-understood fashions to achieve a well-understood goal.
You could script that. I'm sure some places have.
Source: was a commercial interiors contractor before I was a software engineer.
The most well defined piece of software I know of, sel4, had a full machine checkable formal proof up front, and they still ran into issues during implementation that required them to go back and modify the spec.
Our industry being rather foolish, people read the paper and thought, 'hey, this sounds like a good idea!'
It's not my fault that it appears you've been using the term wrong. Waterfall with feedback ceases to be waterfall.
I don't think it really has anything to do with gravity.
That is a very strange thing to say considering that the method comes from "real" branches of engineering (mech, civil, electrical, etc) and you can simply look around you at your built environment to know that it has delivered an awful lot of real, actual stuff. They didn't agile up the building you're sitting in or the roads that lead to it or power station that makes it work or any of the things in it.
Waterfall as far as software is concerned has its origins in a paper from Winston W. Royce and not an unguided adoption of mech/civil/electrical engineering principles: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
Do you know where I'm sitting?
The same thing goes on with OOP. It started out as a good addition to other programming styles, got turned into a religion ("you can't do this. It's not OOP.") and now into a pariah (FP is next to go through this cycle).
In the end stupid people will mess up anything they touch and good people will adapt things until they work.