That's the point; he's arguing that WMF engineering practices are so disorganized that not only don't they qualify as agile, they don't even qualify as waterfall (which predates agile by several decades).
Waterfall methodologies are deeply un-hip today, of course, but when they first coalesced they were a big improvement over what came before them, which was essentially nothing: an absence of any formal project management methodologies, with people cobbling together projects from bits and pieces of expertise learned in other disciplines.
(Note that I have no idea how WMF's software engineering practices work, so I have no idea if this assertion is accurate or not. I'm just trying to clarify what I think Macon is arguing here.)
You are correct. I am arguing that WMF engineering practices are so disorganized that not only don't they qualify as agile, they don't even qualify as waterfall (which predates agile by several decades). In particular, I am part of the community of Wikipedia editors. Nobody asked us what flow or Knowledge Engine should look like. That's part of Waterfall AND Agile. Yes a dedicated person can go to the developer's separate Wiki and mailing lists, but on Wikipedia itself there is zero evidence that the principles I see at [ http://agilemanifesto.org/principles.html ] are in play.
Again, the developers and their managers know this. I am convinced that they have been told in no uncertain terms that they will be fired if they interact with the Wikipedia community.
It's hilarious. It has only existed as a thing to critcize, and the term itself actually originates in a paper describing why it's broken. No one has ever advocated for the "waterfall" approach.
> and the term itself actually originates in a paper describing why it's broken.
So does the term "capitalism". Like capitalism, though, the waterfall method was a thing actually in wide use both before (the first paper describing it's use was about 20 years earlier than the critical one in which the term seems to have been first used) and after (it's been mandated by many institutions, particularly in government, even after that critical paper) being names in criticism.
> No one has ever advocated for the "waterfall" approach.
Actually, a number of large organizations, particularly governments, to this day mandate processes for software development projects, particularly large projects, that embody essentially the key features of the waterfall method, most critically that of doing full analysis across the whole scope before beginning development (often, in government, before getting approval for funding to open up contracting for the actual development work.) A lot of the contractors involved advertise that they use agile methods, but it ends often up being a kind of Scrum-within-waterfall monstrosity that managed to preserve the worst features of both.
Point me to someone espousing the benefits of the waterfall approach, please.
> So does the term "capitalism". Like capitalism, though, the waterfall method was a thing actually in wide use both before (the first paper describing it's use was about 20 years earlier than the critical one in which the term seems to have been first used) and after (it's been mandated by many institutions, particularly in government, even after that critical paper) being names in criticism.
I'm not saying that no one has ever tried building software this way. But the term and "methodology" are literally the collection of broken processes associated with early development.
> Actually, a number of large organizations, particularly governments, to this day mandate processes for software development projects, particularly large projects, that embody essentially the key features of the waterfall method, most critically that of doing full analysis across the whole scope before beginning development (often, in government, before getting approval for funding to open up contracting for the actual development work.)
How do you go to tender without reasonable complete requirements?
The problem here isn't the development methodology, it's the fact that going to tender for development basically forces you into this position. Governments seem to be moving to in house development to solve this problem, but I'd hardly say that the original requirements gathering was the result of anyone advocating for the waterfall approach.
Waterfall methodologies are deeply un-hip today, of course, but when they first coalesced they were a big improvement over what came before them, which was essentially nothing: an absence of any formal project management methodologies, with people cobbling together projects from bits and pieces of expertise learned in other disciplines.
(Note that I have no idea how WMF's software engineering practices work, so I have no idea if this assertion is accurate or not. I'm just trying to clarify what I think Macon is arguing here.)