Why “agile” transformations failwithout continuous delivery

0.5% of large-scale projects are delivered on time, on budget and with the expected value. The remaining 99.5% are not accidents. They are the structural consequences of a pricing and project management model whose limitations have been documented for decades.

0.5%

of projects are delivered on time, on budget and with the expected value

Flyvbjerg, How Big Things Get Done, 2023 (16,000 projects)

52.1%

of projects exceed their initial budget

Flyvbjerg, How Big Things Get Done, 2023 (16,000 projects)

2/3

of features developed deliver no measurable value

Kohavi et al., Microsoft Research, 2009

When scope, budget and timeline are locked at the same time (the iron triangle), the project has no room to adapt. Pressure builds until something gives: the real scope (features disappear in silence), the code quality (shortcuts accumulate), or the budget (amendments, refinancing, a second contract to finish what the first one should have delivered).

Story points illustrate this mechanism well. Originally, Extreme Programming teams estimated in “ideal days,” an abstraction of uninterrupted work time. Clients read “3 ideal days” and understood “Wednesday.” They made commitments to their management on that basis, and teams found themselves held to deadlines they had never given. Story points were created to break this link with the calendar: a deliberately abstract unit, with no possible conversion to days.

The industry restored the conversion. Story points were multiplied by an arbitrary coefficient to produce days, then dates, then contractual commitments. In 2019, Ron Jeffries, one of the creators of story points, wrote: “I may have invented story points, and if I did, I’m sorry now.” The sprint backlog is nothing more than a Gantt chart rotated 90 degrees (Frédéric Leguedois).

Billions in public funds wasted on IT projects, documented by national audit offices and parliaments across multiple countries.

GBP 10 bn

to digitise the medical records of 50 million patients, dismantled after 9 years. Parliament called this programme “one of the worst and most expensive contracting fiascos in the history of the public sector.”

House of Commons, 2013

GBP 15.8 bn

for a welfare system whose cost grew from GBP 2 bn, with an IT system deemed inadequate by 90% of staff. Final calculations were made manually on spreadsheets during pilots.

NAO, 2014

EUR 400 M

for an HR system intended for 1.1 million civil servants. The project was abandoned after 11 years, having covered only 2% of the agents concerned.

Cour des comptes, 2020

In contrast, organisations that practise continuous delivery achieve measurable results:

182x

more capacity to deliver value to customers

8x

fewer production failures

2,293x

faster recovery when failures occur

DORA State of DevOps 2024

The documented business outcome:

+50%

higher market cap growth over 3 years for organisations that practise continuous delivery

Forsgren et al., Accelerate, IT Revolution Press, 2018, Appendix B (2014 analysis on publicly traded subset, not replicated since)

“Agile software development works because it is the application of the scientific method to software development.”

Dave Farley, Hypothesis Based Development

Every idea is a hypothesis. Every release is an experiment. Every piece of user feedback is data.

Agile software development: what the Manifesto actually says

The Agile Manifesto and its 12 founding principles fit on a single page. Four values:

  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • Individuals and interactions over processes and tools

Sprint planning, story points, Scrum ceremonies (daily standup, sprint planning, sprint review), the Scrum Master, velocity charts, agile methodologies, agile management, SAFe and scaling frameworks: none of this appears in the Manifesto.

The rules created to integrate the agile approach into traditional methods, when it was supposed to replace them, became more important than the principles they were meant to apply. The result is measured in billions, invested in software that nobody uses.

The problem is not what the Manifesto says, but the pricing model and project management process that surround it.

Agile is not a mindset. It is the application of the scientific method to software development.

At DEVEDANOS, in our agile approach, each feature is a hypothesis confronted with the reality of your users to collect their feedback. The plan and specifications evolve in contact with the ground. The software development process is designed to discover and adapt, not to execute a document that nobody will read again.

The approach at a glance

Continuous delivery
Your software stays deployable every day
Production monitoring
You see breakages early and real-world usage
Fast feedback loops
You measure what produces results from day one
Value-driven scope
Your priorities evolve with your market
Executable specifications
Your validated features stay stable

What you steer on this project

What does this discipline change for you, week after week?

Agile approach: you decide what goes to production

Priorities

The classic approach

A project manager decides, based on a document written months ago (waterfall, V-model)

With DEVEDANOS

You are the product owner: you carry the product vision, you know your market, you drive user research, you decide what has the most value based on our observations. Every week, we choose together the next hypothesis to test. When the real needs of your users do not match your priorities, we tell you

Change of direction

The classic approach

Amendment, additional cost, delay

With DEVEDANOS

