Delivery Methodology: what it is and how to measure it

Ask a team how it works and you get a method name: Scrum, Kanban, a stage-gate plan, or "we just talk". Ask the same team whether the way of working actually helps and you get a longer pause. Delivery Methodology measures the second answer. It does not care which method a team uses. It asks three questions about whatever the method is: does it fit, is it followed, and does it get better.

The definition, in plain language

Delivery Methodology evaluates the team's processes, tools and workflows for planning, executing, documenting and coordinating work. In the Team P&L it sits in the Process pillar, because a way of working is something the team does, not something it is given. Two teams with the same tools and the same template can score very differently.

The three questions are a useful way to read the KPI, so the rest of this explainer follows them.

1. Does the method fit?

Hackman (2002) listed an enabling structure among the conditions that make a team effective: work designed so the team can do it well, norms that guide conduct, and a composition that fits the task. A method is part of that structure. Two-week sprints fit a team that ships software in increments and misfit a team whose work arrives as unpredictable requests; a detailed project plan fits a construction schedule and misfits a research group. The first sign of a poor fit is a growing stack of exceptions: "we do sprints, except for urgent things, except for the platform work, except in quarter-end."

Marks, Mathieu and Zaccaro (2001) added a point that is easy to miss: teams move between transition phases, where they plan and set goals, and action phases, where they execute and monitor. A method has to serve both. Many teams plan well and coordinate badly, or the reverse, and the KPI's items are written to catch both halves.

2. Is it followed?

A method that lives in a wiki and not in the week has no effect on performance. The review by Mathieu, Maynard, Rapp and Gilson (2008) treats team processes as the mediators between what a team has and what it delivers: processes are the mechanism, so a process nobody runs mediates nothing. In practice, "followed" shows up as predictable rhythms. Planning happens when it is supposed to, hand-offs include what the next person needs, the tracking board matches reality closely enough that nobody keeps a private list.

3. Does it get better?

The teams that score highest on this KPI are not the ones with the most mature method. They are the ones who changed something about it in the last month. A retrospective that produces an action, a tool that was replaced because it created more clicks than it saved, a meeting that was shortened or cancelled: these are what the Deep-Dive item "We regularly improve our processes" is looking for.

A week in two teams

• Monday planning. High: the team leaves with a short list it believes in and knows who owns what. Low: planning overruns, the list is a wish list, and two people quietly plan to ignore it.
• Wednesday hand-off. High: the hand-off is a message with the context attached and the receiver starts within the hour. Low: the receiver books a meeting to find out what was meant.
• Friday status. High: the board already says it, so the meeting is ten minutes and mostly about decisions. Low: the meeting is the status, and it is forty minutes of reading aloud.
• Any day, a new request. High: everyone knows where it goes and when it will be looked at. Low: it goes to whoever was asked, and the method is bypassed again.

How PEAKTEAMS measures it

The Snapshot survey asks two statements, one for planning and one for coordination, each answered on a five-point agreement scale.

The Deep-Dive survey adds thirteen items in its Delivery & Feedback module: twelve positively phrased statements covering workflows for common tasks, tools and systems, documentation, progress tracking, hand-offs, coordination with other teams, meetings, standards and process improvement, plus one reverse-scored statement, "Our way of working creates more overhead than it saves." The reverse item is there to catch the team that agrees with everything on principle.

The KPI score is the mean of its items, and the Consensus Matrix plots each of those items against how much the team agrees on it. For this KPI the agreement axis is often the more interesting one: a split on its items usually means the method works for one role and not for another, for instance for the people who plan and not for the people who execute. Results appear only once at least five team members have answered; the owner's own answer does not count.

How to improve Delivery Methodology

1. Write down the one route a piece of work takes from request to done, because a method that exists in three versions is not a method, and the act of writing it exposes the exceptions.
2. Cut the exceptions before adding anything new, because every "except when" is a place where the method is already not followed.
3. Make the tracking board the single source of truth and retire the private lists, because coordination through shared tools only works when the shared tool is trusted to be current.
4. Define what a hand-off must contain, because most coordination cost is the receiver reconstructing context the sender already had.
5. End every retrospective with one process change and a date, because improvement is a habit the items measure directly, and a retrospective without a change is a status meeting.
6. Review meetings by asking what decision each one produces, because the Deep-Dive item on productive meetings is usually the lowest in this KPI and the easiest to move.

Related KPIs

Delivery Methodology is the process twin of two other KPIs. Team Organization, in the Input pillar, covers who does what; this KPI covers how the work moves between them, and a low score on one often explains a low score on the other. Team Output is the result the method is supposed to produce: a high method score with a low output score means the team runs a process that is not pointed at the right thing. Feedback & Development shares the Deep-Dive module with this KPI, because the retrospective is where process improvement actually happens.