Merlyn Consult / Insights / Updated October 2026
Scrum that works: from busy sprints to real business value
Scrum is not about more meetings, colourful boards or being faster at everything. It is about learning early, delivering usable improvements and adapting before time and money are wasted.
Experience, then and now
Seeing is believing. Using is understanding.
In the original Merlyn article, written around nine years ago, I described discovering Scrum through business development and software delivery. What stood out was not the terminology: it was the ability to show progress early, involve customers and learn together. That core observation still holds.
What has changed is the way we should explain and apply the framework. In 2026, buyers need practical results, not a ritual checklist. A team can complete every ceremony and still create little value if it builds the wrong thing or hides unresolved quality problems.
The framework, correctly explained
What Scrum actually is
Scrum is a lightweight framework for complex work. According to the current official Scrum Guide (November 2020), it is built on transparency, inspection and adaptation — enabled by a self-managing, cross-functional Scrum Team.
Product Owner
Maximises product value and is accountable for effective Product Backlog management. Clear ordering of work matters more than a long wish list.
Scrum Master
Helps the team and organisation understand Scrum, improves team effectiveness and removes barriers. Not a traditional taskmaster or project secretary.
Developers
All professionals who create the usable Increment — not just programmers. They plan, build quality in and adapt their work toward the Sprint Goal.
Visual guide
One sprint. Five events. One purpose.
A Sprint lasts one month or less. The four other events are opportunities to inspect and adapt within it, not meetings held for their own sake.
Throughout the Sprint: Product Backlog refinement, quality assurance and delivery of one or more usable Increments take place as needed.
Five values, not five slogans
The human foundation
Keep a meaningful goal in view.
Finish work that matters.
Show progress and problems early.
Trust professional expertise.
Challenge assumptions and act.
A business example
Scrum beyond the software team
Imagine a logistics company improving its customer shipment portal. Instead of commissioning one large specification and waiting months, the team works toward one Product Goal: customers can identify and resolve shipment exceptions earlier.
Make exceptions visible
Bring shipment milestones and late-arrival alerts together for a small pilot group. Validate what customers actually need to know — before expanding the solution.
Improve decisions, not dashboards
Use feedback to add actionable explanations, ownership and escalation workflows. Measure whether customers resolve problems sooner, not just how many features shipped.
Illustrative scenario — not a claim about a specific Merlyn client or measured outcome.
What changed since the original article
Keep the good ideas. Retire the outdated rules.
Then: project delivery language
- A prescribed minimum of three Sprints
- “Sprint 0” described as the standard starting phase
- A fixed “final Sprint” devoted to implementation
- A Scrum Master described as the main project controller
- A proxy Product Owner described as a regular role
Now: Scrum as defined
- No mandatory number of Sprints
- “Sprint 0” is not a Scrum event
- A usable Increment may be released before the Sprint Review
- Scrum Master accountability centres on effectiveness and enabling Scrum
- Exactly three Scrum Team accountabilities; delegation does not remove Product Owner accountability
The older practices may reflect a specific contract or delivery approach. They should not be presented as mandatory Scrum rules.
The 2026 management lens
How to tell whether Scrum is helping
A good Scrum implementation gives decision-makers more evidence. It does not guarantee budget certainty, faster delivery or satisfied customers automatically.
Choosing well
Scrum is powerful — and not always the right answer
Use Scrum when…
The work is complex, requirements evolve, stakeholders can provide regular feedback and a cross-functional team can build usable Increments. The value lies in adapting based on real learning.
Consider other approaches when…
Work is repetitive, strongly interrupt-driven or tightly prescribed. Kanban-style flow management, conventional project controls or a hybrid operating approach may suit the situation better. The objective is business performance, not methodological purity.
Merlyn Consult / Practical transformation
Less Scrum theatre. More useful progress.
Merlyn helps organisations align strategy, operational realities, software choices and people. Whether you are improving a digital process or redesigning a service, start with the business problem — then choose the working method that makes progress visible.
Historical context: this article updates the original Merlyn Consult publication “Scrum Efficiently and Successfully”, including the author’s experience and the original acknowledgement to Osman Akdemir. The presentation of Scrum roles and events has been aligned with the official Scrum Guide rather than earlier project-specific conventions.
Source: The Scrum Guide (Schwaber & Sutherland, November 2020) — current official version as checked in October 2026.