Progress is hard to inspect
Work remains hidden in large technical batches, making feedback late and leaving product assumptions untested.
03 · Delivery stage
Engineering & Quality
Build in reviewable increments while treating maintainability, security, testing, and product behaviour as connected responsibilities.
The context
What this stage helps the team resolve.
Quality develops through clear expectations, sound decisions, careful implementation, review, and evidence. Testing is important, but it cannot compensate for an unclear outcome, hidden edge cases, or a system that the intended team cannot understand and operate.
Quality is deferred
Testing, security, accessibility, performance, and maintainability are treated as final gates rather than inputs to everyday decisions.
Change becomes fragile
Unclear boundaries, limited automated checks, or undocumented context make routine improvements risky and slow.
What the work considers
Keep product, delivery, and ownership connected.
Activities are selected for the project's current questions and risk. A useful process is structured, but never busy for its own sake.
01
Reviewable increments
Deliver coherent slices that can be demonstrated, evaluated, and connected back to acceptance expectations.
02
Engineering discipline
Use proportionate structure, peer review, version control, documentation, and automated checks around important behaviour.
03
Quality strategy
Combine appropriate unit, integration, interface, exploratory, accessibility, security, and performance evaluation.
04
Risk and traceability
Keep material decisions, limitations, dependencies, defects, and release concerns visible to the people responsible.
Potential outputs
Leave the next decision easier to make.
Outputs are agreed around the work and may be lightweight or detailed. Their value comes from supporting action, review, and shared understanding.
- 01Working increments connected to agreed outcomes
- 02Reviewed implementation and decision records
- 03Automated and manual quality evidence
- 04Known limitations, defects, and risk view
- 05Technical and operational documentation
Working agreement
Make inputs, evidence, and boundaries explicit.
The stage works best when the right context is available and the team agrees how useful progress will be judged.
What we need to understand
- Prioritised behaviour and acceptance expectations
- Architecture, data, integration, and experience direction
- Quality risks and consequences of failure
- Repository, environment, review, and ownership practices
Evidence of useful progress
- Important behaviour has appropriate repeatable checks
- Changes can be reviewed in understandable increments
- Known limitations and material risks are explicit
- The intended team can understand and continue the work
Important boundary
No test suite proves that software is defect-free or appropriate for every context. Quality work prioritises evidence around important behaviour and risk while keeping remaining uncertainty visible.
Stage rhythm
A visible path through the work.
The sequence is adapted to the engagement while preserving clear decisions, review points, and responsibilities.
Prepare the increment
Confirm behaviour, acceptance, design, dependencies, risks, and the smallest coherent implementation slice.
Build with feedback
Implement, review, integrate, and demonstrate progress while questions can still influence the work.
Verify important behaviour
Apply automated and manual evaluation suited to the feature, system boundary, audience, and consequence of failure.
Record readiness
Document decisions, evidence, limitations, operational considerations, and work that remains before release.
Process questions
Useful details to clarify.
What types of testing are included?+
The mix depends on risk and architecture. It may include unit, integration, contract, interface, exploratory, accessibility, security, performance, or operational checks.
How often is progress reviewed?+
A review rhythm should match the work and stakeholder availability. The aim is to expose meaningful increments before decisions become expensive to change.
How do you balance speed and maintainability?+
Prioritise the simplest responsible implementation, automate checks around important behaviour, and make deliberate trade-offs visible rather than accumulating them silently.
Can you work within an existing repository and team practice?+
Yes. Existing standards, pipelines, ownership, constraints, and useful patterns are reviewed before proposing changes.
Start a conversation
Need help with engineering and quality?
Tell us where the work stands, what needs to change, and what is currently unclear. We can help identify a sensible next step.