Agile Delivery Assessment

Fidelity

Framework Fidelity

Whether the framework you name is the one you are running, and whether its roles carry real authority.

How closely does what you actually do match the framework you say you use? We use the vocabulary; the practices underneath are our own Some ceremonies run, others were dropped without anyone deciding to Mostly as designed, with local variations nobody has written down As designed, and the variations we made were deliberate and recorded As designed, and we revisit the variations when they stop earning their place Not applicable to us

What authority does the person prioritising the work actually hold? None; priorities arrive from elsewhere and are not negotiable They can sequence the work but not change what is on the list They can say no, and it gets overturned often enough to notice They own the backlog and are backed when they decline something They own the backlog and the outcome, and are accountable for both Not applicable to us

A stakeholder wants something added mid-sprint. What happens? It goes in; the sprint is a label rather than a commitment It goes in, and something else quietly falls out It goes in after a conversation, and the trade is made explicit It waits for the next sprint unless it is genuinely urgent It waits, and urgent exceptions are rare enough that we can name the last one Not applicable to us

Who updates the items on the board as work progresses? A delivery manager or PMO, on the team's behalf One person in the team, usually the day before a report is due Some of the team, some of the time The people doing the work, at least daily The people doing the work, as they work, and the board is trusted because of it Not applicable to us

Flow

Flow & Cadence

How often working software reaches the people who use it, and how long one piece of work takes to get there.

How often does working software reach real users? Every few months, as a release event Roughly monthly, with a freeze and a plan around it Every sprint, give or take Weekly or more often, without it being an event On demand, several times a day when the work is ready Not applicable to us

Could you say how long a piece of work takes from starting it to it being live? No, and we have never measured it Roughly, from memory Yes, for some teams, if somebody pulls the report Yes, and it is on a board the team looks at Yes, and we know its spread rather than just its average Not applicable to us

How many things is one person working on at a time? Several; everybody is on two or three at any moment More than we would like, and nothing limits it One main thing, with interruptions One thing, with an explicit limit on the board One thing, and we treat a breach of the limit as a problem to solve Not applicable to us

How big is a typical piece of work when a team picks it up? Whatever size the request arrived in; we do not break work down Large; one item often spans a whole sprint or more Mixed, and the large ones cause most of the trouble Small enough to finish inside a sprint, nearly always Small enough that finishing within a few days is normal Not applicable to us

Backlog

Backlog & Readiness

Whether work arrives specified well enough to start and small enough to finish.

When a team picks up an item, how often must they go and find out what it means? Almost always; the item is a title Often, and it is accepted as how things are Sometimes, usually on the larger items Rarely, because refinement happens before anything is picked up Rarely, and when it happens we treat it as a refinement failure Not applicable to us

Is there an agreed definition of done, and does it bind? No It exists somewhere; nobody could recite it Yes, and it is applied loosely when there is pressure Yes, and it holds, including under pressure Yes, it holds, and it has been deliberately tightened over time Not applicable to us

How is the backlog structured above the level of a single task? It is a flat list of requests Two levels at most, applied inconsistently We have epics and stories, and where things sit is often arbitrary A consistent hierarchy: epic, feature, story, task, used as intended A consistent hierarchy we actually plan and report from, at every level Not applicable to us

Is there an agreed definition of ready, and does it stop work starting? No; work starts when somebody asks for it One exists somewhere, and work starts regardless Informally; an experienced team member would push back Yes, and items that do not meet it go back Yes, it holds, and we track what gets sent back so refinement improves Not applicable to us

Teams

Teams & Dependencies

Whether a team can take something from idea to live without waiting on somebody outside it.

Can a team deliver a typical piece of work without another team doing something first? No; almost everything crosses a boundary Rarely; dependencies are the normal case Usually, though the exceptions are slow Nearly always Nearly always, and we treat a new dependency as a design problem Not applicable to us

How are the teams composed? By specialism, with work passing between them Mostly by specialism, with one or two embedded roles Cross-functional to build, dependent on others to release Cross-functional, including test and release Cross-functional, and they run what they build Not applicable to us

How stable are the teams? People are assigned per project and move constantly Teams re-form every few months Broadly stable, with frequent borrowing Stable, and changes to them are deliberate Stable, and we bring work to teams rather than people to projects Not applicable to us

When a cross-team dependency blocks something, how does it get resolved? Escalation, every time Somebody senior makes a call, eventually A regular forum picks it up within a week or two Teams resolve it directly, and escalation is unusual It is visible on a shared board with an owner before it blocks anything Not applicable to us

