AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms2 wks
Increment length
Working build every time
390+
Projects delivered
Since 2013
100%
Written acceptance criteria
Before work starts
0
Status decks
You review software
What you are buying
Project management, as a deliverable rather than a meeting
Software projects rarely fail loudly. They fail in the gap between a status report and reality, and that gap opens quietly over weeks. Everything below exists to keep it closed.
A scope somebody signed
Written acceptance criteria per increment, agreed before work starts. Not a feature list — a definition of what finished means, in language both sides can check against a screen. This is the artefact that prevents the most expensive argument on any project.
A build you can click
Every two weeks there is working software on a preview URL. You review the product, not a deck about the product. It is the only progress report that cannot be optimistic, and it is the part of our process we will argue hardest to keep.
A visible critical path
Which decisions block which work, and who owns each one. Most slipped timelines trace back to a decision nobody knew they were holding — usually an approval, an access request, or a third party nobody chased.
A risk list that is maintained
Risks written down, owned, and reviewed — not a slide produced at kickoff and never opened again. A risk register that has not changed in a month is a risk register nobody is reading.
Methodology
Which methodology should your project run?
Most of this argument is settled before anyone writes code, by two things: how much of the scope is genuinely knowable up front, and how often the people paying for it want to change their minds. Everything else is detail. None of these is better in the abstract — a fixed-scope integration for a regulated client and an early-stage product hunting for fit are different problems, and running the wrong process on either is expensive in its own way.
| Methodology | Shape | Fits when | What it costs you |
|---|---|---|---|
| Agile | Umbrella, not a process | Scope that is allowed to move | Needs a decisive product owner or it drifts |
| Scrum | Fixed sprints, defined roles, backlog | Priorities can hold still two weeks | Ceremony overhead on small teams |
| Kanban | Continuous flow, WIP limits | Support, maintenance, interrupt-driven | No natural cadence to review against |
| SAFe | Scrum coordinated across many teams | 50+ engineers shipping one product | Real hours; wasted below that size |
| Waterfall | Sequential phases, sign-off gates | Scope fixed by contract or regulator | Converts a wrong guess into a finished product |
| Hybrid | Gates outside, sprints inside | Procurement or compliance plus a real build | Two vocabularies to keep straight |
What we run by default is Scrum in shape without the ceremony that does not earn its hour: two-week increments, written acceptance criteria, a working build at the end of each. Gates get added where compliance requires them.
The comparisons people actually ask for
Scrum vs Kanban, Scrum vs SAFe, Agile vs Waterfall
The useful comparison is not feature-by-feature. It is what each one costs you when it is the wrong fit.
Scrum vs Kanban
Scrum batches work into a sprint and protects the team from mid-sprint change; Kanban lets work flow continuously and caps how much is in progress. Choose Scrum when priorities can hold still for two weeks. Choose Kanban when they genuinely cannot — a support queue run as Scrum just produces sprints abandoned by day three, which is worse than having no sprint at all.
Scrum vs SAFe
SAFe exists to synchronise many Scrum teams shipping one product. Its ceremonies cost real engineering hours, and below roughly fifty engineers that cost buys coordination you did not need yet. Most companies that adopt SAFe early would have been better served by three well-run Scrum teams and one shared release calendar.
Agile vs Waterfall
Waterfall is not obsolete, it is specialised. Where scope is fixed by a contract, a regulator or a hardware date, sequential phases with sign-off are the honest structure, and an iterative process just hides the constraint. Where scope is a hypothesis, Waterfall spends the whole budget turning a wrong guess into a finished product and tells you at the end.
Do we need a dedicated project manager?
Below about four engineers on a single workstream, usually not — a technical lead with authority can carry it. Above that, or across more than one team, the coordination work is a real job and giving it to someone part-time means it gets done part-time. The failure mode is a PM with responsibility and no authority to say no.
Where projects actually go wrong
The five failure modes we are hired to fix
Almost every recovery engagement we take on traces to one of these. None of them is a technology problem, which is why adding engineers rarely fixes them.
Nobody owns the decision
Work stalls behind an approval, an access request or a third party nobody was chasing, and it stalls quietly because the blocked task still looks 'in progress' on the board. The fix is unglamorous: every blocked item names a person and a date, and the list gets read aloud every week until it is empty.
Done was never defined
A feature is delivered, rejected, reworked and rejected again, because acceptance was a shared assumption rather than a written sentence. Two rounds of that costs more than writing the criteria would have, and it poisons the relationship while it happens.
Progress is measured in effort
Story points burn down, hours are logged, and nothing is demonstrably working. Velocity measures how much a team estimated, not how much a customer can use. If a metric has never once produced bad news, it is not measuring anything.
Scope grows by a hundred small yeses
No single request is unreasonable and the cumulative effect is a project a third over budget. Scope creep is not caused by clients asking; it is caused by nobody holding a ledger of what has been added and what it cost.
The estimate was a negotiation
A number gets agreed because it had to be agreed, not because anyone believed it. Everything downstream inherits the fiction, and the reckoning arrives at the point where it is most expensive. We would rather lose the work than quote a number we do not believe.
What you get every two weeks
Reporting that cannot be optimistic
A status report is a claim. A deployed build is evidence. The cadence below is designed so you are never more than fourteen days from evidence.
| When | What happens | Why it is there |
|---|---|---|
| Day 1 | Increment scope agreed | Written acceptance criteria for each item, signed off before any code is written. Anything that cannot be described this way is not ready to build. |
| Daily | Board reflects reality | Blocked means blocked, with an owner and a date. The board is maintained by the people doing the work, not curated for an audience. |
| Day 7 | Mid-increment check | The one chance to move something out before it becomes a missed commitment. Slips surfaced here cost a conversation; slips surfaced at the end cost trust. |
| Day 14 | Working build on a preview URL | You click it. Acceptance criteria are walked through against the running software, and anything not met goes back with a reason. |
| Day 14 | Risk list reviewed | Each open risk either changed, got an owner, or gets closed. A register nobody edits is a register nobody reads. |
Where you already run this cadence, our delivery leads join it rather than replacing it. The only thing we insist on is the build at the end.
How an engagement runs
Twelve weeks you can audit
The cadence is the product. Every two weeks there is working software on a URL you can click, which is what keeps the gap between a status report and reality from opening.
How to buy it
Three ways project management arrives
It is rarely bought on its own. These are the shapes it actually takes.
| Shape | Typical range | Duration | What it buys |
|---|---|---|---|
| Inside a build | Included | Per engagement | Every DEV.co build carries delivery management — acceptance criteria, increments, the risk list. It is not a line item you can decline, because the build is not auditable without it. |
| Embedded PM | Scoped per engagement | Defined stretch | A senior delivery lead inside your team, your tools and your cadence, for a launch, a migration or a recovery. Reports to your engineering lead, not to an account manager. |
| Delivery audit | Scoped per engagement | 2 – 3 weeks | An independent read on a project that is slipping: where the critical path actually runs, which risks are unowned, and what to change first. Written up and yours to act on with or without us. |
Rates assume US-based senior delivery leads. An audit is credited against an embedded engagement if you continue within ninety days.
Questions
Buying software project management
What prospective clients ask before a first call.
Agile is the set of principles; Scrum is one specific way of practising them. Every Scrum team is Agile, but plenty of Agile teams do not run Scrum — Kanban teams, for instance, are Agile and have no sprints at all.
In practice the word "Agile" on its own tells you very little about how a team works. Ask what the cycle length is, who may change priorities mid-cycle, and what gets demonstrated at the end. Those three answers describe the process; the label does not.
Ask whether your priorities can hold still for two weeks. If they can, Scrum's fixed sprint is an advantage — it protects the team from churn and makes velocity mean something.
If they genuinely cannot, because you are running support, maintenance or anything interrupt-driven, Kanban with work-in-progress limits fits the reality. Forcing Scrum onto interrupt-driven work produces sprints abandoned by day three.
Above roughly fifty engineers who all have to ship one product together, yes — coordinating that many teams needs a shared cadence, and SAFe is a reasonable off-the-shelf answer.
Below that, usually not. The ceremonies consume real engineering hours to solve a coordination problem you do not have yet. Three well-run Scrum teams and one shared release calendar achieve the same thing for a fraction of the cost.
Yes, and saying otherwise is a fashion rather than an argument. Where scope is fixed by contract, by a regulator, or by a hardware date, sequential phases with sign-off at each gate are the honest structure — the constraint is real and an iterative process just hides it.
The failure mode is using Waterfall when the scope is actually a hypothesis. Then you spend the whole budget turning a wrong guess into a finished product, and you find out at the end.
Usually, and it is often the better arrangement. Our delivery leads join your board, your cadence and your standups rather than running a parallel process and reporting across the gap.
Where we push back is on anything that removes the working build at the end of each increment. That is the mechanism that stops a project failing quietly, and it is the one part we will argue to keep.
You hear about it within the increment it happens in, not at the end. That is the point of a two-week cycle — a slip is visible in fourteen days, while there are still options.
What follows is a scope conversation rather than an overtime one. Usually something moves out of this increment and into the next; occasionally the estimate was wrong and we say so.
You do, throughout. Board, acceptance criteria, architecture notes, risk register and retrospectives live in your tools where possible, and transfer on request at any point.
Nothing about the delivery process should make leaving expensive. If it does, that is a commercial arrangement dressed up as a technical one.