We spent more than a year failing nearly every single sprint goal. It was beyond frustrating. Our estimates were constantly wrong because our understanding of the system was just incomplete. Something we thought was a 5-point story would turn into a 20-point monster once we actually got into the code.
We were stuck in this vicious loop where the pressure to hit a sprint goal meant we never had time to fix technical debt or automate repeated requests. We’d rush to finish, skip the refactor, and create the same bugs that would then derail the next sprint. It felt like we were just doing performance theater with all the planning and pressure.
We eventually just quit Scrum. We dropped the sprint commitments and moved to a simple weekly prioritization with continuous delivery. We kept the dailies and retros, but replaced the long planning sessions with a Friday check-in.
Delivery sped up. We went from shipping about once a month to releasing several features every single week.
Technical debt decreased. Without the sprint promise, the team finally started addressing the root causes of our interruptions instead of just putting out fires.
Focus time increased. We used to have half the team stuck fire-fighting on a bad week. Now it is usually just one person monitoring the system while the rest of the team actually gets to work.
christophilus•1h ago
Yeah. Basically how I’ve been running my projects for the past 5 years. My philosophy is: process should be as minimal as possible. Don’t add structure / friction to a thing until it solves some real, experienced pain.
romannikolaev•1h ago
When work is connected to outcomes—when you can see how your efforts contribute to the business - there’s a natural tendency to focus on the most important things and approach them in the most effective way.
I suppose the larger the organization, the more difficult this becomes to achieve.
markus_zhang•1h ago
We just stopped caring about sprint objective and pushed everything unfinished to the next sprint. Upper management wants sprints so we keep the form.
romannikolaev•1h ago
To be fair, I have the advantage of being part of the leadership :) (CTO at a startup).
I think this style of delivery is fine as long as both management and the teams are comfortable with it. The only thing that frustrates me in this setup is the agile theater - planning, estimating, and refinement.
romannikolaev•1h ago
We were stuck in this vicious loop where the pressure to hit a sprint goal meant we never had time to fix technical debt or automate repeated requests. We’d rush to finish, skip the refactor, and create the same bugs that would then derail the next sprint. It felt like we were just doing performance theater with all the planning and pressure.
We eventually just quit Scrum. We dropped the sprint commitments and moved to a simple weekly prioritization with continuous delivery. We kept the dailies and retros, but replaced the long planning sessions with a Friday check-in.
Delivery sped up. We went from shipping about once a month to releasing several features every single week.
Technical debt decreased. Without the sprint promise, the team finally started addressing the root causes of our interruptions instead of just putting out fires.
Focus time increased. We used to have half the team stuck fire-fighting on a bad week. Now it is usually just one person monitoring the system while the rest of the team actually gets to work.
christophilus•1h ago
romannikolaev•1h ago
I suppose the larger the organization, the more difficult this becomes to achieve.