Home / How We Work

How We Work

Fixed price discovery, two week increments, four gates with written criteria, a live delivery board and a written report every increment.

Delivery

Predictable is a design decision

Software projects do not slip in one dramatic moment. They slip two days at a time, invisibly, until the last month. Our process exists to make that visible in week three instead of week fifteen.

  • Fixed price discovery that ends with a written scope, a plan and a number
  • Two week increments that always end with working software in a production like environment
  • Four gates with written entry and exit criteria, decided by evidence and not by optimism
  • A live delivery board you can open at any time without asking us for a status update
  • A written increment report every two weeks: what shipped, what moved, and why it moved
Nexum Forge consultants running a commerce discovery workshop with a client team

The increment

What happens every two weeks

Two week increment loop and the artefact each step produces

Figure 10 / delivery loop
Planhalf a day Buildseven days Reviewevery change Testautomated first Demoone hour, live Releaseon demand FEEDBACK, MEASURED RESULTS AND ANYTHING THAT DID NOT FIT GO BACK INTO THE NEXT PLAN ARTEFACT PRODUCED Plan: increment goal, scope, acceptance criteria, updated board. Build and review: every change peer reviewed, no direct commits to the main branch, architecture decisions recorded when they change. Test: unit, contract, end to end and visual regression suites in the pipeline, plus exploratory testing on the increment goal. Demo and release: working software shown live, written increment report, release notes, deployable artefact whether or not you choose to ship it.

Figure 10. Release is a business decision, not an engineering event. Every increment produces something that could go to production the same afternoon.

Governance

Who decides what

Ambiguity about decision rights is the most expensive thing in a delivery programme. This is agreed in week one and put on the wall.

DecisionYour product ownerYour technical leadOur delivery leadOur principal architect
Scope and priorityDecidesConsultedConsultedInformed
Architecture and vendor choiceConsultedDecides jointlyInformedDecides jointly
Release to productionDecidesConsultedRecommendsInformed
Definition of doneConsultedConsultedDecidesConsulted
Change to fixed scopeDecidesInformedPrices it firstConsulted
Incident severityInformedConsultedDecidesConsulted

Table 09. Two people cannot own the same decision. Where a client has no technical lead available, we make that gap explicit and price the extra architect time to cover it.

01

Definition of done

  • Peer reviewed and merged
  • Automated tests written and green
  • Performance budget respected
  • Accessibility checks passed
  • Documentation and run book updated
  • Deployed to the staging environment

02

What you attend

  • One hour demo every two weeks
  • Thirty minute planning every two weeks
  • Gate reviews, four in a typical programme
  • Nothing else is mandatory

03

Change control

Any change to fixed scope is written down, estimated and priced before it is built. You approve it or you do not. There is no discovery of extra cost at invoice time.

Next step

Tell us what is slowing your commerce platform down

Send the brief. A principal architect reads it, then you get a written technical assessment with options, effort and risk inside five working days. No sales call required first.

Start a conversation Read the case studies