<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>stingraycharles</author><text>Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines).&lt;p&gt;Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.</text></item><item><author>gbro3n</author><text>Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2 weeks.</text></item></parent_chain><comment><author>elboru</author><text>&amp;gt; Sprints are really just a form of pressure&lt;p&gt;I’ve felt the opposite. My team switched from “Scrum” to “Kamban”. Then after a few months the sensation of having an endless pile of cards, without a time frame, felt overwhelming.&lt;p&gt;In the other hand, having a short lived cycle used to help me manage my time. If for any reason one day I was not able to accomplish much, I knew I still had a few more days to compensate. The same was true for the opposite, I could be really productive a few days and then I could relax for the rest of the sprint.&lt;p&gt;That workflow really worked for me. With Kanaban I feel the pressure to always be “productive”, because I don’t have a clear reference on how “relaxed” I’m (or not), during the week or month.&lt;p&gt;Maybe I just need to find a different reference. I guess my point is that sprints don’t necessarily mean pressure for everyone.</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>stingraycharles</author><text>Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines).&lt;p&gt;Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.</text></item><item><author>gbro3n</author><text>Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2 weeks.</text></item></parent_chain><comment><author>throwaway4aday</author><text>You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it&amp;#x27;s a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who&amp;#x27;s doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading&amp;#x2F;managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.</text></comment>