<story><title>Agile&apos;s early evangelists wouldn&apos;t mind watching Agile die</title><url>https://builtin.com/software-engineering-perspectives/lean-agile-methodology-software-engineering</url></story><parent_chain><item><author>plughs</author><text>My first team, some 14 years ago, had the best experience with Agile.  What made this work&lt;p&gt;&amp;gt; During planning, everyone understood that the estimates were _estimates_.  Tasks could take longer or shorter, that was OK and even expected.  The goal was to improve velocity, not to accomplish every story, every time.&lt;p&gt;&amp;gt; Engineers felt comfortable taking stories in areas they knew nothing about. A stated goal was that every engineer understand every piece of the project.&lt;p&gt;&amp;gt; Standups were team only. Engineers felt comfortable saying they got stuck or needed help or got lost in a rathole and didn&amp;#x27;t make the progress they hoped.&lt;p&gt;&amp;gt; Demos were important so that the team and the clients could understand what had changed and what new features were available.&lt;p&gt;But it quickly got lost - managers and PMs and Directors got involved and Jira boards became published for all to see. (In the beginning it was whiteboards and sticky note).  Standups and Demos were all about self-promotion.  No one ever wanted to take on a task they weren&amp;#x27;t 100% certain they could do.  If a task was 3 point it needed to be done in 3 days or there would be questions.&lt;p&gt;When I left the last company it had gotten outrageous. Every task should be completed in three days and in production in five days - and if not that team was Doing Something Wrong.&lt;p&gt;( We were told that this was standard FAANG practice, I have no idea how true that was )&lt;p&gt;What happened was what you&amp;#x27;d expect - shortcuts, tech debt, unit tests cynically design to pass and meet code coverage expectations instead of actually usefully testing.&lt;p&gt;The reality is that any process is going to fail one senior leadership decides it&amp;#x27;s a way to evaluate engineers, not create a good product.</text></item></parent_chain><comment><author>marktangotango</author><text>A looong time ago I went through Army basic training. As a BS degree holder I was given the job of &amp;quot;book man&amp;quot;. This meant I carried around the platoon training book and carried placards to put in signs at various training locations that told what battalion, company, and platoon we were so if anyone driving by a gun range, motor pool, or classroom could look and see oh that&amp;#x27;s 1st platoon, C company, 1st training battalion.&lt;p&gt;I&amp;#x27;ve come to believe that that main driver for Agile adoption has come to be something similar. Making visible to outsiders what software development teams are doing, and making progress (or it&amp;#x27;s lack) visible to management. I thinks that&amp;#x27;s a completely reasonable expectation. Businesses are paying exorbitant salaries and providing ping pong tables, why shouldn&amp;#x27;t they have visibility into what&amp;#x27;s being done?&lt;p&gt;Where it becomes toxic is in areas this posts parent indicates; posturing, one upsmanship, pressure to perform. Effective teams need &amp;quot;safe spaces&amp;quot; to learn, discover, try and fail. Agile isn&amp;#x27;t that anymore. Hasn&amp;#x27;t been for a long time.</text></comment>
<story><title>Agile&apos;s early evangelists wouldn&apos;t mind watching Agile die</title><url>https://builtin.com/software-engineering-perspectives/lean-agile-methodology-software-engineering</url></story><parent_chain><item><author>plughs</author><text>My first team, some 14 years ago, had the best experience with Agile.  What made this work&lt;p&gt;&amp;gt; During planning, everyone understood that the estimates were _estimates_.  Tasks could take longer or shorter, that was OK and even expected.  The goal was to improve velocity, not to accomplish every story, every time.&lt;p&gt;&amp;gt; Engineers felt comfortable taking stories in areas they knew nothing about. A stated goal was that every engineer understand every piece of the project.&lt;p&gt;&amp;gt; Standups were team only. Engineers felt comfortable saying they got stuck or needed help or got lost in a rathole and didn&amp;#x27;t make the progress they hoped.&lt;p&gt;&amp;gt; Demos were important so that the team and the clients could understand what had changed and what new features were available.&lt;p&gt;But it quickly got lost - managers and PMs and Directors got involved and Jira boards became published for all to see. (In the beginning it was whiteboards and sticky note).  Standups and Demos were all about self-promotion.  No one ever wanted to take on a task they weren&amp;#x27;t 100% certain they could do.  If a task was 3 point it needed to be done in 3 days or there would be questions.&lt;p&gt;When I left the last company it had gotten outrageous. Every task should be completed in three days and in production in five days - and if not that team was Doing Something Wrong.&lt;p&gt;( We were told that this was standard FAANG practice, I have no idea how true that was )&lt;p&gt;What happened was what you&amp;#x27;d expect - shortcuts, tech debt, unit tests cynically design to pass and meet code coverage expectations instead of actually usefully testing.&lt;p&gt;The reality is that any process is going to fail one senior leadership decides it&amp;#x27;s a way to evaluate engineers, not create a good product.</text></item></parent_chain><comment><author>wpietri</author><text>Totally. &amp;quot;When a measure becomes a target, it ceases to be a good measure. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Goodhart%27s_law&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Goodhart%27s_law&lt;/a&gt;&lt;p&gt;And as you say, managerial involvement is the problem. Managers and execs mostly get paid to appear to be in control, so having the appearance of control is vital to them, even if that makes the results wildly worse.</text></comment>