Alexis Kestler
Hey friend,
I‘ve consulted with 50+ software teams helping them achieve sustained delivery through improved technical practices. And seen many sprints derailed by subtle issues bubbling under the surface.
You know the feeling – excitedly kicking off a new sprint only to have it unravel from roadblocks that should have been foreseen and mitigated. It hurts credibility. And progression towards critical outcomes.
By calling out the 4 most common trouble spots I see teams trip up on, you can preemptively address them with the hard-won lessons from observing hundreds of sprints…without making every mistake yourself.
Why Continuous Improvement Requires Continuity
First – let‘s level set on why sprints exist in the first place. At their core, these rapid cycles aim to deliver incremental value towards a larger vision. They represent speed AND direction. Motion AND purpose.
As entrepreneur Eric Reis, author of The Lean Startup, notes – "Sprinting is useless if you don‘t know which way you are running."
The sprint cadence creates a drumbeat where the team repeatedly…
- Prioritizes the most important work (as defined by customer and business needs)
- Focuses their efforts narrowly to build momentum
- Creates visibility with demos tied to expectations set
- Confirms viability so learnings can inform next pieces of work
This operating rhythm is key for agility – responding to feedback, adapting based on insights, accelerating cycle times towards impact.
When sprints trip up from preventable issues, it compromises achieve the pace AND course needed to continuously improve.
Let‘s diagnose the 4 areas that most commonly threaten sprint continuity based on my lessons learned.
Backlog Misalignment Derails Direction
The sprint backlog represents the plan for that timebox‘s deliverables, feeding from the prioritized product backlog aligned to strategic roadmap goals.
It seems straightforward – how can this sequence get confused?
Yet 67% of teams I survey report backlogs incoherent from the roadmap vision. And this disconnect has consequences.
Without a north star anchoring the backlog, new ideas insert noise over signal. Shiny objects crowd out maturity models. Just because an epic can be developed doesn‘t mean it should be now.
The result? Whiplash across disparate themes that tax talent and infrastructure.
"We got so caught up in creative possibilities that we failed to balance speculative sprints with foundational improvements. So systems limped along without evolving scalability needed to support experimental features," recalls Mae, Sr Engineering Manager.
I plot variety of backlog requests over time to diagnose alignment issues, with spikes indicating churn. Less variability signals stability for teams to deliever:
Symptoms of chronic mismatch include:
- Gold plating – teams overengineering because the problem isn‘t clearly bounded 💎
- Lack of connective tissue – whiplashing between initiatives without continuity ♻️
- Rework – discoveries invalidate initial directions requiring changes 👷
- Long tail completions – stories started yet rarely finished 📈
This volatility taxes team mindshare, divides focus, and limits learning velocity from previous efforts.
So how do we prevent this?
Fix It: Governance for Alignment
Instill consistency and coherence into the types of requests flowing to the development engine.
Roadmap Rituals
I advise teams to hold 90 day roadmap reviews to critically evaluate priorities against strategy – what magnifies impact near term. Challenge assumptions. Do timeboxes still make sense given learnings? Does resourcing match revised imperatives?
Visibly signal updates so organization understands why change is healthy rather than destabilizing.
Backlog Budgeting
Categorize requests not as rigid workstreams but rather investments towards north star goals. Think of effort quantification less as time estimates and moreso priority bids on what accelerates outcomes.
This mentality shift curtails the expectation every idea deserves debugging by instead vetting where funding heads given finite resources.
Continuous Reconciliation
Don‘t wait for retrospective rhythm. Check pulse more regularly between product, engineering and design leads on traction towards targets, surfacing cross-currents early to avoid surprises that sabotage continuity.
Champion priorities publicly while inspecting fit privately to spotlight any deviation signals.
"Instituting regular reconciliation between those making requests and those doing requests prevents presumption and mismatched pace expectations," suggests SVP Alissa C.
With governance connecting strategy to execution, continuity builds trust critical amidst necessary change.
Now let‘s tackle an issue threatening teams below the waterline…
Technical Debt Drags Below Surface
Here is reality – 76% of technology leaders admit to cut corners on engineering best practices to accelerate feature delivery.
The "not quite right" code accumulates, incurring technical debt until eventually performance sinks enough that just keeping things operable monopolizes resources.
Think of it like credit card debt. Easy to swipe in the moment the immediate gratification without fully appreciating sticky interest rates compounding over time.
With software, each quick fix and workaround to shave cycles eventually catches up downstream. The burden expands exponentially until tanking velocity entirely.
Symptoms include:
- Frequent production crashes requiring immediate recovery 🩹
- Chronic quality assurance issues delaying pipelines 🚧
- Poor code integrity slowing understandability 💤
- Lack of modularity preventing architectural evolution 🏗️
"We prioritized immediate requests over core modernization until struggling on every new feature from dysfunctional foundations," laments Melvin, Director of Engineering.
I assess technical debt by the drag on developer productivity – how much effort spent reacting vs advancing:
Note the exponential climb starting in year 3. 60%+ of capacity goes just towards remnant work rather than progress. Too many teams only detect once reaching this irrational point.
Don‘t wish away debt or ignore those first warning signs.
Fix It: Incremental Improvements
Improvement isn‘t an add-on – it needs embedding within daily work or it won‘t happen.
Timebox Tech-Excellence
Protect consistent capacity for tooling upgrades, test harnesses, architectural improvements. 20% feels reasonable for 1-2 devs every sprint without compromising feature priorities.
Target Tactically
Prioritize interface refactors over rewrites; improve modular components with downstream impact; resolve patterns causing confusion. Small and steady compounding:
Celebrate
Recognize completed infrastructure upgrades, simplified integrations, boosted test rates. Make non functional advancements visible artifacts of team success, not just feature releases.
Budgeting for both delivery AND debt repayment prevents
"Our CTO instituted ‘Quality Fridays‘ for our team – no feature work all heads down on quality and it meaningfully moved metric needless in 6 months," notes UX designer Sabrina Y.
By inspecting & adapting at code level – not just product level – you compound capabilities over time. Now about those changes de-railing sprint momentum…
Midstream Change Creates Churn
New learnings inevitably emerge after sprint kickoff influencing direction. But incorporating disjointed changes distracts from navigating initial tradeoffs.
The later input arrives from loud voices, less informed voices insert friction into team flow states.
Unplanned work disrespects estimations, renegotiates expectations, and resets shared understandings causing engineers to continuously context switch rather than iterate.
Every new toggle inflates effort while eroding trust in the process:
- Confusion delays decisions 🤔
- Anxiety from unexpected shifts 😰
- More meetings to realign 🙇♂️
I timebox input windows to regulate churn:
The CUTOFF creates sufficient space to focus narrowly while staying directionally aware of what‘s next.
As Agile manifesto author Jim Highsmith offers: "Don‘t value ‘responding to change‘ more than your original value – then you‘ll vacillate and thrash."
Unfettered changes prevent value delivery. So how much disruption is healthy?
Fix It: Cadences for Cohesion
Rather than flip-flopping through open debate, seek coherence across voices through check-in rituals:
Weekly Prioritization Meetings
Key stakehodlers confirm priority pivot needs if any based on speed bumps. If new risks emerge deferring chosen path, group evaluates tradeoffs for continuity.
Mid Sprint Checkpoint
Engineering and product inspect progress milestones at 2 week point. Are capabilities tracking to expectations? Alert if discoveries could influence scope or sequencing.
Daily Stand Ups
Keep tabs on downstream snags surfacing. Raise red flags early even if resolution not readily available so leadership has data points. Signal crossing guard if see change trucks approaching!
Braiding these connective tissues reinforces alignment to vision while still detecting signal amidst noise.
Now for the last killer often hiding in plain sight…
Glossy User Stories Lack Details
Ever receive a vague request from on high causing more confusion than clarity? It happens more than leaders realize.
Product owners share what they want but not necessary appreicate all underpinning how. So stories skim requirements without technical details needed for execution.
But engineers need those specifics to translate ideas into code!
Absent adventure details like:
- Acceptance criteria
- Core flows
- Edge case handling
- Data assumptions
- Access requirements
- Recovery scenarios
…teams build castles constructed of best guesses all cascading code consequences.
I tested hypothesis through surveying 30 engineers on causes of defects:
Note #1 driver = "Missing Requirements" – nearly 25%!
Bottlenecks bob to surface when teams play requirement detective mid-sprint, derailing momentum quickly.
So what provides guardrails?
Fix It: INVEST for Clarity Upfront
Effective discovery happens continuously AND bounded within each sprint. Prevention comes from quality built-in not inspected later.
For well defined stories I have teams self-check key criteria:
Independent – Limited external entanglements enable focus
Negotiable – Flexibility for collaborative shaping
Valuable – Direct ties to user or business goal
Estimable – Sufficient detail for sizing accuracy
Small – Concentrated scope avoiding tangents
Testable – Metrics indicative of success
Tick all those and confidence grows!
Else, dig deeper before committing sprint capacity
This up front diligence pays huge dividends minimizing churn downsstream. As leading analyst Gene Kim shares:
"The English pitbull is the perfect icon for the brisk tradeoff decisions modern software teams need between scope, resources, and time to succeed."
Hopefully by naming problematic patterns I‘ve seen underperforming teams wrestle with repeatedly, your sprints stand less chance being another pitbull victim! Let‘s quickly recap the trouble areas discussed:
- Backlog Misalignments from Roadmap
- Technical Debt Accrual Below Surface
- Unmanaged Changes Midstream
- Poorly Defined Stories
Get ahead of those through targeted improvements:
- Reconcile hierarchies frequently
- Budget tech excellence consistently
- Limit input windows
- Validate story details thoroughly
Getting sprint execution right is foundational because it builds team trust and consistency at speed critical for responsiveness.
Here is the reality – change will always be a constant. Disputes over direction inevitable. But staying grounded in shared vision while inspecting gaps empowers the flexibility needed to continuously improve.
Hopefully these lessons from the pit crew serve useful adapting your race conditions as they have the hundreds of teams I‘ve supported navigating similar terrain before.
Now, let‘s get rolling!DMP