Engineering

Engineering Practice

The substrate underneath the framework: what makes finished mean shipped rather than merged.

How much of your testing runs without a person? Almost none; testing is manual Some unit tests, run inconsistently A reasonable suite, run before a release A suite we trust, run on every change A suite we trust on every change, and we fix flaky tests rather than rerun them Not applicable to us

How long does it take to get a one-line change into production? Weeks, through a release process Days, through several approvals A day or two Under an hour, through an automated pipeline Minutes, and we do it often enough to be confident in it Not applicable to us

How long do branches live before they are merged? Weeks or months, and merging is an event we dread A week or two, and conflicts are common A few days About a day; we integrate continuously Hours, and we hold work back with flags rather than long branches Not applicable to us

When a release goes wrong, what happens? Users tell us, and fixing it takes days Users tell us, and we can roll back within a day Monitoring tells us, and we roll back within hours Monitoring tells us quickly, and rolling back is routine It rarely reaches everyone, because we release progressively and can reverse it in minutes Not applicable to us

Planning

Planning, Funding & Governance

How the work is funded and committed, and what delivery is asked to promise upwards.

How is delivery funded? Project by project, each with a business case and an end date Project by project, with a few continuing teams A mix, and the larger items are still projects Teams are funded continuously and work is prioritised into them Teams are funded continuously against outcomes, and the funding moves with the outcome Not applicable to us

What is committed to the business at the start? Scope, date and cost, all fixed Scope and date, with cost flexing quietly A date and a direction, with scope negotiable An outcome and a review point, with scope genuinely open An outcome, a budget, and a cadence of decisions about whether to carry on Not applicable to us

How far ahead does planning genuinely commit teams? Twelve months or more, in detail Six to twelve months, and it is re-planned repeatedly A quarter, with detail that survives about half of it A quarter of direction, and a sprint or two of detail A quarter of intent, reviewed often enough that surprises are cheap Not applicable to us

What does the board or steering group actually see? A status colour and a percentage complete A status colour, plus milestones against the original plan Progress against plan, with some delivery measures alongside Working software, and measures of flow and outcome Outcomes achieved, what was learned, and what we stopped doing as a result Not applicable to us

Improvement

Measurement & Improvement

Whether anything measured changes anything done, and whether retrospectives produce decisions or attendance.

What do you measure about delivery? Nothing consistently Velocity, mostly to compare teams Velocity, and whether dates were met Flow measures: cycle time, throughput, work in progress Flow measures alongside outcome measures, and we act on both Not applicable to us

What happens to the output of a retrospective? There is no output Actions get written down and rarely done One or two get done, usually the easy ones Actions are owned, sized, and picked up alongside the work Actions are owned, and we can point at practices that changed because of one Not applicable to us

Has anything structural changed because of something you measured? No We have discussed it Once or twice, within a team Yes, more than once, including how teams are organised Yes, routinely; we expect measurement to change something Not applicable to us

Is velocity used to compare teams or individuals? Yes, and it is reported upwards Yes, informally, and people know it Occasionally, though we know we should not No; the team uses it for its own planning and nothing else No, and we have replaced it with measures that survive being made public Not applicable to us

About you

A few things that are not scored

None of this affects your result. It tells us how to read it, and it is the part that makes any follow-up conversation useful rather than generic. Skip anything you would rather not answer.

Which framework does the organisation primarily use? Scrum Kanban Scrumban, or Scrum with Kanban practices SAFe, the Scaled Agile Framework LeSS, Nexus or another scaling framework A homegrown model of our own No framework; we deliver in our own way Waterfall or stage-gate, with some agile practices

When was it adopted? Within the last year One to two years ago Two to five years ago More than five years ago It has changed more than once Never formally adopted

Who does the delivery work? Our own employees Mostly employees, with contractors A mix of employees and a delivery partner Mostly a partner or outsourced supplier Several partners

Has the organisation used external agile coaching or a transformation programme? No Yes, currently Yes, within the last two years Yes, more than two years ago More than once

What prompted you to look at this now? Delivery is slower than the business expects A transformation or reorganisation is being considered We are choosing or changing framework A new leader is assessing the current position Cost or headcount pressure on delivery A programme has gone wrong General review or benchmarking

You run the ceremonies. Do they change what ships?

Which areas do you want to assess?