You reorient priorities whenever you want, with full flexibility and responsiveness. The contract does not change. Neither does the price

Validation

The classic approach

Bulk delivery at the end of the project (tunnel effect). Your only choice: sign the acceptance report

With DEVEDANOS

Every feature is validated by you before going to production. You approve, or you refuse

Progress visibility

The classic approach

Monthly demonstrations. Progress percentages disconnected from the actual software

With DEVEDANOS

You open the application at any time and use what has been delivered. Working software in production is the primary measure of project progress. Our collaborative kanban board and backlog are also accessible at all times

Two thirds of features developed deliver no measurable value. There is no way to know without shipping them.

Each feature becomes a deliverable product in the form of a minimal increment. In production, we observe what your users do. What we learn decides what comes next: continue, adjust or abandon.

The maintenance cost of a feature is 3 to 4 times its initial development cost (Capers Jones, Applied Software Measurement, 2008). Building nothing useless is not a luxury. Moving forward with a flexible scope and iterative development in short cycles is the only lean response to this waste and ensures customer satisfaction.

Together, we form an agile team: teamwork between you and us drives every decision and covers the entire software lifecycle.

Each feature is an iteration: a complete development cycle

1

You decide what the software does; we specify it together.

We investigate, plan, ensure prioritisation and synchronise continuously. Software development is a process of permanent discovery.

Together, we identify what creates the most value for your end users and break it down to the smallest deliverable user stories. We prioritise by direct value comparison. When the domain complexity demands it, we map the territory of the problem before coding.

For each feature, we formulate concrete criteria: what must the software do, exactly, so that you can validate the work? These criteria are translated into automated test scenarios, written before the first line of code (executable specifications). If the tests pass, the feature becomes a deliverable product. If not, it does not.

2

Every change is verified automatically before reaching your review environment.

Every code change triggers a continuous integration and automated verification chain (the “pipeline”). Fast checks (unit tests, type checking, static analysis) take less than 5 minutes. Integration tests and acceptance tests (functional tests), which reproduce the behaviour expected by your users, take less than 30 minutes.

A change that fails any of these stages never reaches your review environment: technical defects are intercepted upstream, and only features that conform to the criteria defined in step 1 reach you.

3

You validate; we go live.

You test each feature in a review environment identical to production. In parallel, the pipeline runs security audits and performance tests. From change to full verdict, less than one hour elapses.

If the result meets your expectations, we make the new version visible. The code is already deployed via our automated deployment pipeline and awaits your go-ahead to be activated in production. We aim for at least one production release per week. Nothing goes live without your approval.

In the production environment, monitoring alerts us in case of an incident, without waiting for your users to report it. Our analytics tools measure the real impact of each feature through pirate metrics (AARRR: acquisition, activation, retention, revenue, referral) and guide the next decisions.

What continuous improvement produces in 6 months

What can you observe after six months of continuous delivery?

Your users stay and your revenue grows

Software validated every week by real users. You measure what works, you remove what does not, and your investment produces visible results from the very first weeks.

You set the pace for your competitors

You occupy the ground. You iterate faster, at a sustainable pace.

Every pound invested funds a feature that is actually used

What was not serving its purpose was removed within days. The budget funds only what your users actually use.

Your company absorbs growth without proportional hiring

The software handles what would have required hires: recurring processing, follow-ups, synchronisations, reporting. Your business grows and your current team is enough, because the software absorbs the additional volume. The gains are operational and immediate.

The zero-regression guarantee

Every feature you approve is locked by an automated test. If a subsequent change alters its behaviour, the test detects the regression before your users notice.

The development team fixes the regression before the next deployment.

Covered

  • Any feature approved in review that changes behaviour due to a subsequent modification
  • Fix deployed in hours rather than weeks
  • Rollback possible at any time in case of an incident

Not covered

  • Feature requests (counted as regular work, not as a regression)
  • Third-party service failures (hosting, external APIs)

15 days to form your opinion. No invoice if you decide not to continue.

The first month is a trial period. We scope the work with you, then we develop and deploy continuously. You review every feature. If you decide not to continue, no invoice is issued and you owe nothing.

Photo of Sébastien Nobour, founder of DEVEDANOS

Sébastien Nobour

Software Developer · Founder of DEVEDANOS

You work with the developers who design, develop, and deploy your software.

Frequently asked questions

Do you provide estimates?
How does your model work?
Can we change priorities along the way?
What happens if your lead developer becomes unavailable?
What is the difference between your approach and a classic agile project?
Am I locked into a minimum contract period?

Ready to see the difference?

Thirty minutes to understand your situation. If we can help, a second meeting takes place within 48 hours to build the quote together.