4 ms·
The mind of comprehensive documentation they were referring to were garbage 1000+ page documents… Perhaps, but I don’t believe that is how the documentation po
by Chris_Newton 5y ago
The mind of comprehensive documentation they were referring to were garbage 1000+ page documents…
Perhaps, but I don’t believe that is how the documentation point in the Manifesto has always been interpreted since then, and I suspect no-one else here does either.
As I said in my original comment, I think the ideas around Agile can be an interesting and useful area for discussion, but I’ve never fully agreed with the Agile Manifesto as-written. The danger with making these kinds of short, profound statements about a field as nuanced as software development is always that you immediately have to start backtracking and clarifying that what you really meant was… And as soon as you’re doing that, probably the original statement has lost most of any value it might have had anyway and it’s more interesting and productive to discuss the nuanced issues that you brought up afterwards instead.
In Waterfall and related BDUF approaches the intent was to produce this before any code.
OK, but it’s not as if everyone was trying to write software that way before the Agile Manifesto came along. I’ve been writing software for money since well before the Manifesto was published, I’d say I’ve worked on a fairly broad range of applications over the years, and I don’t think I’ve ever seen that kind of process in actual use either before or since the publication. Waterfall just seems to be the preferred straw man for Agile advocacy.
You just have to be smart enough to identify what is the MVP.
Or, more generally, you have to be smart enough to identify which milestones in terms of functionality and performance add real business value. That is almost always some kind of step function. Reaching an MVP that you can deploy to start collecting feedback from end users on a realistic product and ideally bringing in some revenue as well is obviously one of the more important steps when developing certain kinds of software, but really there is nothing unique about it and even for those kinds of software the same principles apply both before and after shipping the MVP.
That then invites the question, how do we identify what we need to have ready before we take the next step, MVP or otherwise? And just like before, the options are essentially to check our requirements or to wing it and hope that we’ve guessed well.
- Jtsummers 5y ago> Waterfall just seems to be the preferred straw man for Agile advocacy. People keep saying this, but either I hallucinated the early part of my career, or it's real. The straw man is saying that it's a straw man.
- Chris_Newton 5y agoWithout wanting to make this unnecessarily personal, I’m genuinely curious to know what sort of work you were doing at the time and how long ago that was. Anecdotally, I wrote my first code for money about 30 years ago and have been a developer by profession for well over 20 at this point, and I’ve never encountered anything like it. Even working on firmware or device control software, where you tend to know more of your requirements early on because they are dictated by the physical equipment involved, the process has always been incremental and changes in requirements have always happened along the way and been incorporated accordingly. Of course that’s just my own personal experience; I’m not disputing that yours might have been very different, just a little surprised.
- Jtsummers 5y agoAbout 15 years ago, aircraft safety systems at that point. One area where Waterfall is almost justifiable, but most of the other projects (in the same office) did not use Waterfall because (as that project demonstrated) it was crap. V-Model or Iterative & Incremental (slow-motion Scrum) were used with much greater success on all other projects. Success as in, they were rarely late by more than a rounding error (days, maybe a couple weeks). When they were late by larger margins the issues causing the delays were discovered early and were almost always requirements issues or hardware issues (that is, the former was partly on us, the latter never was). I've seen Waterfall used on other projects since then including a major information system that resulted in about $1 billion of waste, fortunately I've only been adjacent to them not on them. The billion dollar waste relied on (as Waterfall often does) late integration, none of the pieces worked together even though everyone built everything per the spec they'd been given. If you've not encountered it, that's great. Doesn't mean it doesn't exist.
- Chris_Newton 5y agoFair enough. Perhaps a better position would have been that a choice between Agile and Waterfall is often presented as a (false) dichotomy.