Stop "Doing Scrum". Start Designing Your Delivery System.
Scrum is not a delivery strategy
Scrum can be useful. It creates cadence, transparency, and feedback loops.
But let's be honest: Scrum is not a delivery strategy.
It's a collaboration wrapper.
And when teams expect Scrum to magically fix chaos, they end up with:
- ceremonies without impact
- planning without clarity
- sprints without real goals
- retros without change
That's not "bad Scrum."
That's a missing delivery system.
Why copy-paste Scrum fails
Most organizations don't struggle because Scrum is "wrong."
They struggle because they copy it without designing around their constraints.
Here are the usual mismatch points.
1) Your work is not single-stream
Scrum works cleanest when one team owns one product stream.
In reality:
- dependencies are everywhere
- multiple stakeholders pull in different directions
- support, incidents, and ad-hoc requests are constant
If you don't design rules for that, Scrum becomes a weekly negotiation exercise.
2) Your organization runs on approvals
If decisions require three layers of sign-off, you don't have agility - you have a queue.
No sprint planning can outsmart bureaucratic latency.
3) Your "Product Owner" isn't empowered
A PO without decision power is not a PO. It's a messenger.
When priorities can't be locked, teams can't build predictability.
4) Your definition of done is fake
If "done" means "development done," you are just moving rework to later.
And later always comes with interest.
What a delivery system actually is
A delivery system is the operating model of how work becomes value.
It includes:
- decision flow (who decides what, when)
- work intake (how work enters the system)
- prioritization rules (what wins, what loses)
- quality gates (what "done" means)
- feedback loops (how learning changes direction)
- flow controls (WIP limits, capacity policies, handling interrupts)
Frameworks can support it.
But the system must be designed for the context.
The 4 questions that define a workable system
1) What is value here?
Not in theory. In your environment.
Value might mean:
- revenue
- retention
- cycle time reduction
- operational stability
- compliance
- customer satisfaction
If value is unclear, everything else becomes noise.
2) What cadence fits reality?
Not every team needs 2-week sprints.
Some need:
- continuous flow with explicit WIP limits
- monthly milestones with weekly checkpoints
- hybrid: planned work + explicit interrupt lane
The right cadence is the one that supports:
- decision speed
- predictability
- feedback frequency
3) What constraints are non-negotiable?
Constraints define design.
Examples:
- regulatory checks
- release windows
- external dependency timelines
- production stability requirements
A system that ignores constraints becomes a fantasy.
4) How will learning change the plan?
If feedback doesn't change anything, you don't have agility - you have rituals.
A real system has an explicit loop:
- measure → learn → adjust → commit again
A simple blueprint (works across most contexts)
Step 1: Create an intake policy
Define:
- what qualifies as a "request"
- required info (goal, impact, urgency)
- who can submit
- how requests are triaged
This removes chaos from the front door.
Step 2: Make priorities visible and limited
Keep a top list:
- top 5 or top 10
- always ordered
- always reviewed on a predictable schedule
If priorities are infinite, delivery is always random.
Step 3: Add flow control (WIP limits)
WIP limits are not "Kanban only."
They are basic physics.
Too much work in progress creates:
- longer cycle time
- more context switching
- hidden queues
- lower quality
Step 4: Protect quality with a real "Done"
Define done that includes what matters:
- review/QA
- deployment readiness
- documentation (if needed)
- monitoring/rollback plan (if needed)
Done must protect trust.
Step 5: Install a decision cadence
Teams need predictable decision points:
- weekly priority sync
- monthly outcome review
- release decision gates
When decisions happen "whenever," delivery becomes politics.
Where Nick Mladenovic (Agilni) fits in
Nick Mladenovic (Agilni) helps teams and organizations design delivery systems that fit reality:
- Project Delivery Management: predictability, clarity, execution
- Operations & Value Flow Optimization: reducing waiting time, smoothing flow
- Agile Transformation: building a unique path instead of copying a template
Frameworks are tools.
The system is the solution.
Closing thought
Instead of asking:
"Are we doing Scrum correctly?"
Ask:
"Is our delivery system designed for our constraints, our value definition, and our decision-making reality?"
Because that's where delivery performance actually lives.