agile delivery

Agile delivery: what could wait so the important work can finish?

In Tuesday’s post, I explored why agility needs boundaries: clarity about what we protect and what we can change.

Now consider what happens when those boundaries meet a difficult deadline.

There is more work left than the team can realistically finish. What changes next?

Make scope the conversation

DSDM offers a deliberate approach: protect time, cost and the agreed quality standard, then vary the features delivered.

Try bringing that thinking into your next planning conversation.

My new book is available: What kind of problem is this?

Book cover for What kind of problem is this? It shows an illustration of the Cynefin framework: four domains, clear, complicated, complex and chaotic. — *My new book’s cover*

I’m delighted to say that my new book, What kind of problem is this?, is now available to buy from Lulu.

The full title is What kind of problem is this? A Scrum Master’s field guide to using Cynefin in real team situations.

It is a practical book for Scrum Masters, Agile Coaches, Product Owners, delivery leaders and anyone who works with Scrum but has sometimes wondered why the same practices work beautifully in one situation and fall flat in another.

When rhythm matters more than velocity

Previously, I argued that Scrum events create coherence, not control.

This is where that idea becomes practical.

Because there are moments in team life when speed is not the real problem. The real problem is loss of rhythm.

The team is busy. Work is moving. People are under pressure. But the usual patterns that help everyone stay aligned have started to break down.

Conversations become reactive.
Priorities shift too often.
Decisions happen too late or in the wrong place.

In those moments, trying to speed up usually makes things worse.

What helps is restoring rhythm.

How to influence when slowing down is the right move

One of the harder parts of being a Scrum Master is this: sometimes you can see that a team needs to slow down, but managers or stakeholders want the opposite.

That is understandable.

From the outside, slowing down can look like reduced effort.
But in practice, reducing overload is often how delivery improves.

The key is not to argue for ‘slowing down’ in the abstract.

It is to help people see that too much work in progress, too many competing priorities and too much pressure to start work are often the very things that stop work from finishing.

When slowing a team down increased delivery

One of the most important agile lessons I have learned is that speed does not always come from going faster.

Sometimes it comes from slowing the system down.

I saw this in a Scrum team that was struggling to finish work. On paper, we looked reasonably disciplined. We were following Scrum well enough. We had two-week sprints, like other teams in the organisation. But our delivery told a different story.

When I checked the Jira data, our cycle time for backlog items ranged from one day to 35 days.

That meant some work was taking up to seven weeks to get through the system.

For a team working in two-week sprints, that was a warning sign.

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31