Run a mock round

Common anti-patterns usually dress up traditional management as agile.

Zombie Scrum: the ceremonies happen but there is no real self management or working software. The Daily Scrum becomes a status report to the Scrum Master or manager. Story points get treated as a productivity metric and compared between teams. A Product Owner acts as a proxy for a committee with no real authority over priorities. The Sprint Review becomes a demo with no stakeholder feedback, or the retrospective produces actions that are never followed up. No refinement until mid sprint leads to unclear stories and spillover.

I address these by naming the behaviour, connecting it to the underlying purpose it defeats, and coaching rather than blaming. I use data such as cycle time, carry over and defect rates, and I ask the team what these patterns cost them. Improvement sticks when the team owns it.

The Product Owner and the Scrum Master are different roles with different accountabilities.

The Product Owner owns the value of the product. They manage the product backlog, define and order items, set priorities and make sure the team is building the right thing. They act as the voice of the customer and stakeholders.

The Scrum Master owns the Scrum process. They coach the team and the organisation in Scrum, facilitate the events, remove impediments, and help the team improve. They are a servant leader, not a project manager and not a boss.

In one line: the Product Owner focuses on what and why, the Scrum Master focuses on how the team works and removes obstacles.

A common anti-pattern is combining both roles in one person, which creates a conflict between pushing scope and protecting the team's sustainable pace. They should be distinct.

A good retrospective is safe, focused and produces a small number of owned actions.

I set the stage and remind everyone of the prime directive: we assume good intent and focus on the system, not individuals. I choose a format that fits the mood, such as start stop continue, what went well and what did not, or a data driven review of the sprint board and metrics.

I gather input individually or in writing first, so quieter people contribute and louder voices do not anchor the discussion. Then we group themes and vote on the ones that matter most.

We discuss the top one or two in depth and agree concrete actions with an owner and a date. I limit the number so they actually happen.

I record actions where everyone can see them and review them at the start of the next retrospective. A retrospective without follow through quickly becomes theatre.

I start from curiosity, not accusation. Silence usually has a cause: they may feel the ceremonies are pointless, be overloaded, lack psychological safety, or simply prefer written communication.

I would speak to them privately and ask what would make the meetings useful for them. Often the answer reveals a team level problem rather than a personal one.

Then I address the cause. If the Daily Scrum feels like a status report, I refocus it on the Sprint Goal and make it a conversation among developers. If a few people dominate, I use structured formats or written input first. If they are overloaded, we look at workload with the Product Owner.

I also make participation expectations clear and give them a meaningful role, such as owning refinement for a feature.

Persistent disengagement after that is a performance conversation, but that is the last step, not the first.

I surface it early rather than hoping. Transparency is more valuable than protecting appearances, and late surprises are worse than early honesty.

First I look at why. Is scope larger than estimated, did an unexpected defect or incident absorb capacity, did someone leave, or was there a dependency we did not control? The cause determines the response.

In the Daily Scrum I raise the risk and propose options: reduce scope to the most valuable items that still meet the Sprint Goal, or renegotiate the Sprint Goal with the Product Owner if the goal itself is no longer achievable. I never quietly carry unfinished work as if it were done.

After the sprint I bring it to the retrospective and look for a systemic fix: better refinement, smaller stories, more buffer, or addressing the dependency. Repeated misses usually point to a process problem, not lazy work.

Scaling Scrum is a problem of coordination, not of adding more Scrum. The first question is whether scaling is needed, because more layers often slow delivery.

I keep teams small, autonomous and aligned to a product or value stream, with clear ownership so they can release independently where possible. I avoid component teams that hand work across boundaries.

For coordination I use a shared Product Goal and a light synchronisation cadence, a Scrum of Scrums or similar forum focused on dependencies, risks and integration, not status reporting. I make dependencies visible on a shared board and design interfaces early.

I invest in engineering practices: continuous integration, automated testing and a definition of done that includes integration, because scaling without technical excellence fails.

Frameworks such as LeSS, SAFe or Nexus can provide structure, but the principles matter more than the brand. I scale gradually and measure flow.

Story points estimate relative size, not time. They combine effort, complexity and uncertainty compared with other backlog items.

I use planning poker. The team discusses each item, asks clarifying questions, and simultaneously reveals a card from a sequence such as Fibonacci. Disagreement is useful because it surfaces hidden assumptions, so I ask the highest and lowest estimators to explain their thinking. We re vote until we converge, without forcing false consensus.

I anchor estimates with a reference story the team agreed on. A three point story is roughly three times the size of a one point story, but that says nothing about hours.

Points are for the team's own forecasting, not for comparing teams or measuring individual productivity. Velocity is a rough guide for how much to take into a sprint, and it should never be used as a performance target.

Both are agile approaches, but they differ in structure and flow.

Scrum works in fixed length sprints with a committed Sprint Goal and a defined set of events and roles: Product Owner, Scrum Master and Developers. Work is planned and reviewed each sprint, and change within a sprint is limited.

Kanban is continuous. There are no required sprints or roles, and work flows through stages on a board. Its core practices are visualising the workflow, limiting work in progress, managing flow and making policies explicit. It is often better for support, operations or teams with unpredictable incoming work.

Scrum is stronger when the team needs regular cadence, prioritisation and a clear goal. Kanban is stronger when work arrives continuously and cycle time matters more than sprint commitments.

Some teams blend them, using a Scrum cadence with Kanban's work in progress limits and flow metrics.