<story><title>My 20-Year Experience of Software Development Methodologies</title><url>https://zwischenzugs.wordpress.com/2017/10/15/my-20-year-experience-of-software-development-methodologies/</url></story><parent_chain><item><author>kenshi</author><text>Methodologies are a trap. The problem with any methodology is they tend to lead people to stop thinking about the context they are operating in.&lt;p&gt;&amp;quot;The methodology says X, we should do X, why oh why aren&amp;#x27;t we doing X?&amp;quot; is a familiar lament in the development world. I have been there and done that, to be sure.&lt;p&gt;It really isn&amp;#x27;t going to matter what the Methodology says, if something or someone in the context means it isn&amp;#x27;t being adhered to.&lt;p&gt;If the person ultimately paying for the project isn&amp;#x27;t convinced by the Methodology, or wants to deviate from it badly enough, guess what? The Methodology will be ignored.&lt;p&gt;You should always advocate for what the Right Thing To Do(tm) is, but you should ask yourself first: what is the most important criteria that determines what the Right Thing is?&lt;p&gt;&lt;i&gt;Sometimes&lt;/i&gt; writing the quickest, hackiest, throwaway code can be the Right Thing. It can be a horrifying truth for a software developer. Sometimes doing the ballsy re-write is the Right Thing. Sometimes letting a project fail is the Right Thing.&lt;p&gt;Sometimes last weeks context and decisions no longer apply.&lt;p&gt;More critical to project (and personal) success than any Methodology is gaining a thorough understanding of the context in which you are working in, as quickly as you can. And then doing all the Right Things that will make you effective within those constraints.&lt;p&gt;This means there is no Single Truth for software development. No easy answers. But there are a wide variety of principles you can draw from and apply and &lt;i&gt;discard&lt;/i&gt; as needed.&lt;p&gt;Or as Bruce Lee put it: Be like water.</text></item></parent_chain><comment><author>agentultra</author><text>This is what I call, &lt;i&gt;development by a dozen managers&lt;/i&gt;.&lt;p&gt;If you have every developer on the team on the look out to do The Right Thing then you be sure that you&amp;#x27;ll start replacing your decision-making strategies with whimsical fancy.&lt;p&gt;A collective fiction, or methodology if you will, isn&amp;#x27;t supposed to replace individual thought with adherence to the all-powerful methodology. I&amp;#x27;m suspicious of sales people with a vested interest in the methodology they&amp;#x27;re selling. A methodology isn&amp;#x27;t something you can purchase... the collective fiction metaphor is apt: you have to convince people to believe and adopt it.&lt;p&gt;In my experience a team will adapt a methodology like Agile but the best teams will mold it to the way they do things. Their collective fiction needs to integrate their tribal knowledge, goals, experience, etc. There isn&amp;#x27;t Agile™ — there&amp;#x27;s &lt;i&gt;Agile the X way&lt;/i&gt;.</text></comment>
<story><title>My 20-Year Experience of Software Development Methodologies</title><url>https://zwischenzugs.wordpress.com/2017/10/15/my-20-year-experience-of-software-development-methodologies/</url></story><parent_chain><item><author>kenshi</author><text>Methodologies are a trap. The problem with any methodology is they tend to lead people to stop thinking about the context they are operating in.&lt;p&gt;&amp;quot;The methodology says X, we should do X, why oh why aren&amp;#x27;t we doing X?&amp;quot; is a familiar lament in the development world. I have been there and done that, to be sure.&lt;p&gt;It really isn&amp;#x27;t going to matter what the Methodology says, if something or someone in the context means it isn&amp;#x27;t being adhered to.&lt;p&gt;If the person ultimately paying for the project isn&amp;#x27;t convinced by the Methodology, or wants to deviate from it badly enough, guess what? The Methodology will be ignored.&lt;p&gt;You should always advocate for what the Right Thing To Do(tm) is, but you should ask yourself first: what is the most important criteria that determines what the Right Thing is?&lt;p&gt;&lt;i&gt;Sometimes&lt;/i&gt; writing the quickest, hackiest, throwaway code can be the Right Thing. It can be a horrifying truth for a software developer. Sometimes doing the ballsy re-write is the Right Thing. Sometimes letting a project fail is the Right Thing.&lt;p&gt;Sometimes last weeks context and decisions no longer apply.&lt;p&gt;More critical to project (and personal) success than any Methodology is gaining a thorough understanding of the context in which you are working in, as quickly as you can. And then doing all the Right Things that will make you effective within those constraints.&lt;p&gt;This means there is no Single Truth for software development. No easy answers. But there are a wide variety of principles you can draw from and apply and &lt;i&gt;discard&lt;/i&gt; as needed.&lt;p&gt;Or as Bruce Lee put it: Be like water.</text></item></parent_chain><comment><author>jrs95</author><text>What’s worked best for me is basically ‘agile’ but without a lot of what I consider to be the bullshit. Project manager and&amp;#x2F;or team lead prioritize new cards as they come in, and developers just keep working on them. No sprints, just keep pulling work out of the backlog as needed. Stand ups and most meetings can be replaced with quick updates via Slack, otherwise they can be organized as needed (they usually aren’t). We had agreed that estimation was mostly a pointless waste of time, so we stopped doing it.</text></comment>