One of the main ideas put forward by Thomas is that the generic agile principles are basically a reflection of gradient descent: take a small step in the direction you think you should go, evaluate the value of doing so and the error generated, then repeat. For a well-posed problem, you&#x27;ll converge without taking huge steps generating tons of short term inefficiency.<p>Real world Agile is effectively like taking this gradient descent idealization espoused by the agile creators and turning it into <i>simulated annealing</i> instead -- a vastly slower, dumber optimization method with no guarantees about avoiding local extrema.<p>This analogy carries you pretty far. It&#x27;s all the extra political, bureaucratic, micromanagerial stuff that creates the effect of <i>random</i> displacements, as in simulated annealing, instead of <i>calculated</i>, <i>deterministic</i> displacements as in real gradient descent. (And hooking up user and customer feedback as a major driver for the displacements is one of the worst failure modes for this.)<p>For me, the trouble is that &quot;real agile&quot; (i.e. the &quot;good&quot; and &quot;not manipulated&quot; principles) doesn&#x27;t provide any mechanism for explicitly preventing this kind of political subversion. It&#x27;s just too easy for middle managers and bureaucrats to subvert for their own purposes, while shoving all the negative externalities of doing so onto lowly developers.<p>I don&#x27;t particularly like Agile because I don&#x27;t think one-size-fits-all approaches will ever work (e.g. every sprint must be 2 weeks long, every workflow must involve story points, etc.).<p>But if I had to think about a way to vindicate Agile and protect it from subversion, I would suggest it needs some kind of explicit statement that short-term business concerns are not valid excuses for modifying the process. Of course, then managers won&#x27;t like it ... because they <i>only</i> like things that give them metric surface area with which to politically manipulate the situation for their changing agenda, and so Agile would become impossible to sell to huge companies.<p>It&#x27;s a Catch-22. Actually good software dev practices that make money, make customers happy, and live up to quality standards instead of just paying lip service to them are completely at odds with executives and managers who want to torch the commons for the sake of short term bonuses and couldn&#x27;t give two shits about whether it makes customers unhappy, etc. (because they will have secured blame insurance against that anyway, and may even make more money from endless irrational tech re-orgs).