There is no one-size-fits-all approach, but there is a repeatable way to diagnose what is actually slowing delivery. Every team I work with is different, different tools, different org structure, different failure patterns. But the first 30 days follow the same logic: build a shared picture of how work moves, find where it stops, and change the smallest number of things that will have the largest impact. You will leave this article with a week-by-week checklist you can run without buying new tools.
Week 1: Establish Reality, Not Opinions
You cannot improve what you cannot describe, so I start by building a shared picture of how work moves today, before I form any opinion and before I change anything.
The first step is pulling 60 to 90 days of completed work from whatever tool the team uses. From that data I calculate four numbers: median cycle time, 85th percentile cycle time, throughput per week, and average WIP. A common starting point looks something like this: median 9 days, 85th percentile 21 days, throughput 8 items per week, average WIP 22. That tells a story immediately. Twenty-two items in progress for a team delivering 8 per week means the average item competes with 21 others for attention at any given time.
I also watch at least two planning meetings and two standups before I say anything. I am not there to give feedback yet. I am building a model of what the team actually does, not what it thinks it does.
Most teams start with training and new meetings and ceremonies. What works is starting with baseline data and direct observation before changing anything. Training without a diagnosis is decoration. For the metrics that matter most in this baseline, and why velocity should not be one of them, the guide to Agile metrics that actually matter lays out the full case.
Week 1: Map The Work System, Then Find The Queues
Once I have the baseline numbers, I map how work moves from "ready to start" to "done." Not the workflow the team thinks it has, the one the data shows. I look at average time spent in each column of the board over the last 60 days and identify where items spend the most time waiting rather than being actively worked.
It's not unusual to find that 18 of 45 average total days were spent waiting for code review or approval, 40% of total cycle time sitting in a queue, not in active development. The development team thought the slowdown was on their end. The data showed it was in the handoffs.
Most teams focus on individual utilization, who is working at capacity, who is underloaded. What works is making queues visible first. A person can be 100% utilized and still be the wrong constraint. Waiting states, not work states, are where most cycle time is lost.
This queue map becomes the first shared artifact the team and stakeholders can look at without argument. The data made it, not me.
Week 2: Fix The Daily Standup By Making It About Flow
By the end of week two, I want the standup to move work instead of reporting on it. Most standups I observe are structured around people, "I did this, I'm doing that", rather than items. Work that is stuck does not get identified because nobody is looking at the board systematically. The Scrum Master role article covers this in more depth, but the fix comes down to a specific sequence.
I replace the round-robin format with four checks run against the board, in this order:
- Flow check. Read out the top items aging past 2x the median cycle time. If median is 7 days, anything older than 14 days gets named and acted on in 60 seconds. One decision per item: help assigned, scope cut, or item removed.
- WIP check. Call out anyone holding more than two items in progress simultaneously. Ask which one finishes today and whether someone can help.
- Blockers. Any blocked item gets an owner and a next action before the meeting ends. A 24-hour follow-up rule: if the blocker is not resolved by tomorrow's standup, it escalates.
- Pull rule. New work is only pulled when WIP is under the agreed limit. No new items until something finishes.
This takes 10 minutes for a team of 8. It changes what happens in the next 24 hours, which is the only measure that matters.
Week 3: Introduce WIP Limits And Explicit Policies Without Creating Theater
WIP limits are not control. They are a guardrail that reduces context switching and delivery variability. Most teams have seen WIP limits fail, someone puts a number on the board and the team ignores it within a week. That happens because limits without policies are just decorations.
I start with a soft limit in week three. The team agrees in principle not to exceed two items per person, but I do not enforce it with a hard stop yet. The goal is to surface the tension. When someone is at three items and wants to pull a fourth, the conversation becomes visible. I use that visibility to build the habit before codifying the rule.
When teams commit to this approach, WIP often starts falling within the first few weeks. As WIP drops, cycle time tends to follow — though how fast depends on the team's context, dependencies, and how deeply the habit takes hold. Nothing else changed in week three except the team's default behavior when something finished. For the implementation mechanics, WIP limits, aging WIP, and what to watch during the transition, the guide to reducing cycle time covers the detail.
Explicit column policies come in the same week. Each board column gets an entry criteria and an exit criteria. Entry criteria define what must be true before work enters that column. Exit criteria define what must be true to move right. A blocked item rule goes alongside: if an item is blocked for more than 24 hours, it gets surfaced at the next standup. These policies do not require a new tool. They go on a shared doc linked from the board.
Week 4: Lock In A 90-Day Plan Tied To Measurable Outcomes
By week four I have enough data to write a plan that is defensible. Not a roadmap, a small set of system changes with metrics that demonstrate impact. The 90-day plan is structured around four elements.
- Targets. Two metrics, chosen from the baseline. A typical example: median cycle time down 25% from baseline, 85th percentile down 15%. These are not aspirational. They are calibrated to what the data shows is achievable given current variability and throughput.
- Cadence. A weekly 30-minute flow review using the three charts, cycle time scatterplot, aging WIP, throughput run chart, and a biweekly retrospective focused on outliers rather than general sentiment.
- Risk triggers. Explicit replan criteria. If throughput drops 30% week-over-week for two consecutive weeks, or WIP exceeds two items per person for five straight days, we revisit the plan. These are pre-agreed, not reactive.
- Ownership. Each policy gets a named owner: who monitors it, who enforces it, who escalates when it is violated. Without this, policies erode silently.
Most engagements end with vague action items that get forgotten. What works is a concrete 90-day plan that gets reviewed every week against the same three numbers.
If you want to run this diagnostic on your own team and come out of 30 days with a delivery system that is measurable and defensible, that is exactly the work I do. Explore the services page to see how a 30-day engagement is structured, or Book a Strategy Session and I will start with your team's actual data in the first session.