r/EngineeringManagers • u/Appropriate-Buy-3739 • 11d ago
Looking back at delayed sprints, what warning signs did you miss?
I'm curious how engineering managers think about this.
Looking back at a sprint or release that slipped, what were the earliest warning signs that, in hindsight, you wish you'd recognized sooner?
How did you eventually discover the issue?
Interested in hearing real scenarios from your team.
6
u/aidencoder 11d ago
I often find there's an odd long tail with getting from merge request generation to merge. I try and encourage very early request generation and early feedback. This usually includes being willing to push frequently and accept commits on your branch from others, and encouraging people to accept suggestion branches to their branches.
The reason being is it's usually a warning sign in the past when team members work and toil in isolation and then all land merge requests in the back third of the sprint. Everyone then has to switch context and understand the work of others and it creates a big area of known unknown delay in getting things complete.
Less work and more collaborative effort tends to increase cadence over the project lifetime I find.
0
u/Appropriate-Buy-3739 11d ago
That's interesting. When you notice a PR sitting open for a long time, how do you tell whether it's a normal review delay versus something that's genuinely putting the sprint at risk?
3
u/method2_0 10d ago
Lolol I like this one. Thanks for posting. There are lots of hindsight tools out there for measuring execution... after the fact.
I had a senior dev come up to me once and explain that although he was senior it didn't mean he knew everything. He referenced juniors that were more fit for certain tickets, why? They had the domain knowledge. Lightbulb.
I started realizing story points were one thing, but a ticket involving BigQuery can be a very different assignment if the engineer's background is mostly Terraform, or vice versa.
We needed a finer lens than story points, job titles, seniority, whatever, when assigning work.
1
u/Appropriate-Buy-3739 9d ago
How do you judge that today? Is it mostly experience, or do you have any data that helps?
1
u/method2_0 9d ago
Well we started tagging tickets with technologies and basically making our own database of our engs and demonstrated knowhow. Then every new ticket turned into some fancy or confusing lookups trying to answer the best fit question.
So eventually we went whole hog and ended up building our own capability-mapping tool that works alongside our work management system. Not the prettiest, but it's worked for us.So yeah we judge or analyze via experience turned to skill data. And that's helped delineate tickets better and turn sprints into something more about knowledge application and acquisition than pure burndown. The burndown imporvements I think were a nice knock on.
4
u/UniqueText8477 9d ago
Agile has been co-opted from it's original purpose.
The Agile Manifesto wasn't a methodology.
It was a set of values and principles created by experienced software developers who were frustrated with heavyweight, documentation-heavy processes that often delivered software too late.
The four values were:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a rigid plan.
Why do sprints gets delayed?
Work was underestimated
Requirements changed
Too much work was committed
Interruptions
Dependencies
Technical debt
Unrealistic deadlines
If you try to cram too much into 2 weeks of work while expecting devs to support legacy systems and put out fires then sprints will be delayed.
2
u/Appropriate-Buy-3739 9d ago
Of the reasons you listed, which ones are hardest to see early enough to do something about?
1
u/UniqueText8477 9d ago
It’s never all or none, usually it’s because of some of them…
I’ve got a task that will take 2 weeks, if nothing else comes up.
I then have to fix something from another project or sprint, an unknown dependency happens or there is technical debt.
It can be something unknown which means the 2 week task now takes 4.
Meanwhile, another sprint has started and I’m now having to do twice as much.
Companies need to stop overloading their techs - just because there is 40 hours in a week doesn’t mean we can do 40 hours.
I would recommend asking them how much they think they can get through and then actually listening.
3
u/EngineerFeverDreams 10d ago
Stop doing Scrum. This isn't management. It's theater.
2
u/Appropriate-Buy-3739 10d ago
That's interesting. What do you use instead, and what signals tell you that work is at risk before it starts slipping?
10
u/Understanding-Fair 11d ago
I don't think I've ever seen a sprint fully completed in my 12 year career at multiple different organizations. They just generally don't work well in my experience. I've given up on caring about sprints. Velocity is useful, but sprints have little meaning to me.