<story><title>Scrum disempowers developers</title><url>https://www.lambdacambridge.com/blog/how-scrum-disempowers-developers-and-destroys-agile</url></story><parent_chain><item><author>nickelcitymario</author><text>Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own.&lt;p&gt;The fact that there is so much B.S. in Scrum doesn&amp;#x27;t mean that it has nothing of value to offer, though.&lt;p&gt;Here&amp;#x27;s what I get out of it:&lt;p&gt;1. Sprints are a better way to organize than Waterfalls. I&amp;#x27;ve experienced this over and over again personally, so I&amp;#x27;m sold on this.&lt;p&gt;2. It&amp;#x27;s important to stop what you&amp;#x27;re doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.&lt;p&gt;3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user.&lt;p&gt;Okay, so that&amp;#x27;s 3 ideas. It&amp;#x27;s better than most.</text></item></parent_chain><comment><author>wpietri</author><text>I think you are entirely right that the &amp;quot;sell books and consulting&amp;quot; is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;agilefocus.com&amp;#x2F;2011&amp;#x2F;02&amp;#x2F;21&amp;#x2F;agiles-second-chasm-and-how-we-fell-in&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;agilefocus.com&amp;#x2F;2011&amp;#x2F;02&amp;#x2F;21&amp;#x2F;agiles-second-chasm-and-how...&lt;/a&gt;&lt;p&gt;One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that&amp;#x27;s where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum.&lt;p&gt;I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a &amp;quot;certification&amp;quot; program, where a) anybody wanting a career bump could spend 2 days to get a &amp;quot;Master&amp;quot; certificate without taking any test or proving any competence, and b) any &amp;quot;consultant&amp;quot; wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes.&lt;p&gt;If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It&amp;#x27;s instead to make managers and executives &lt;i&gt;feel&lt;/i&gt; like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare &amp;quot;mission accomplished&amp;quot;.&lt;p&gt;And my point here isn&amp;#x27;t &amp;quot;Scrum bad&amp;quot;, really. There are some great people in the Scrum world. My point is, &amp;quot;Business models shape outcomes, so be careful which you pick.&amp;quot;</text></comment>
<story><title>Scrum disempowers developers</title><url>https://www.lambdacambridge.com/blog/how-scrum-disempowers-developers-and-destroys-agile</url></story><parent_chain><item><author>nickelcitymario</author><text>Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own.&lt;p&gt;The fact that there is so much B.S. in Scrum doesn&amp;#x27;t mean that it has nothing of value to offer, though.&lt;p&gt;Here&amp;#x27;s what I get out of it:&lt;p&gt;1. Sprints are a better way to organize than Waterfalls. I&amp;#x27;ve experienced this over and over again personally, so I&amp;#x27;m sold on this.&lt;p&gt;2. It&amp;#x27;s important to stop what you&amp;#x27;re doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.&lt;p&gt;3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user.&lt;p&gt;Okay, so that&amp;#x27;s 3 ideas. It&amp;#x27;s better than most.</text></item></parent_chain><comment><author>mmusson</author><text>My experience is that a good team does a good job. A bad team doesn’t.&lt;p&gt;I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice.&lt;p&gt;There are no quick fixes. People can improve but it takes time, dedication, and support.</text></comment>