7 min read
We Do the Scrum Events, but Delivery Hasn't Improved. What Should Leadership Do?
When the stand-ups, Sprints and retrospectives all happen and results do not move, the cause is usually above the team. Five things leaders should check first.
If your teams run every Scrum event and delivery has not improved, the cause is usually not the teams. Look at what sits above them: whether leaders agree on priorities, whether dependencies and shared people are sorted out, whether a real Product Owner decides what gets built, and whether leaders look at working results and act on what they see.
The five checks, in order:
- Is everything “Priority #1”?
- Who de-conflicts the dependencies and the shared people?
- Is there a real Product Owner, or a Product Owner Proxy?
- Does anyone who matters come to the Sprint Review?
- Is working product delivered by the end of every Sprint?
I’m Michael Vizdos, a Certified Scrum Trainer® (CST) since 2006, one of the first 25 in the world. My Certified ScrumMaster license is #72, one of the first 75 ever issued (my Scrum Alliance profile). I have watched situations like this play out for 35+ years, and the pattern is consistent enough to give you a checklist.
What does it look like when every event runs and nothing changes?
It looks like Agile in name only. The stand-ups happen, the Sprints have names and the retrospectives produce sticky notes. Underneath, the organization is still running mini-waterfalls:
- Work moves through a chain of hand-offs, and every hand-off is a dependency on another group.
- There are dozens of projects, and every one of them is “Priority #1”.
- Individual people, often called “resources”, are assigned to several teams at once, so no team ever has its whole team.
I have seen this at more than one client, and at prospective clients who called me before it got that far. The teams are not the problem. They are doing what the system asks of them.
The events run, but they cannot do their job. A retrospective can surface that a dependency is blocking the team, yet the team cannot remove it. Someone with authority across the groups has to, and without that person the organization drifts back to its old habits.
That is process theater: the roles, the rituals and the Sprints are present, and the decision-making that is supposed to follow them is missing. When leadership does not step in, align as a First Team and give the teams political cover, nothing below them can fix it.
What should leadership check first?
Go through these in order. Each is something leaders can look at this week.
1. Is everything “Priority #1”?
If every project is top priority, none of them is. Teams pick whatever is loudest, and people are split across work that all claims to come first.
Ask each of your direct reports to write down the top three priorities for the quarter. If the lists differ, the teams are getting mixed direction. Then apply the 80/20 rule (the Pareto principle): a small share of your projects will account for most of the value. Find that share, protect it, and hold the rest until capacity frees up. This is the most common cause I find, and it is why my advisory work starts at the executive team.
2. Who de-conflicts the dependencies and the shared people?
The most common blocker I see that only leaders can remove is dependencies between teams, including the same person assigned to several teams. A Scrum team can name the dependency in its retrospective. It cannot decide that another group will change its schedule, or that a person will belong to one team.
This is why leaders need to work as a First Team: peers who sort out conflicting demands together, so the teams do not each fight the same battle. Pick one dependency that has shown up in the last three retrospectives and have a leader own it by name.
3. Is there a real Product Owner, or a Product Owner Proxy?
The Product Owner is the one person accountable for maximizing the value of the product. I often find a Product Owner Proxy instead, and it takes two forms:
- The Business Analyst in the role. They write the stories and run the meetings, but they are powerless to say no and cannot make decisions. Every real decision goes to someone else, so the team waits.
- The IT-side Product Owner. This person comes from the technology group, not from the business or operations, so they are not a true Product Owner. They make technical assumptions with no real customer problem behind them, inventing solutions to problems that do not exist. The team builds exactly what was asked for and nobody wanted it.
The second form is a common anti-pattern, and it is how a team can deliver on time and still deliver nothing of value. Ask who owns the order of the Product Backlog, and whether they could say no to a senior leader today. For the full picture, read Our Product Owner Can’t Make Decisions. What Is Going On?
4. Does anyone who matters come to the Sprint Review?
When leaders and outside stakeholders, including internal and external customers depending on your setting, are not in the room, the Sprint Review turns into a check-the-box exercise. It becomes a “demo” in name only.
The point of the Sprint Review is feedback on Done work that meets the Sprint Goal and moves toward the Product Goal. Without people who can react to the work, the team learns nothing and the next Sprint starts where the last one did. Attend one, and say out loud what you would change.
5. Is working product delivered by the end of every Sprint?
I make sure people deliver a working Increment by the end of each Sprint. I have worked with Sprints of one hour, one day, one week and two weeks. The Scrum Guide puts a ceiling on the Sprint:
“They are fixed length events of one month or less to create consistency.”
Many organizations think even a month is too short and stretch the Sprint past it. Then come the Sprint 0s, which are mini-waterfalls with a new name. Work expands to fill the time available, so nothing gets delivered. If your Sprints run longer than a month, or end without something usable, that is your answer.
This matters more now. With AI, the old “software factory” (another name for Waterfall) is coming back into vogue. In my view that is a mistake: short cycles that end in working product are how you get the benefit of AI without the risk. If you want to talk about using AI and Scrum together to Focus. #deliver, use the contact link at the end of this page.
Is it the teams after all?
Sometimes. Check these before you decide it is all above the team:
- The team never had real training. Skills gaps are what a class fixes, and it fixes them well.
- The team is new to Scrum and has not had time to settle.
- One event is broken, such as a retrospective that never produces an action. The Scrum Event Tune-Up is a $297 asynchronous review of a recording of that one event.
If none of these fit, look up the organization, not down. Not sure whether you need training or outside help? Read Do We Need an Agile Consultant, or Just Better Training?
What does the fix look like?
A senior executive at one of the world’s largest banks brought me in on a risk-reduction project. The team had failed regulatory audits, and fines and federal scrutiny were on the table. Nine months in, a project team of over 100 people had produced status reports, not a working solution.
We reorganized around a single cross-functional team of about ten, using Scrum’s roles, events and artifacts. (The full story, with the client’s own words, is on my consulting page.) They delivered something real by the end of the first Sprint, and within three months the full solution shipped. The team did not need more ceremony. It needed a structure where the people deciding and the people doing were close enough to act on what they learned.
What can leaders do this week?
- Ask each direct report for their top three priorities, and compare the lists.
- Pick one cross-team dependency and name the leader who owns removing it.
- Find out who owns the Product Backlog order, and whether that person can say no.
- Attend one Sprint Review, and say out loud what you would change.
- Check whether the last Sprint ended with something usable.
What next?
Not sure whether this is your situation? Send me two or three sentences about what is stuck, and I’ll tell you honestly whether I can help, or whether it is something you can fix yourselves.
- Leadership or system is the problem: executive advisory
- The team needs skills: private Scrum training
- It is about you as a leader: 1:1 mentoring
For why a First Team of peers is not always enough, read You built a First Team. So why is leadership still misaligned? Learn more on my services page.
Who wrote this?
I’m Michael Vizdos. I started in software delivery at EDS in 1991, so I have 35+ years in this work. I have been a Certified Scrum Trainer® since 2006 and have trained 4,900+ Scrum Masters and Product Owners since 2006, from about 1,500 organizations. More about my background.
Weekly, free, no fluff
Get one actionable Scrum idea a week.
Saturday morning emails on Implementing Scrum in the real world — the same cartoons and straight talk that built this site.
Subscribe — It's FreeStuck on something specific? Email me your situation.
