Methodology

Eight phases. Eight exit conditions.

Most software development processes are a list of nouns on a slide. Ours names the lifecycle model governing each phase, what that phase hands to the next one, and the condition that has to be true before it is allowed to. That last part is the whole method.

The Lifecycle

Discovery to scale, in eight phases

From reading your existing system to profiling the one that replaced it. Each phase names the model that governs it, the artefacts it produces, and the gate at the end of it.

01
Discovery & Strategic Alignment
Spiral, risk-first2–3 weeks
We start from the assumptions that would be most expensive to be wrong about, not from the feature list. Legacy systems are read rather than described to us, constraints are written down as constraints, and success is reduced to numbers somebody is willing to be measured on.
Hands off
- System audit
- KPI baseline
- Risk register
- North-star architecture brief
Exit gate · Every architecture-invalidating assumption has been tested or explicitly accepted.
02
System Architecture
Spiral → gated design1–2 weeks
Service boundaries are drawn along the seams of the data, not the org chart. Every consequential choice, datastore, transport, consistency model, deployment topology, is recorded as an ADR with the alternatives that lost and the reason they lost.
Hands off
- Topology diagram
- Service boundary map
- ADR set
- Stack decision record
Exit gate · Load, failure and scaling behaviour are modelled before implementation begins.
03
UX & Product Systems
Iterative prototyping2 weeks, overlapping build
Enterprise interfaces fail on cognitive load long before they fail on aesthetics. Complex workflows are prototyped and put in front of the people who will run them daily, and the design system is built as tokens and components rather than as screens.
Hands off
- Workflow wireframes
- Interactive prototype
- Design token set
- Component inventory
Exit gate · The critical path has been walked by a real operator without a facilitator explaining it.
04
Sprint Engineering
Scrum. 2-week sprintsContinuous, demoed fortnightly
Two-week sprints against a backlog your product owner ranks. Trunk-based development, tests written with the requirement rather than after it, and no merge without review. Every sprint ends in a demo of running software, not a status deck.
Hands off
- Shippable increment
- Sprint demo
- Updated burn-down
- Reviewed, tested code
Exit gate · The increment is deployable to production at the end of every sprint, whether or not it is deployed.
05
QA & Reliability Testing
V-Model pairingPer sprint + release hardening
Every requirement was paired with its verification when it was written, so this phase executes a plan rather than inventing one. Load tests run against modelled peak, and failure is injected deliberately, the first time a dependency dies should never be in production.
Hands off
- Automated E2E suite
- Load & soak reports
- Chaos experiment results
- Traceability matrix
Exit gate · Performance and failure behaviour are known quantities with numbers attached.
06
CI/CD & DevOps
Continuous deliveryEvery merge
The pipeline is treated as a product with its own tests. Infrastructure is declared in code and reviewed like application code, releases are progressive, and rollback is a single pipeline run rather than an incident procedure.
Hands off
- Automated pipeline
- Infrastructure as code
- Progressive rollout config
- Rollback runbook
Exit gate · A deploy is boring, reversible and requires nobody to be awake for it.
07
Monitoring & Observability
DevOps feedback loopFrom release one
Tracing, metrics and structured logs ship with the first release, not after the first outage. Alerts are attached to service level objectives rather than to raw thresholds, so the pager fires on user-visible harm instead of on noise.
Hands off
- Distributed tracing
- SLO definitions
- Alert routing
- Live dashboards
Exit gate · Any production question can be answered from telemetry without adding code.
08
Scaling & Optimization
Kanban, flow-basedContinuous, WIP-capped
Post-launch work arrives unpredictably, so it runs as flow rather than in sprints. Production is profiled continuously, and optimisation is driven by what the traces say costs the most, never by what looks slow in a code review.
Hands off
- Profiling reports
- Query & cache optimisation
- Capacity plan
- Cycle-time metrics
Exit gate · Cost and latency curves are understood ahead of the next order of magnitude of load.

Lifecycle Models

Six ways to build software

Waterfall, the V-Model, Spiral, Scrum, Kanban and continuous delivery are not competing brands, they are different answers to the question of when you are allowed to be wrong. Pick a model and the diagram redraws to its actual shape.

Waterfall

1970 · Royce

Applied by signal

Every phase is finished, signed off and frozen before the next one starts. The plan is written once, up front, and the project's job is to execute it faithfully.

Where it wins

