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.
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.
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.
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.
One of the reasons that we stopped caring is because planning is impossible. You could plan very well and leave 20% capacity, and then get a ton of new requests in the middle of the sprint so need to replan(we leave that to personal judgments).
Can’t blame it on the clients though because they genuinely can’t plan.
My conclusion is, if my team is facing clients that can’t plan properly, don’t bother plan anything for your own team.
Yes, it sounds very familiar. Scrum is not really designed for this mode of operation. It works well when there are no interruptions, and the team knows the code and domain area inside out.
To be honest, I was only once in this situation. It was when I worked with a small team on a greenfield project. We knew the whole codebase, and the project wasn't deployed to clients yet - so no surprises during sprints.
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.
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.
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.
We just stopped caring about sprint objective and pushed everything unfinished to the next sprint. Upper management wants sprints so we keep the form.
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.
One of the reasons that we stopped caring is because planning is impossible. You could plan very well and leave 20% capacity, and then get a ton of new requests in the middle of the sprint so need to replan(we leave that to personal judgments).
Can’t blame it on the clients though because they genuinely can’t plan.
My conclusion is, if my team is facing clients that can’t plan properly, don’t bother plan anything for your own team.
Yes, it sounds very familiar. Scrum is not really designed for this mode of operation. It works well when there are no interruptions, and the team knows the code and domain area inside out.
To be honest, I was only once in this situation. It was when I worked with a small team on a greenfield project. We knew the whole codebase, and the project wasn't deployed to clients yet - so no surprises during sprints.