3 ms·

Its problematic that Waterfall/Agile stuff regularly gets upvoted to the front page, and then the majority of commenters don't seem to read the article before p

by fergie 8y ago

Its problematic that Waterfall/Agile stuff regularly gets upvoted to the front page, and then the majority of commenters don't seem to read the article before posting some tangentially related anecdotes on the vague topic of "Agile". This article is making the point that a "Waterfall Method" has never actually been proposed by academia, so it is incorrect to speak about an Agile/Waterfall dichotomy. In other words: The Waterfall Methodology is not a thing and only seems to be used as a "straw man" foil. Personally I think we should also be a little more critical about who defines "Agile", how it differs from common sense, and what research has actually been done on it, but thats another matter.

jillesvangurp 8y ago
I would at this point argue agile is the new waterfall. It's so common that the phrase "we're doing agile" vaguely hints at a few practices that may or may not be relevant to the discussion. Mostly it means "we have standups" and "we promoted some juniors to scrum master and pm roles". It's mostly devolved to ritualistic bullshit performed dogmatically by corporate idiots. Every shitty third rate software sweat shop does agile/scrum these days. You need to look pretty hard to find companies that are not very eagerly proclaiming they do agile.It means absolutely nothing until you qualify what that actually means for you. Those claiming they are doing it "right" or by the book are the worst because that means they read some stuff without grasping the meaning of what they read. Basically, the agile manifesto signers have come out arguing against that. That was the whole point of that manifesto. They basically provided us with tools, practices, and ways of working that we're supposed to adapt to our context as needed. They don't say: do this dogmatically and follow my instructions by the letter. They actually say don't do that but if you are getting started you might as well do this and then adapt as needed. That's sort of the same thing that went wrong with waterfall. The article points out a few historical twists to historical context of that. I read the paper by Royce long time ago and found it to be quite modern and insightful. It doesn't mention waterfalls at all (as the article points out). It also points out that, waterfall as we know and love it, basically was institutionalized bureaucratic government organizations using it to sugar coat heavy processes that they came up with that got subsequently adopted as "the way to do things" by equally bureaucratic large software houses they worked with. It got a bad reputation for said corporations making obscene amounts of money with obscenely bad software delivered late and never on budget. This pattern is something that is a constant and was referred to as the software crisis in the 1960s already and lead to Margaret Hamilton along with other famous pioneers in computing coining the notion of software engineering in the 1970s. She was of course working on the lunar program at Nasa (speaking of bureaucratic organizations). The software crisis is alive and kicking. Many scrum/agile organizations continue to peddle atrociously bad software developed. That doesn't mean that nothing has changed but you should beware of anyone claiming to know the one and only way to do stuff. There's a lot of common sense that inspired agile and waterfall. I'd argue the modern take on this is to replace manual processes with automation to facilitate rapid flow of changes from inception to production. Another trend is to decouple decision points to facilitate asynchronous processes and communication. For example, you don't bundle features into releases. Instead you ship pull requests straight to CI and CD pipelines. That means that there are no central planning bottlenecks for delivering new features and they can be developed on their own schedules. This happens continually. Most big brand websites you use, update many times per day. Iterations and sprints are kind of obsolete as a way of orchestrating release schedules. That practice is now creeping into the enterprise. If you are doing scrum and being told not to do this, that's something that you need to challenge.
sonnyblarney 8y ago
"The Waterfall Methodology is not a thing and only seems to be used as a "straw man" foil." Waterfall is a 'thing' because it existed long before software or computers. I view it as essentially the most obvious form of project management, which is simply a phased approach to solving a problem: gather requirements, plan, design, do, test, fix problems etc..
- acdha 8y ago
  I think that’s the core problem, too: it works fine for well-defined needs in mature categories — things like buying printers or renting office space, where all of the options are usually capable of doing the job to at least a basic level. Large organizations have tons of experience muddling through that process and it’s tempting to think that software is similar, especially because many vendors are will to perjure themselves saying so. The problem was accepting that custom software doesn’t work in the same way and reconciling the huge differences in how much customization people request versus what they are willing to pay.
mmsimanga 8y ago
The word Agile has become so loaded that if you want to side track a meeting just mention you will be using Agile. Nothing else of value will be discussed in the meeting because people will either vigorously object, support it or argue on what exactly is Agile. This brings me to your statement: > Agile, how it differs from common sense Thank you for mentioning common sense. No one size fits all. I have never followed one methodology to the absolute T. I borrow from all the methodologies I have read about. I use KanBan boards I learnt about at a Agile workshop but don't have daily scrum meetings. I have SLDC like development plans but never hesistate to meet clients to seek clarity when needed or even to show them what I have done. Sometimes I show them final product at the end of the implementation because it can confuse clients to show them a half finished product. Sometimes it is possible to show a half finished product. I must confess I haven't read the article but had to post about Agile :-).
randomdata 8y ago
It is but a symptom of the real problem of organizations blindly adopting 'Agile' out of no more than a desire to stay trendy and the developers taking an interest in the subject out of seeing that the move is an abject failure more often than not.