Scope, cost and date can be fixed in a contract before work begins
Documentation is a deliverable, not an afterthought
Every gate leaves a signed artefact, so the trail is auditable
Fits fixed-bid procurement and public-sector tendering

Where it breaks

Working software appears last, so the first honest feedback is also the most expensive
A requirement that was wrong in month one stays wrong until acceptance testing
Change control turns adversarial, every correction becomes a variation order
Testing gets compressed into whatever time the build overran by

Best for

Externally fixed scope: regulatory rewrites, contractual integrations, migrations with an immovable cutover.

How LogixLoops uses it

We run it only where the requirement genuinely cannot move. Even then the build behind the gate stays iterative, the plan is fixed, the way we hit it is not.

Selection Logic

Why we choose what we choose

Six signals we read in the first fortnight of an engagement, and what each one changes about how the work is run.

A regulator or a contract owns the requirement

The specification is not ours to renegotiate, and someone will audit the trail.

We runV-Model assurance over an Agile core

Acceptance criteria are authored with the requirement and traced to a named test, so evidence is a by-product of building rather than a scramble before the audit.

The hardest unknown is technical, not functional

We know what it should do. We do not yet know whether the architecture can do it at this volume.

We runSpiral spikes before commitment

A two-week disposable prototype that disproves an architecture is the cheapest artefact on the whole project. Committing a delivery team to it first is the most expensive.

Real users exist and can be observed

The requirement is a hypothesis, and there is a fast way to test it.

We runScrum on a two-week cadence

Every sprint boundary is a free chance to change direction. Any model with a longer feedback loop is paying more for the same information.

Work arrives unpredictably and never ends

There is no release to plan toward, there is a queue, and it refills.

We runKanban with hard WIP limits

Sprint commitments and unplanned incidents cannot both be honoured. Flow metrics tell you what the queue actually costs; velocity on interrupted sprints tells you nothing.

The cutover date is immovable and scope is known

Migration, decommission, or a compliance deadline with a hard edge.

We runA Waterfall plan with an iterative build behind it

The plan has to be fixed because the date is. The construction inside it does not, so we keep sprint demos and CI running under a gated schedule.

The system has to stay up while it changes

There are users on it right now, and there will be during the next deploy.

We runContinuous delivery, unconditionally

Deployment risk scales with batch size. Small reversible releases are the only mechanism that makes a change window boring, and boring is the target.

Our Method

One engagement, four governing models

No single lifecycle is strongest everywhere. We run each stage under the model that is best at it, and keep the seams between them explicit.

Discovery

Spiral

Risk-first. Timeboxed spikes against the assumptions that would invalidate the architecture, before a delivery team is committed.

Delivery

Scrum

Two-week sprints, demonstrable increment every time, backlog re-ranked at every boundary by a single accountable owner.

Assurance

V-Model pairing

Every requirement ships with the test that proves it, authored at the same time. Traceability is a by-product, not a phase.

Operations

Kanban + CD

Flow-based support with WIP limits, riding a trunk-based pipeline that makes every deploy small, gated and reversible.

Four things we will not do

Each of these has cost us work. They are here because the constraints a firm holds to are more informative than the services it lists.

Scrum with no product ownerIf nobody on your side can rank the backlog and accept work inside the sprint, the ceremony is theatre. We will ask for the person before we quote the cadence.
Fixed-bid work sold as agileFixed scope, fixed price and fixed date is a Waterfall contract. We will name it as one rather than promise flexibility the commercial terms forbid.
Continuous delivery without testsA pipeline with no meaningful coverage is a machine for shipping defects at speed. Coverage comes first, automation second.
Observability retrofitted after the incidentTracing, metrics and structured logs ship with the first release. Instrumenting a system while it is on fire is the most expensive time to do it.

You watch it happen

We work inside your board, your channels and your standups. There is no weekly summary email standing between you and the actual state of the work.

sync

Two-week sprints

Every one ends in a demo of running software. If we are building the wrong thing, you find out fourteen days after we start doing it.

dashboard

Your board, not ours

We work in your Jira or Linear instance. Nothing gets copied into a private tracker and summarised for you afterwards.

description

Decisions on the record

Each consequential choice becomes an ADR: what we picked, what we rejected, and why. The reasoning outlives the people who had it.

Phases, each with a gate

2 wks

Between demos

Pipeline run to roll back

Merges without review

Run your next build this way.

Bring us the system and the deadline. We will tell you which of these models fits it, and where the risk actually is.

Book a discovery call