7 ms·

I don't know about an accident, necessarily. It's got two important things going for it. 1. It lets everyone involved cover their ass. "All I'm responsible

by seanc 8y ago

I don't know about an accident, necessarily. It's got two important things going for it. 1. It lets everyone involved cover their ass. "All I'm responsible for is my function. There was a problem with my inputs, so no wonder my outputs suck. Don't blame me, my inputs are all right there in black and white, and you signed off on them." 2. It gives people the comforting feeling that they can predict the future, and then do things like plan budgets or negotiate fixed price sales contracts. Predicting the future is irresistible for people who handle money. As fictional as it might be. So those two things, I think they have a momentum of their own, and without constant vigilance and effort, for most domains, waterfall development is a sad, inevitable default.

dreamcompiler 8y ago
Completely agree. The recent discussion here about Jira confirms this: Any new software development methodology -- however well-intentioned -- eventually will be distorted into the waterfall model with a sexier name. The incentives for doing so are much more powerful than the incentives for sticking with a truly better development process. If we want to change this, we have to change those incentives.
- mlthoughts2018 8y ago
  I agree with you, except I’d say that the ideal of Agile, the manifesto itself, responding to change, etc., is a significantly worse workflow process than Waterfall (which is also bad). Agile prescribes so many things that are absolutely pushover, toothless concepts in the face of basic corporate bureaucracy that it really is a case where it’s the tool’s own fault that everyone uses it wrong. I’ve seen Waterfall used successfully. Not often, but on a few defense research projects it was great. I have never once seen or heard of any Agile process anywhere actually working with any degree of success. I’ve heard plenty of people indulging some No True Scotsman nonsense about how a “real” Agile process can succeed, and then proceeding to write a diatribe about their “real Agile” workplace that is clearly so fucked with dysfunction that the person writing can’t even realize they are only shipping software in spite of Agile and not the least bit because of it. But I’ve never ever seen or heard of it actually causing success, not across any of the countless blog posts or anecdata on HN, and not across 6 different jobs at companies of various ages, sizes and capitalization levels all using Agile withvarying degrees of formality, pragmatism, Agile coaching and consulting, etc. None of it made any difference. Agile just hinders people. It is not capable of doing otherwise. Now, having said all that, I do agree that for processes that can work, processes that are not overly prescriptive, let different teams do things different ways at different times based on different goals or different personnel, let teams ignore the customer when needed, enforce long-term planning when needed, do pure research with no time boxing when needed, etc., then for those kinds of common sense, non-Agile processes, we have to change the incentives so that people are aligned to care about the objective truth and objective outcomes required to get the job done.
  - com2kid 8y ago
    > I have never once seen or heard of any Agile process anywhere actually working with any degree of success. I ran a team were we shipped (firmware!) every 3 weeks. After the first year of tracking all our numbers we were able to hit our estimates within a few hours +/- for the entire team. 3 week sprints, 2 weeks writing code, 1 week testing and bug fixing. It wasn't perfect, and learning how to do it was painful, but once we got going it worked great. We didn't adhere strongly to any one guiding principle, but being able to use sprints to align work across multiple teams, and as a planning mechanism for management was incredibly useful. "Our breakdown of that feature means it'll take 3 sprints in total, the last of those sprints the work is split across 2 devs, if one of those devs gets reassigned it'll take 4 sprints." Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating, and knowing how far to break work down. There is of course a trade off between gains from breaking work down, and time spent doing the breakdown! Several months were rather painful when we went too far one way, and then inevitably the next few months swung too far in the other direction. But in the end? Yeah it all worked out. We figured out what length of sprint worked for us, what type of estimation system to use, and how much work to put into our planning sessions. FWIW one of the huge benefit of doing the work breakdowns is being able to see opportunities to parallelize work, and also to see natural stopping points. My team was lucky to have someone almost full-time dedicated to managing our workflow, without that the entire process wouldn't have been tenable. The tools just suck up too much time.
    - mlthoughts2018 8y ago
      > “Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating” I’m skeptical of this, because even working in a team that had many person-decades of experience of estimating software delivery, the consensus opinion was that nobody’s estimates are worth anything and that the business would actually be worse off using estimates even as mere guidelines than just working on things, hitting blockers, and adjust expectations as you go. But regardless it sounds like your process was fairly different from Agile. The only superficial similarity was having some notion of a regular sprint cadence, but cadence based scheduling is common to many project management strategies. It sounds like you had something very pragmatic for your exact situation, which is great — that’s the whole goal, the very thing Agile paradoxically does not conceptually support.
agumonkey 8y ago
I experienced 1) in another context. We went from traditional coarse task per employee to atomic operation dedicated employees, to increase throughput. The system became blind. Everybody was applying it's tiny task on the stream, except there were always a tiny % of ambiguity that nobody cared enough (we all cared, but the stream pushed and no one upstream / manager wanted to stop and solve issues). We generated a never ending list of crap that got rejected by the final commit step.
- jrochkind1 8y ago
  but you totally increased throughput, right?
  - agumonkey 8y ago
    for a while, then higher level consultants fixed numbers while we were reorganizing ..