by fergie 8y ago

jillesvangurp 8y ago

I would at this point argue agile is the new waterfall. It's so common that the phrase "we're doing agile" vaguely hints at a few practices that may or may not be relevant to the discussion. Mostly it means "we have standups" and "we promoted some juniors to scrum master and pm roles". It's mostly devolved to ritualistic bullshit performed dogmatically by corporate idiots. Every shitty third rate software sweat shop does agile/scrum these days. You need to look pretty hard to find companies that are not very eagerly proclaiming they do agile.It means absolutely nothing until you qualify what that actually means for you. Those claiming they are doing it "right" or by the book are the worst because that means they read some stuff without grasping the meaning of what they read. Basically, the agile manifesto signers have come out arguing against that. That was the whole point of that manifesto. They basically provided us with tools, practices, and ways of working that we're supposed to adapt to our context as needed. They don't say: do this dogmatically and follow my instructions by the letter. They actually say don't do that but if you are getting started you might as well do this and then adapt as needed. That's sort of the same thing that went wrong with waterfall. The article points out a few historical twists to historical context of that. I read the paper by Royce long time ago and found it to be quite modern and insightful. It doesn't mention waterfalls at all (as the article points out). It also points out that, waterfall as we know and love it, basically was institutionalized bureaucratic government organizations using it to sugar coat heavy processes that they came up with that got subsequently adopted as "the way to do things" by equally bureaucratic large software houses they worked with. It got a bad reputation for said corporations making obscene amounts of money with obscenely bad software delivered late and never on budget. This pattern is something that is a constant and was referred to as the software crisis in the 1960s already and lead to Margaret Hamilton along with other famous pioneers in computing coining the notion of software engineering in the 1970s. She was of course working on the lunar program at Nasa (speaking of bureaucratic organizations). The software crisis is alive and kicking. Many scrum/agile organizations continue to peddle atrociously bad software developed. That doesn't mean that nothing has changed but you should beware of anyone claiming to know the one and only way to do stuff. There's a lot of common sense that inspired agile and waterfall. I'd argue the modern take on this is to replace manual processes with automation to facilitate rapid flow of changes from inception to production. Another trend is to decouple decision points to facilitate asynchronous processes and communication. For example, you don't bundle features into releases. Instead you ship pull requests straight to CI and CD pipelines. That means that there are no central planning bottlenecks for delivering new features and they can be developed on their own schedules. This happens continually. Most big brand websites you use, update many times per day. Iterations and sprints are kind of obsolete as a way of orchestrating release schedules. That practice is now creeping into the enterprise. If you are doing scrum and being told not to do this, that's something that you need to challenge.

sonnyblarney 8y ago

"The Waterfall Methodology is not a thing and only seems to be used as a "straw man" foil." Waterfall is a 'thing' because it existed long before software or computers. I view it as essentially the most obvious form of project management, which is simply a phased approach to solving a problem: gather requirements, plan, design, do, test, fix problems etc..

acdha 8y ago
I think that’s the core problem, too: it works fine for well-defined needs in mature categories — things like buying printers or renting office space, where all of the options are usually capable of doing the job to at least a basic level. Large organizations have tons of experience muddling through that process and it’s tempting to think that software is similar, especially because many vendors are will to perjure themselves saying so. The problem was accepting that custom software doesn’t work in the same way and reconciling the huge differences in how much customization people request versus what they are willing to pay.

mmsimanga 8y ago

The word Agile has become so loaded that if you want to side track a meeting just mention you will be using Agile. Nothing else of value will be discussed in the meeting because people will either vigorously object, support it or argue on what exactly is Agile. This brings me to your statement: > Agile, how it differs from common sense Thank you for mentioning common sense. No one size fits all. I have never followed one methodology to the absolute T. I borrow from all the methodologies I have read about. I use KanBan boards I learnt about at a Agile workshop but don't have daily scrum meetings. I have SLDC like development plans but never hesistate to meet clients to seek clarity when needed or even to show them what I have done. Sometimes I show them final product at the end of the implementation because it can confuse clients to show them a half finished product. Sometimes it is possible to show a half finished product. I must confess I haven't read the article but had to post about Agile :-).

randomdata 8y ago

It is but a symptom of the real problem of organizations blindly adopting 'Agile' out of no more than a desire to stay trendy and the developers taking an interest in the subject out of seeing that the move is an abject failure more often than not.