<story><title>A brief list of what Scrum gets wrong</title><url>https://medium.com/@ard_adam/why-scrum-is-the-wrong-way-to-build-software-99d8994409e5</url></story><parent_chain><item><author>wilkosez</author><text>I agree 100%.&lt;p&gt;Thankfully I dont do agile any more, but I&amp;#x27;m close to several teams that do. My fondest memories are:&lt;p&gt;No over-arching design (Implement feature after feature however the hell anyone likes)
Once said features are implemented, taking the time to &amp;quot;refactor&amp;quot; (read: completely rewrite because the code was so bad) becomes a really hard sell.&lt;p&gt;Thus, new features get progressively harder to implement, as you touch a deeper cross-section of the code to try and fix stuff semi-covertly, without a formal refactor.&lt;p&gt;&amp;quot;Tech Debt&amp;quot; was done in sprint scheduled after phase of dev sprints. After, say, a year of development, lets fix all the problems in 3 weeks... When you&amp;#x27;re dealing with procedural php masquerading as OO, MVC with business logic everywhere it shouldnt be, and abuse of inheritance such that you cant throw an error in a command line because you&amp;#x27;re not a logged in browser user, who&amp;#x27;s had their language queried from a database, and doesnt fall back to default when the db isnt there... 3 weeks isnt gonna cut it!&lt;p&gt;Introducing peer review was supposed to sort that, but bad or inexperienced devs didnt know they were doing shoddy work (it met the criteria after all..), and good devs became impediments because so many stories needed redoing. Demoralising.&lt;p&gt;We were probably &amp;quot;doing agile wrong&amp;quot;. But it&amp;#x27;s like a religion: open to interpretation. In my experience it&amp;#x27;s a tool used to extract maximum customer benefit at the expense of the developer&amp;#x27;s soul, under the pretence of &amp;quot;self managing team&amp;quot; - ie. &amp;quot;You brought it on yourself&amp;quot;.</text></item></parent_chain><comment><author>Huggernaut</author><text>&amp;gt; No over-arching design (Implement feature after feature however the hell anyone likes) Once said features are implemented, taking the time to &amp;quot;refactor&amp;quot; (read: completely rewrite because the code was so bad) becomes a really hard sell.&lt;p&gt;Can I ask why do you deliver stories before refactoring, if that&amp;#x27;s what you&amp;#x27;re saying? We&amp;#x27;d tend to do necessary refactors as part of features or bugs when we touch related code and rarely have pure refactor chores.&lt;p&gt;Also, why do you have to _sell_ code quality? At least where I work there is a pretty strong divide between what to build and how to build it. There is two-way trust between the product manager and engineers that they know their domain and when they say &amp;quot;this is important right now&amp;quot;, it&amp;#x27;s probably the right thing. After that it&amp;#x27;s just a matter of communication and prioritisation between the the two sides.&lt;p&gt;I could easily see how this might fall apart if either side was not trusted or not doing a great job, but I guess it would probably fall apart no matter what development process you followed if that were true.</text></comment>
<story><title>A brief list of what Scrum gets wrong</title><url>https://medium.com/@ard_adam/why-scrum-is-the-wrong-way-to-build-software-99d8994409e5</url></story><parent_chain><item><author>wilkosez</author><text>I agree 100%.&lt;p&gt;Thankfully I dont do agile any more, but I&amp;#x27;m close to several teams that do. My fondest memories are:&lt;p&gt;No over-arching design (Implement feature after feature however the hell anyone likes)
Once said features are implemented, taking the time to &amp;quot;refactor&amp;quot; (read: completely rewrite because the code was so bad) becomes a really hard sell.&lt;p&gt;Thus, new features get progressively harder to implement, as you touch a deeper cross-section of the code to try and fix stuff semi-covertly, without a formal refactor.&lt;p&gt;&amp;quot;Tech Debt&amp;quot; was done in sprint scheduled after phase of dev sprints. After, say, a year of development, lets fix all the problems in 3 weeks... When you&amp;#x27;re dealing with procedural php masquerading as OO, MVC with business logic everywhere it shouldnt be, and abuse of inheritance such that you cant throw an error in a command line because you&amp;#x27;re not a logged in browser user, who&amp;#x27;s had their language queried from a database, and doesnt fall back to default when the db isnt there... 3 weeks isnt gonna cut it!&lt;p&gt;Introducing peer review was supposed to sort that, but bad or inexperienced devs didnt know they were doing shoddy work (it met the criteria after all..), and good devs became impediments because so many stories needed redoing. Demoralising.&lt;p&gt;We were probably &amp;quot;doing agile wrong&amp;quot;. But it&amp;#x27;s like a religion: open to interpretation. In my experience it&amp;#x27;s a tool used to extract maximum customer benefit at the expense of the developer&amp;#x27;s soul, under the pretence of &amp;quot;self managing team&amp;quot; - ie. &amp;quot;You brought it on yourself&amp;quot;.</text></item></parent_chain><comment><author>spookthesunset</author><text>&amp;gt; Once said features are implemented, taking the time to &amp;quot;refactor&amp;quot; (read: completely rewrite because the code was so bad) becomes a really hard sell.&lt;p&gt;This should be a hard sell.  The code in production works.  Why does it in need a rewrite?  The fact it needed a rewrite in the first place doesn&amp;#x27;t really reflect on scrum but on poor engineering and management practices.</text></comment>