6 ms·

I think I’d prefer to do Waterfall correctly than pretending to be Agile. I love the idea of Agile, hasn’t worked at our company since we got spotified.

Jtsummers 5y ago
Doing Waterfall correctly is easy. Spend 1 year planning, 3-5 years building, 1 year testing, then release. Find out you built the wrong thing, enjoy the earnings from your $10 billion government contract, and start another cycle.
- JohnFen 5y ago
  People often describe waterfall in that way -- but I've been in the industry for decades, and if that's what waterfall is, then I have never seen anyone do waterfall even before Agile was a thing. I think that "waterfall" is often a straw man.
  - Jtsummers 5y ago
    > I think that "waterfall" is often a straw man. Every discussion where Waterfall comes up has someone saying this, I'm glad you've not experienced it. But it has existed, does exist, and will continue to exist (because enough project managers are idiots). One of my first jobs (I quit) was a failed project that persisted because of gov't money, but would have failed as a commercial venture (started circa 2007, failed to deliver at least through 2011, I was on board for a year and found an exit). It was 100% Waterfall, they literally delivered the wrong thing several years late and with around $1 billion spent. Great for the contractors, awful for the taxpayers. But yes, that is what Waterfall is. It's a large scale project executed linearly with limited-to-no-feedback. Large scale is somewhat subjective, but basically if it's done in less than a few months it's probably not at a scale where your choice of development model actually matters.
  - brightball 5y ago
    The issue with waterfall is that planning it properly depends entirely on accurate estimates. Estimates are never accurate. You can’t possibly have all of the information present up front.
    - dilyevsky 5y ago
      In my experience with waterfall this was solved exactly same as with making sure scrum stories can be completed in a sprint - by padding the shit out of your estimates to the point most engineers can complete their tasks working a few hours a week.
  - corpMaverick 5y ago
    I think it is more correctly defined as "Big Upfront Design". This was a thing; months spent on analysis and design that filled several tomes.
    - Jtsummers 5y ago
      Big Design Up Front (the more common way of ordering the words) is related to, but is not, Waterfall. Waterfall is best considered an instance of BDUF (to borrow a programming term). V-Model and (often) Iterative & Incremental (slow-motion Scrum) each have varying degrees of BDUF as well, and there are plenty of other SDLCs out there that can be categorized as BDUF-lifecycles. Waterfall's principle failing for large scale projects is that it does not incorporate sufficient (if any) feedback or delays the feedback until too late in the cycle, and plans too far out to be reasonable (do you kwon with any real confidence what you'll have for dinner in 3 years, 2 months and a day?) V-model generally also plans out very far, but incorporates V&V as an ongoing activity (it's name is a bit of a pun, both incorporating V&V and usually being charted out as a V, vice a waterfall for Waterfall). I&I may have a big design phase, but it's usually not as fully designed as either Waterfall or the V-model because the iterations are meant to provide checkpoints for validating the design and potentially changing direction (like I wrote, slow-motion Scrum).
- Ecstatify 5y ago
  Conversely we’re Agile™, the company is looking for external solutions to replace everything that has been developed for the last 8 years. If the company from top to bottom isn’t Agile then I don’t believe you can truly be Agile.
  - Jtsummers 5y ago
    I'd agree with that. A principle quality of Agile (what was intended, though often not what is) is responsiveness to changing circumstances and reality. A commitment to the wrong development model is anti-Agile, though very common. It's, for most purposes, just as bad as Waterfall's commitment to building the wrong thing.
Graffur 5y ago
What does getting 'spotified' mean? A company doing Agile poorly most likely would do Waterfall poorly too.
- Ecstatify 5y ago
  Spotified basically means your company decided it was Agile™ and forced the Spotify model on teams so essentially now you’re a cargo cult. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScal... Our problem at the moment is we have no processes/documentation because we’re Agile™
- blakehaswell 5y ago
  Back in 2014 Spotify released some videos[1][2] about their engineering culture. From what I understand these were widely cited by consultants and the squad/tribe/chapter model was implemented verbatim at a number of companies. I'm guessing that is "getting Spotified". [1]: https://engineering.atspotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://engineering.atspotify.com/2014/03/27/spotify-enginee... [2]: https://engineering.atspotify.com/2014/09/20/spotify-engineering-culture-part-2/ https://engineering.atspotify.com/2014/09/20/spotify-enginee...
  - Ecstatify 5y ago
    Allegedly they never actually implemented the model either https://www.jeremiahlee.com/posts/failed-squad-goals/ https://www.jeremiahlee.com/posts/failed-squad-goals/
EliRivers 5y ago
The highest quality software I ever worked on was waterfall all the way, and by God, was it high quality. The requirements were hammered out in brutal detail by an experienced specialist. Each requirement agreed with the customer, and then each requirement carefully worked into a design. Each requirement clearly linked with every part of the design that fulfilled it. The design reviewed and approved. The code written in literal style (using a variant of noweb), with discussion and commentary, and that noweb document compiling into the source code to be onwards compiled and also a beautiful document listing the full source code and the various commentaries and discussions of it (such that one understood the code not by looking at the code, but by reading the document, which was like a structured guided tour of the code, and to look at the actual code was to see a one-to-one relationship with the documentation). Each part of that document linked to a part of the design, and thus to the requirements. Tests had been written independently of the code, based on the design and the original requirements. Test documents were printed out, and an individual conducted every test on that document, writing down version numbers and so on, and writing down each results, circling PASS or FAIL, signing their name to it. Successful test documents were sealed in an envelope, with a date and signature, and put into storage against the customer requesting to see one (which happened every so often). The original requirements could, years later, be followed through the design, through the code, through the tests; the whole chain verified on demand. The software I worked on was developed over most of a decade (I was only there about four years), with a delivery a couple of times a year. The customer never once reported a bug. Every requirement was met. Other contractors had their part taken away from them and given to us, and when it was finished they took it and asked us if we could start working on the next generation product of the same. I have never before or since worked on such high quality software. It was only possible because we happened to have really high quality customers, who actually knew what they wanted and had the ability to say it and agree to it.
- foobarian 5y ago
  Quoth the Tao of Programming: 8.3 There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?" The mainframe programmer then began to describe his system to his friend, saying, "The mainframe sits like an ancient Sage meditating in the midst of the Data Center. Its disk drives lie end-to- end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am." The personal computer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
hinkley 5y ago
Waterfall with WIP limits and continuous delivery is far less painful than a lot of processes I've used. Because waterfall generally has milestones as a coarser grained way of ensuring evidence of forward progress, all deliverables generated around the time of a milestone just become candidates for delivery. Do you want this version that is missing two features, this version that is missing one but the other might be buggy, or to wait another two weeks to get the whole thing? If you have anything that looks like QA or acceptance tests, those can be run on deliverables, keeping people a little more comfortable with the process than they would with strict Waterfall.
thrower123 5y ago
To quote Fowler and all of his ilk, this means you're doing it wrong, and you must contemplate the principles of Agile further until you achieve enlightenment and discover True Agile.
- g051051 5y ago
  > But this guidebook can help you through that journey—moving away from barren ceremonies to the vigor that we felt when James and I first used these techniques all those years ago. This explains so much...this was something they enjoyed, and somehow conflated that as some kind of proof that it would work for all software development.
Zababa 5y ago
We're technically agile at my work, which means that we follow a waterfall cycle of 2 weeks.

Jtsummers 5y ago

Doing Waterfall correctly is easy. Spend 1 year planning, 3-5 years building, 1 year testing, then release. Find out you built the wrong thing, enjoy the earnings from your $10 billion government contract, and start another cycle.

JohnFen 5y ago
People often describe waterfall in that way -- but I've been in the industry for decades, and if that's what waterfall is, then I have never seen anyone do waterfall even before Agile was a thing. I think that "waterfall" is often a straw man.
- Jtsummers 5y ago
  > I think that "waterfall" is often a straw man. Every discussion where Waterfall comes up has someone saying this, I'm glad you've not experienced it. But it has existed, does exist, and will continue to exist (because enough project managers are idiots). One of my first jobs (I quit) was a failed project that persisted because of gov't money, but would have failed as a commercial venture (started circa 2007, failed to deliver at least through 2011, I was on board for a year and found an exit). It was 100% Waterfall, they literally delivered the wrong thing several years late and with around $1 billion spent. Great for the contractors, awful for the taxpayers. But yes, that is what Waterfall is. It's a large scale project executed linearly with limited-to-no-feedback. Large scale is somewhat subjective, but basically if it's done in less than a few months it's probably not at a scale where your choice of development model actually matters.
- brightball 5y ago
  The issue with waterfall is that planning it properly depends entirely on accurate estimates. Estimates are never accurate. You can’t possibly have all of the information present up front.
  - dilyevsky 5y ago
    In my experience with waterfall this was solved exactly same as with making sure scrum stories can be completed in a sprint - by padding the shit out of your estimates to the point most engineers can complete their tasks working a few hours a week.
- corpMaverick 5y ago
  I think it is more correctly defined as "Big Upfront Design". This was a thing; months spent on analysis and design that filled several tomes.
  - Jtsummers 5y ago
    Big Design Up Front (the more common way of ordering the words) is related to, but is not, Waterfall. Waterfall is best considered an instance of BDUF (to borrow a programming term). V-Model and (often) Iterative & Incremental (slow-motion Scrum) each have varying degrees of BDUF as well, and there are plenty of other SDLCs out there that can be categorized as BDUF-lifecycles. Waterfall's principle failing for large scale projects is that it does not incorporate sufficient (if any) feedback or delays the feedback until too late in the cycle, and plans too far out to be reasonable (do you kwon with any real confidence what you'll have for dinner in 3 years, 2 months and a day?) V-model generally also plans out very far, but incorporates V&V as an ongoing activity (it's name is a bit of a pun, both incorporating V&V and usually being charted out as a V, vice a waterfall for Waterfall). I&I may have a big design phase, but it's usually not as fully designed as either Waterfall or the V-model because the iterations are meant to provide checkpoints for validating the design and potentially changing direction (like I wrote, slow-motion Scrum).
Ecstatify 5y ago
Conversely we’re Agile™, the company is looking for external solutions to replace everything that has been developed for the last 8 years. If the company from top to bottom isn’t Agile then I don’t believe you can truly be Agile.
- Jtsummers 5y ago
  I'd agree with that. A principle quality of Agile (what was intended, though often not what is) is responsiveness to changing circumstances and reality. A commitment to the wrong development model is anti-Agile, though very common. It's, for most purposes, just as bad as Waterfall's commitment to building the wrong thing.

Graffur 5y ago

What does getting 'spotified' mean? A company doing Agile poorly most likely would do Waterfall poorly too.

Ecstatify 5y ago
Spotified basically means your company decided it was Agile™ and forced the Spotify model on teams so essentially now you’re a cargo cult. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScal... Our problem at the moment is we have no processes/documentation because we’re Agile™
blakehaswell 5y ago
Back in 2014 Spotify released some videos[1][2] about their engineering culture. From what I understand these were widely cited by consultants and the squad/tribe/chapter model was implemented verbatim at a number of companies. I'm guessing that is "getting Spotified". [1]: https://engineering.atspotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://engineering.atspotify.com/2014/03/27/spotify-enginee... [2]: https://engineering.atspotify.com/2014/09/20/spotify-engineering-culture-part-2/ https://engineering.atspotify.com/2014/09/20/spotify-enginee...
- Ecstatify 5y ago
  Allegedly they never actually implemented the model either https://www.jeremiahlee.com/posts/failed-squad-goals/ https://www.jeremiahlee.com/posts/failed-squad-goals/

EliRivers 5y ago

The highest quality software I ever worked on was waterfall all the way, and by God, was it high quality. The requirements were hammered out in brutal detail by an experienced specialist. Each requirement agreed with the customer, and then each requirement carefully worked into a design. Each requirement clearly linked with every part of the design that fulfilled it. The design reviewed and approved. The code written in literal style (using a variant of noweb), with discussion and commentary, and that noweb document compiling into the source code to be onwards compiled and also a beautiful document listing the full source code and the various commentaries and discussions of it (such that one understood the code not by looking at the code, but by reading the document, which was like a structured guided tour of the code, and to look at the actual code was to see a one-to-one relationship with the documentation). Each part of that document linked to a part of the design, and thus to the requirements. Tests had been written independently of the code, based on the design and the original requirements. Test documents were printed out, and an individual conducted every test on that document, writing down version numbers and so on, and writing down each results, circling PASS or FAIL, signing their name to it. Successful test documents were sealed in an envelope, with a date and signature, and put into storage against the customer requesting to see one (which happened every so often). The original requirements could, years later, be followed through the design, through the code, through the tests; the whole chain verified on demand. The software I worked on was developed over most of a decade (I was only there about four years), with a delivery a couple of times a year. The customer never once reported a bug. Every requirement was met. Other contractors had their part taken away from them and given to us, and when it was finished they took it and asked us if we could start working on the next generation product of the same. I have never before or since worked on such high quality software. It was only possible because we happened to have really high quality customers, who actually knew what they wanted and had the ability to say it and agree to it.

foobarian 5y ago
Quoth the Tao of Programming: 8.3 There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?" The mainframe programmer then began to describe his system to his friend, saying, "The mainframe sits like an ancient Sage meditating in the midst of the Data Center. Its disk drives lie end-to- end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am." The personal computer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.

hinkley 5y ago

Waterfall with WIP limits and continuous delivery is far less painful than a lot of processes I've used. Because waterfall generally has milestones as a coarser grained way of ensuring evidence of forward progress, all deliverables generated around the time of a milestone just become candidates for delivery. Do you want this version that is missing two features, this version that is missing one but the other might be buggy, or to wait another two weeks to get the whole thing? If you have anything that looks like QA or acceptance tests, those can be run on deliverables, keeping people a little more comfortable with the process than they would with strict Waterfall.

thrower123 5y ago

To quote Fowler and all of his ilk, this means you're doing it wrong, and you must contemplate the principles of Agile further until you achieve enlightenment and discover True Agile.

g051051 5y ago
> But this guidebook can help you through that journey—moving away from barren ceremonies to the vigor that we felt when James and I first used these techniques all those years ago. This explains so much...this was something they enjoyed, and somehow conflated that as some kind of proof that it would work for all software development.

Zababa 5y ago

We're technically agile at my work, which means that we follow a waterfall cycle of 2 weeks.