gthtjtkt 8y ago
Did I read the wrong article? I don't see how your comment is related to the content of the article at all aside from the word "waterfall".
- seanc 8y ago
  To my reading, the article suggests that the reason why we have waterfall style development is because some guy at the DoD misread Winston Royce's paper. "In 1985 the US Departement of Defense wanted a documented process for software development: DOD-STD-2167. Since governments and companies reused these requirements, it radiated across the world from there" I contend that there are more fundamental reasons for this, so even if this quirk of history had never occurred, we'd still see a lot of waterfall development.

by seanc 8y ago

dreamcompiler 8y ago

Completely agree. The recent discussion here about Jira confirms this: Any new software development methodology -- however well-intentioned -- eventually will be distorted into the waterfall model with a sexier name. The incentives for doing so are much more powerful than the incentives for sticking with a truly better development process. If we want to change this, we have to change those incentives.

mlthoughts2018 8y ago
I agree with you, except I’d say that the ideal of Agile, the manifesto itself, responding to change, etc., is a significantly worse workflow process than Waterfall (which is also bad). Agile prescribes so many things that are absolutely pushover, toothless concepts in the face of basic corporate bureaucracy that it really is a case where it’s the tool’s own fault that everyone uses it wrong. I’ve seen Waterfall used successfully. Not often, but on a few defense research projects it was great. I have never once seen or heard of any Agile process anywhere actually working with any degree of success. I’ve heard plenty of people indulging some No True Scotsman nonsense about how a “real” Agile process can succeed, and then proceeding to write a diatribe about their “real Agile” workplace that is clearly so fucked with dysfunction that the person writing can’t even realize they are only shipping software in spite of Agile and not the least bit because of it. But I’ve never ever seen or heard of it actually causing success, not across any of the countless blog posts or anecdata on HN, and not across 6 different jobs at companies of various ages, sizes and capitalization levels all using Agile withvarying degrees of formality, pragmatism, Agile coaching and consulting, etc. None of it made any difference. Agile just hinders people. It is not capable of doing otherwise. Now, having said all that, I do agree that for processes that can work, processes that are not overly prescriptive, let different teams do things different ways at different times based on different goals or different personnel, let teams ignore the customer when needed, enforce long-term planning when needed, do pure research with no time boxing when needed, etc., then for those kinds of common sense, non-Agile processes, we have to change the incentives so that people are aligned to care about the objective truth and objective outcomes required to get the job done.
- com2kid 8y ago
  > I have never once seen or heard of any Agile process anywhere actually working with any degree of success. I ran a team were we shipped (firmware!) every 3 weeks. After the first year of tracking all our numbers we were able to hit our estimates within a few hours +/- for the entire team. 3 week sprints, 2 weeks writing code, 1 week testing and bug fixing. It wasn't perfect, and learning how to do it was painful, but once we got going it worked great. We didn't adhere strongly to any one guiding principle, but being able to use sprints to align work across multiple teams, and as a planning mechanism for management was incredibly useful. "Our breakdown of that feature means it'll take 3 sprints in total, the last of those sprints the work is split across 2 devs, if one of those devs gets reassigned it'll take 4 sprints." Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating, and knowing how far to break work down. There is of course a trade off between gains from breaking work down, and time spent doing the breakdown! Several months were rather painful when we went too far one way, and then inevitably the next few months swung too far in the other direction. But in the end? Yeah it all worked out. We figured out what length of sprint worked for us, what type of estimation system to use, and how much work to put into our planning sessions. FWIW one of the huge benefit of doing the work breakdowns is being able to see opportunities to parallelize work, and also to see natural stopping points. My team was lucky to have someone almost full-time dedicated to managing our workflow, without that the entire process wouldn't have been tenable. The tools just suck up too much time.
  - mlthoughts2018 8y ago
    > “Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating” I’m skeptical of this, because even working in a team that had many person-decades of experience of estimating software delivery, the consensus opinion was that nobody’s estimates are worth anything and that the business would actually be worse off using estimates even as mere guidelines than just working on things, hitting blockers, and adjust expectations as you go. But regardless it sounds like your process was fairly different from Agile. The only superficial similarity was having some notion of a regular sprint cadence, but cadence based scheduling is common to many project management strategies. It sounds like you had something very pragmatic for your exact situation, which is great — that’s the whole goal, the very thing Agile paradoxically does not conceptually support.

agumonkey 8y ago

I experienced 1) in another context. We went from traditional coarse task per employee to atomic operation dedicated employees, to increase throughput. The system became blind. Everybody was applying it's tiny task on the stream, except there were always a tiny % of ambiguity that nobody cared enough (we all cared, but the stream pushed and no one upstream / manager wanted to stop and solve issues). We generated a never ending list of crap that got rejected by the final commit step.

jrochkind1 8y ago
but you totally increased throughput, right?
- agumonkey 8y ago
  for a while, then higher level consultants fixed numbers while we were reorganizing ..

gthtjtkt 8y ago

Did I read the wrong article? I don't see how your comment is related to the content of the article at all aside from the word "waterfall".

seanc 8y ago
To my reading, the article suggests that the reason why we have waterfall style development is because some guy at the DoD misread Winston Royce's paper. "In 1985 the US Departement of Defense wanted a documented process for software development: DOD-STD-2167. Since governments and companies reused these requirements, it radiated across the world from there" I contend that there are more fundamental reasons for this, so even if this quirk of history had never occurred, we'd still see a lot of waterfall development.