<story><title>I don’t believe in sprints</title><url>https://www.robinrendle.com/notes/i-don’t-believe-in-sprints/</url></story><parent_chain><item><author>hurril</author><text>This is nothing but a bad strawman from start to finish.&lt;p&gt;Sprints are not made to help organize things, they&amp;#x27;re a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability.&lt;p&gt;This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.&lt;p&gt;Nobody has to like it, this is probably not the best method and maybe it&amp;#x27;s not even good. But the author misses the point completely.</text></item></parent_chain><comment><author>xxEightyxx</author><text>It&amp;#x27;s all about how everything is implemented. I&amp;#x27;ve worked in places where sprints were hard deadlines and there was no acceptable reason for missing said deadlines. We worked 12-15 hour days, including working weekends to try and meet our release schedules.&lt;p&gt;Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.&lt;p&gt;We engineers had two business analysts, a scrum master, and two managers that resided &amp;quot;above&amp;quot; us in rank all working to keep the &amp;quot;flow&amp;quot; of the sprints alive to help ensure we meet our deadlines.&lt;p&gt;It was the most stressful tech job&amp;#x2F;environment I&amp;#x27;ve ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours.&lt;p&gt;Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it&amp;#x27;s inception.&lt;p&gt;I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six.&lt;p&gt;Sprints&amp;#x2F;agile&amp;#x2F;scrums are generally a good thing IF and ONLY IF you have a capable manager&amp;#x2F;scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.</text></comment>
<story><title>I don’t believe in sprints</title><url>https://www.robinrendle.com/notes/i-don’t-believe-in-sprints/</url></story><parent_chain><item><author>hurril</author><text>This is nothing but a bad strawman from start to finish.&lt;p&gt;Sprints are not made to help organize things, they&amp;#x27;re a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability.&lt;p&gt;This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.&lt;p&gt;Nobody has to like it, this is probably not the best method and maybe it&amp;#x27;s not even good. But the author misses the point completely.</text></item></parent_chain><comment><author>PaulHoule</author><text>I&amp;#x27;ve worked in places where the cycle to integrate work was more than six months.  In a situation like that you often don&amp;#x27;t really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months.&lt;p&gt;It is true though that springs bring in their own problems.  For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database&amp;#x2F;a.i. model.  This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time.  If you didn&amp;#x27;t start the database build early enough you would predictably blow the sprint.&lt;p&gt;At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint.&lt;p&gt;Another problem is how you organize work that has a pipeline structure.  Is a tester expected to test work in the same sprint it is being developed in?  What does a developer do when a feature is under test?&lt;p&gt;What really kills teams is a lack of trust.  With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks.  I think sprints are popular with some because it gives developers some space to be inflexible,  but it is harmful for the business.  Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.</text></comment>