<story><title>Even with Agile and Scrum waterfall will sneak in</title><url>https://www.amazingcto.com/why-we-always-endup-with-waterfall-even-scrum/</url></story><parent_chain><item><author>boffinAudio</author><text>If you can&amp;#x27;t formulate actionable requirements, you&amp;#x27;re either not the domain expert, or not communicating properly with the domain expert.&lt;p&gt;What your service looks like &lt;i&gt;now&lt;/i&gt; and what it looks like in &lt;i&gt;five&lt;/i&gt; years are obviously two different questions, but a proper analysis will divide the issue between &lt;i&gt;now&lt;/i&gt; and &lt;i&gt;5 years from now&lt;/i&gt; and come up with requirements that fill the gaps.  This doesn&amp;#x27;t mean things get set in stone and aren&amp;#x27;t adaptable to changing needs - when this condition is identified, the manger&amp;#x2F;developer need only apply the workflow again, and revise the specifications with the updated data, and a new development plan can be formulated.  Maybe this is &amp;#x27;agile&amp;#x27;, but again - it speaks to the fact that waterfall is a naturally occurring phenomenon in engineering&amp;#x2F;technical matters, and thus should be applied consistently, completely, in order to provide fruitful results.&lt;p&gt;&amp;gt; You cannot analyse how users will empirically interact with a product that does not yet exist.&lt;p&gt;I don&amp;#x27;t agree with this, as I believe it is very, very glib.  You can of course empirically interact, &lt;i&gt;by wearing the user hat&lt;/i&gt;.  Too often the developer&amp;#x2F;manager&amp;#x2F;user hats are considered adversarial - but when the decision is made to be flexible about which of these hats one is wearing, &lt;i&gt;during analysis&lt;/i&gt;, makes all the difference between whether your product is successful or not.  Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field.&lt;p&gt;&amp;gt;You&amp;#x27;re presuming that it&amp;#x27;s possible to gather the &amp;quot;ideal requirements&amp;quot; when the project first starts, with enough due diligence - and also, that those requirements are fixed.&lt;p&gt;I make the claim that this ideal &lt;i&gt;can&lt;/i&gt; be attained, by ensuring that the early steps in the waterfall process are &lt;i&gt;actually&lt;/i&gt; applied.  You are correct in noting that &amp;quot;when you don&amp;#x27;t do things right, right things don&amp;#x27;t happen&amp;quot;, however ..</text></item><item><author>ivanbakel</author><text>&amp;gt;This just indicates a failure to perform a proper Analysis&amp;#x2F;Specification&amp;#x2F;Requirements phase, with relevant qualifications steps. It doesn&amp;#x27;t matter if you&amp;#x27;re a Manager or a lowly Developer - if you can&amp;#x27;t adequately qualify the requirements and specifications, the analysis is simply not complete.&lt;p&gt;But that view of requirements is not borne out by the reality for most projects. You&amp;#x27;re presuming that it&amp;#x27;s possible to gather the &amp;quot;ideal requirements&amp;quot; when the project first starts, with enough due diligence - and also, that those requirements are fixed.&lt;p&gt;In my current job, we&amp;#x27;re producing a service that has to court a handful of very large clients. Even if there was a well-defined idea of what the service should &lt;i&gt;eventually&lt;/i&gt; look like in 5 years, a lot of feedback is required to discover how it should look &lt;i&gt;now&lt;/i&gt;. Which client needs more attention? Where is the biggest opportunity for additional value? How are users &lt;i&gt;actually using&lt;/i&gt; the service, ignoring what they said they were going to do with it?&lt;p&gt;That last part is the most important - requirements are in reality a feedback process for which the existing product is one input. You cannot analyse how users will empirically interact with a product that does not yet exist. Abstract analysis is no substitute for data.</text></item><item><author>boffinAudio</author><text>&amp;gt;The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn&amp;#x27;t know what they want - they think they do, but they don&amp;#x27;t and will only realize this after you finished development and have a visible system demo&amp;#x2F;field test.&lt;p&gt;This just indicates a failure to perform a proper Analysis&amp;#x2F;Specification&amp;#x2F;Requirements phase, with relevant qualifications steps.  It doesn&amp;#x27;t matter if you&amp;#x27;re a Manager or a lowly Developer - if you can&amp;#x27;t adequately qualify the requirements and specifications, the analysis is simply &lt;i&gt;not&lt;/i&gt; complete.&lt;p&gt;Pushing the problem to or away- from Managers is just one way of saying &amp;quot;I&amp;#x27;m too lazy&amp;#x2F;incompetent to adequately complete the Analysis phase, resulting in poor requirements, lacking or contradictory specifications, and no planning&amp;quot;.  Its the Analysis that needs attention, i.e. maybe nobody actually knows how to wear the Analysts hat any more ..</text></item><item><author>littlecranky67</author><text>The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn&amp;#x27;t know what they want - they think they do, but they don&amp;#x27;t and will only realize this after you finished development and have a visible system demo&amp;#x2F;field test.&lt;p&gt;Additionally it is really hard for project management to get metrics&amp;#x2F;early warnings if something is not going properly (no project - waterfall or agile - is without problems during its lifetime). How would you asses the quality&amp;#x2F;progress of a project based on a couple of a specification or requirements documents 1-2years into the project with no (immediately usable) code being available? How would you asses if the approach taken after 3years in a project will be accepted by your endusers?&lt;p&gt;Waterfall is just a big black box to management and stakeholders with the hope that after 5years something usable will come out of it.</text></item><item><author>boffinAudio</author><text>I&amp;#x27;ve never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-&amp;#x2F;cargo-cult  territory.&lt;p&gt;There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated&amp;#x2F;verified with a Qualification step, and then it gets released to the end user&amp;#x2F;product owner, who sign off on it.&lt;p&gt;This is a natural flow of steps, and it always appears to me that the new-fangled developer cults are always trying to &amp;#x27;prove&amp;#x27; that these aren&amp;#x27;t natural steps, by either cramming every step into one phase (we only do &amp;quot;Analysis&amp;quot; and call it Scrum) or by throwing away steps (Qualification?  What&amp;#x27;s that?) and then wondering why things are crap.&lt;p&gt;Too many times, projects I&amp;#x27;ve seen fail could&amp;#x27;ve been saved if they&amp;#x27;d just gotten rid of the cult-think.&lt;p&gt;Its nice, therefore, to see someone else making the observation that Waterfall is a natural process and all the other -isms are just sugar&amp;#x2F;crap-coating what is a natural consequence of organizing computing around the OSI model - something that has been effective for decades now, and doesn&amp;#x27;t need improvement-from-the-youth antics.</text></item></parent_chain><comment><author>ivanbakel</author><text>&amp;gt;but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps&lt;p&gt;The issue with the Waterfall model is that this approach doesn&amp;#x27;t work. Aiming for &amp;quot;now&amp;quot; means you come out with an outdated product in the future. Aiming for &amp;quot;5 years from now&amp;quot; means speculating on what users &lt;i&gt;will eventually want&lt;/i&gt;, which is very error-prone. Trying to adjust course midway through is a nightmare - and completely defeats the point of trying to get requirements &amp;quot;right&amp;quot; the first time.&lt;p&gt;&amp;gt;You can of course empirically interact, by wearing the user hat.&lt;p&gt;This is not empirical: it does not involve observation or measurement of the real world. Speculating about user behaviour is no substitute for concrete data about how users actually behave.</text></comment>
<story><title>Even with Agile and Scrum waterfall will sneak in</title><url>https://www.amazingcto.com/why-we-always-endup-with-waterfall-even-scrum/</url></story><parent_chain><item><author>boffinAudio</author><text>If you can&amp;#x27;t formulate actionable requirements, you&amp;#x27;re either not the domain expert, or not communicating properly with the domain expert.&lt;p&gt;What your service looks like &lt;i&gt;now&lt;/i&gt; and what it looks like in &lt;i&gt;five&lt;/i&gt; years are obviously two different questions, but a proper analysis will divide the issue between &lt;i&gt;now&lt;/i&gt; and &lt;i&gt;5 years from now&lt;/i&gt; and come up with requirements that fill the gaps.  This doesn&amp;#x27;t mean things get set in stone and aren&amp;#x27;t adaptable to changing needs - when this condition is identified, the manger&amp;#x2F;developer need only apply the workflow again, and revise the specifications with the updated data, and a new development plan can be formulated.  Maybe this is &amp;#x27;agile&amp;#x27;, but again - it speaks to the fact that waterfall is a naturally occurring phenomenon in engineering&amp;#x2F;technical matters, and thus should be applied consistently, completely, in order to provide fruitful results.&lt;p&gt;&amp;gt; You cannot analyse how users will empirically interact with a product that does not yet exist.&lt;p&gt;I don&amp;#x27;t agree with this, as I believe it is very, very glib.  You can of course empirically interact, &lt;i&gt;by wearing the user hat&lt;/i&gt;.  Too often the developer&amp;#x2F;manager&amp;#x2F;user hats are considered adversarial - but when the decision is made to be flexible about which of these hats one is wearing, &lt;i&gt;during analysis&lt;/i&gt;, makes all the difference between whether your product is successful or not.  Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field.&lt;p&gt;&amp;gt;You&amp;#x27;re presuming that it&amp;#x27;s possible to gather the &amp;quot;ideal requirements&amp;quot; when the project first starts, with enough due diligence - and also, that those requirements are fixed.&lt;p&gt;I make the claim that this ideal &lt;i&gt;can&lt;/i&gt; be attained, by ensuring that the early steps in the waterfall process are &lt;i&gt;actually&lt;/i&gt; applied.  You are correct in noting that &amp;quot;when you don&amp;#x27;t do things right, right things don&amp;#x27;t happen&amp;quot;, however ..</text></item><item><author>ivanbakel</author><text>&amp;gt;This just indicates a failure to perform a proper Analysis&amp;#x2F;Specification&amp;#x2F;Requirements phase, with relevant qualifications steps. It doesn&amp;#x27;t matter if you&amp;#x27;re a Manager or a lowly Developer - if you can&amp;#x27;t adequately qualify the requirements and specifications, the analysis is simply not complete.&lt;p&gt;But that view of requirements is not borne out by the reality for most projects. You&amp;#x27;re presuming that it&amp;#x27;s possible to gather the &amp;quot;ideal requirements&amp;quot; when the project first starts, with enough due diligence - and also, that those requirements are fixed.&lt;p&gt;In my current job, we&amp;#x27;re producing a service that has to court a handful of very large clients. Even if there was a well-defined idea of what the service should &lt;i&gt;eventually&lt;/i&gt; look like in 5 years, a lot of feedback is required to discover how it should look &lt;i&gt;now&lt;/i&gt;. Which client needs more attention? Where is the biggest opportunity for additional value? How are users &lt;i&gt;actually using&lt;/i&gt; the service, ignoring what they said they were going to do with it?&lt;p&gt;That last part is the most important - requirements are in reality a feedback process for which the existing product is one input. You cannot analyse how users will empirically interact with a product that does not yet exist. Abstract analysis is no substitute for data.</text></item><item><author>boffinAudio</author><text>&amp;gt;The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn&amp;#x27;t know what they want - they think they do, but they don&amp;#x27;t and will only realize this after you finished development and have a visible system demo&amp;#x2F;field test.&lt;p&gt;This just indicates a failure to perform a proper Analysis&amp;#x2F;Specification&amp;#x2F;Requirements phase, with relevant qualifications steps.  It doesn&amp;#x27;t matter if you&amp;#x27;re a Manager or a lowly Developer - if you can&amp;#x27;t adequately qualify the requirements and specifications, the analysis is simply &lt;i&gt;not&lt;/i&gt; complete.&lt;p&gt;Pushing the problem to or away- from Managers is just one way of saying &amp;quot;I&amp;#x27;m too lazy&amp;#x2F;incompetent to adequately complete the Analysis phase, resulting in poor requirements, lacking or contradictory specifications, and no planning&amp;quot;.  Its the Analysis that needs attention, i.e. maybe nobody actually knows how to wear the Analysts hat any more ..</text></item><item><author>littlecranky67</author><text>The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn&amp;#x27;t know what they want - they think they do, but they don&amp;#x27;t and will only realize this after you finished development and have a visible system demo&amp;#x2F;field test.&lt;p&gt;Additionally it is really hard for project management to get metrics&amp;#x2F;early warnings if something is not going properly (no project - waterfall or agile - is without problems during its lifetime). How would you asses the quality&amp;#x2F;progress of a project based on a couple of a specification or requirements documents 1-2years into the project with no (immediately usable) code being available? How would you asses if the approach taken after 3years in a project will be accepted by your endusers?&lt;p&gt;Waterfall is just a big black box to management and stakeholders with the hope that after 5years something usable will come out of it.</text></item><item><author>boffinAudio</author><text>I&amp;#x27;ve never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-&amp;#x2F;cargo-cult  territory.&lt;p&gt;There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated&amp;#x2F;verified with a Qualification step, and then it gets released to the end user&amp;#x2F;product owner, who sign off on it.&lt;p&gt;This is a natural flow of steps, and it always appears to me that the new-fangled developer cults are always trying to &amp;#x27;prove&amp;#x27; that these aren&amp;#x27;t natural steps, by either cramming every step into one phase (we only do &amp;quot;Analysis&amp;quot; and call it Scrum) or by throwing away steps (Qualification?  What&amp;#x27;s that?) and then wondering why things are crap.&lt;p&gt;Too many times, projects I&amp;#x27;ve seen fail could&amp;#x27;ve been saved if they&amp;#x27;d just gotten rid of the cult-think.&lt;p&gt;Its nice, therefore, to see someone else making the observation that Waterfall is a natural process and all the other -isms are just sugar&amp;#x2F;crap-coating what is a natural consequence of organizing computing around the OSI model - something that has been effective for decades now, and doesn&amp;#x27;t need improvement-from-the-youth antics.</text></item></parent_chain><comment><author>LaundroMat</author><text>&amp;quot;Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field.&amp;quot;&lt;p&gt;All the more reason &lt;i&gt;not&lt;/i&gt; to rely on the proper wearing of a user hat (how are you going to know, by the way?), but actually work with the users instead and spend time creating the necessary artefacts to capture their perspective as soon and as well as possible.</text></comment>