Resources

When delivery feels slow or unpredictable, changing the framework can look like decisive action. It can also hide the real problem. Scrum and Kanban are useful options, but neither is the point. The point is to understand what prevents valuable work from moving from a clear need to a reliable result.

Run a short health check before reorganising roles, ceremonies or boards. Two working weeks is usually enough to observe normal delivery without turning the exercise into a large review. Tell the team that the aim is to learn, not to score people. Use existing meetings and work records where possible.

Days 1–3: establish direction and ownership

Take a small sample of current work. For each item, ask what outcome it supports, who can make priority decisions and who can accept the result. Note where goals are broad, priorities compete or decisions wait for somebody outside the team. If people are busy but cannot explain which outcome matters most, the first need may be clearer product priorities rather than a new delivery method.

Days 4–7: follow the work

Trace each item from request to completion. Record active work separately from queue and wait time. Look for repeated hand-offs, work started without enough information, too many items in progress and specialist stages that regularly form a queue. Capture blockers with their cause, owner and age. A board may show activity while concealing that most elapsed time is spent waiting.

Review feedback loops too. How soon do users, operational colleagues or decision-makers see something testable? What happens when feedback changes the need? Late feedback, unclear acceptance and large batches often create more delay than the framework itself.

Days 8–10: examine risk and decide

Bring the evidence together in a one-page view: the goal, decision delays, work-in-progress, queue time, common blockers, feedback points and significant risks. Include dependencies, control requirements and operational readiness. Avoid turning a small sample into a universal claim; use it to identify the next sensible experiment.

• Choose coaching when the method is understood but habits, collaboration or facilitation are preventing consistent use.
• Choose clearer product priorities when goals conflict, decision rights are vague or work enters faster than priorities can be settled.
• Choose process changes when evidence shows persistent queues, hand-offs, oversized batches or controls placed too late in the flow.

Agree one or two changes, an owner and a date to review the same measures. That may mean refining Scrum, using selected Kanban practices or simplifying a local workflow. Treat the framework as a tool. Keep the diagnosis tied to outcomes, flow and risk.

This is a general delivery diagnostic, not an assessment of any particular organisation or team.

A regulated team should not begin a generative AI rollout by giving everybody a tool and asking them to experiment. Start with one bounded use case, the information it needs and the controls required when its output is incomplete, wrong or inappropriate. The objective is not adoption for its own sake. It is a defensible decision about whether a tool improves a defined task without creating unacceptable risk.

Set the boundary first

Describe the task narrowly: for example, creating a first-pass summary of an approved internal document. Identify the users, the current manual steps and the point where a person remains accountable. Classify the data involved. State what may be entered, what must be removed or masked and what must never leave an approved environment. Use only authorised tools with understood data retention, access and supplier terms.

Bring legal, compliance, information security and the operational owner into the design early. Their role is not a final approval queue. They should help define acceptable use, records, oversight and escalation before testing begins. Requirements will depend on the organisation, jurisdiction, data and professional duties.

Evaluate one task with human accountability

Build a representative test set that can be used lawfully. Decide what good looks like before running it: factual accuracy, omitted points, unsupported statements, tone, time saved and the effort needed for review. Compare the AI-assisted route with the existing baseline. An accountable person must check every output during the trial and retain authority to reject or rewrite it.

Include failure cases, not just demonstrations that work. Test ambiguous instructions, missing context and material that should be refused or escalated. Record model and configuration changes where they can affect results. A promising average is not enough if a low-frequency failure could cause serious client, legal or operational harm.

Prepare controlled use

• Train users on the approved purpose, prohibited data, verification duties and how to report a concern.
• Create a clear incident route for accidental disclosure, harmful output, unexpected tool behaviour and control failure.
• Measure useful adoption rather than log-ins: suitable tasks completed, review effort, quality, exceptions and reasons people stop using it.
• Track ongoing licence, usage, assurance, support and review costs alongside any time saved.

Set a decision date. Continue only if the evidence supports the use case and the control owners are satisfied with their responsibilities. Pause if data boundaries are unclear, review cannot be sustained or the quality gain does not justify the cost and exposure. Wider rollout should be a new decision, not an automatic consequence of a limited trial.

This practical guide is general information, not legal or compliance advice. It does not certify that a tool, process or organisation meets any regulatory requirement.