Leader vs Scrum Master, what is the difference between a Scrum Master and an Agile Coach?
Scrum Masters and agile leaders do a lot of the same work: observing, coaching, removing impediments, and cultivating the environment where agility can actually grow. The main differences are about reach — leaders walk the Gemba of value creation and consumption, connect funding to learning, and use their power to clear the obstacles Scrum Masters can't. Done right, the line between the two starts to blur — and that's a good thing.
Who is responsible for a scrum team's performance?
Developers build the product. The product owner sets the direction. So when a scrum team is struggling, whose name is on the line? Since the 2020 Scrum Guide, the answer is clearer than it used to be — and it has real implications for how scrum masters show up, intervene, and work beyond the team itself.
Most conversations about value stop at the organization — revenue protected, costs reduced, market share grown. But societal value is a legitimate dimension too, and the UN's 17 Sustainable Development Goals offer a practical way to bring it into how you order your backlog. The catch: only the authentic version counts, because greenwashing wastes the energy you could have spent delivering something genuinely better.
Who Writes the Acceptance Criteria?
You might assume the product owner writes acceptance criteria. They shouldn't — and when they do, a predictable dysfunction creeps in. Here's why the people doing the work should own what "done" looks like, and what the product owner should be doing instead.
When there's more unknown than known, committing to a Gantt chart that has everything wrapped up by Christmas isn't planning — it's theatre. But "we don't know when we'll be done" rarely lands well with stakeholders, and if you leave a vacuum, they'll fill it with a date they invented themselves. Monte Carlo probabilistic forecasting offers a middle path: still honest about uncertainty, but structured enough to give stakeholders something they can actually work with.
Constraints, work capability, throughput and flow
A long queue for pizza at a rainy English festival turned into an unexpected lesson in flow. The team at the stall was deliberately slow at taking orders, perfectly coordinated through each step, and careful never to take on more work than their slowest stage could handle. That's a lesson most knowledge work teams haven't quite learned yet — and it's why so many of them feel constantly overloaded.
How do you measure value in scrum?
How do you measure value on a major IT infrastructure project? Start by admitting that "value" itself is a loaded word — organizational, market, societal, risk-reduction, and learning value are all different things, and most teams conflate them. And then accept the harder truth: until something is actually released and in someone's hands, there's nothing real to measure, and proxy metrics like story points will quietly take over to fill the vacuum.
Trust and its impact on the definition of done in scrum
When a Definition of Done stretches to 30 items, most people stop reading it, stop respecting it, and stop improving it. The usual instinct is to make it shorter by cutting items — but the real problem usually isn't the list at all. It's trust, and until you address that, adding or removing items won't change much.
In scrum who is responsible for engaging the stakeholders?
The buck stops with the product owner when it comes to stakeholders — customers, end-users, compliance, suppliers, and the wider organization all fall under that remit. But that doesn't mean the product owner should be doing it alone. Developers should be connecting directly with customers, the scrum master should be negotiating with other teams and shaping how compliance gets demonstrated, and the whole team should be having honest conversations about who owns what.