Agile Methods We Use

Overview

We use agile methods pragmatically. The chosen method must fit the work, team, customer environment and phase.

We commonly combine:

• Scrum-style sprint delivery

• Kanban-style flow management

• Lean thinking

• user-centred design

• service design

• technical spikes

• prototyping

• continuous delivery practices

Scrum-Style Delivery

Scrum-style delivery works well when a team can plan work in short iterations.

Typical sprint length:

• 1 week for fast-moving discovery or alpha work

• 2 weeks for most product and software delivery

• 3 to 4 weeks only where customer governance or dependency cycles require it

Core sprint practices:

• sprint planning

• daily stand-up

• backlog refinement

• show and tell

• retrospective

• sprint review or governance review

Kanban-Style Delivery

Kanban-style delivery works well where work arrives continuously or where support, live service improvement or operational tasks need steady flow.

Kanban practices include:

• visible board

• work in progress limits

• clear workflow states

• explicit policies

• cycle time measurement

• blocker management

• continuous prioritisation

Lean Thinking

Lean thinking helps us remove waste and focus on value.

Examples of waste include:

• building features without validated need

• waiting for decisions

• duplicating evidence

• producing documentation nobody uses

• handoffs without ownership

• over-engineering too early

• fixing defects that could have been prevented

User-Centred Design

User-centred design ensures services are shaped by evidence from users and their context.

This includes:

• user research

• journey mapping

• service blueprinting

• usability testing

• accessibility consideration

• content design

• assisted digital needs

Technical Spikes

A technical spike is a time-boxed investigation used to reduce uncertainty.

Use a spike where the team needs to answer a question such as:

• Can this integration work?

• Is this technology suitable?

• What is the data quality like?

• What are the security constraints?

• Can the system meet performance requirements?

• What is the simplest viable architecture?

A spike must have:

• a clear question

• a timebox

• expected evidence

• decision criteria

• documented outcome

Prototyping

Prototypes are used to learn. They are not automatically production assets.

Prototype types include:

• paper prototype

• clickable prototype

• content prototype

• data prototype

• technical proof of concept

• integration prototype

• service simulation

Prototype rules:

• make the learning goal explicit

• keep the prototype as simple as possible

• do not confuse prototype code with production code

• record what was learned

• decide whether to continue, change direction or stop

Method Selection

Select the method based on:

• uncertainty level

• delivery phase

• team size

• customer governance needs

• supplier involvement

• technical complexity

• release frequency

• operational risk

• assurance requirements

Default Method Pattern

Our default pattern is:

• Discovery: user-centred research, service design, technical discovery and short Kanban flow

• Alpha: prototypes, technical spikes, user testing and short sprint cycles

• Beta: Scrum-style product build with release planning and assurance gates

• Live: Kanban-style continuous improvement with roadmap-based planning

• Retirement: controlled transition plan with governance checkpoints