Why “agile” transformations failwithout continuous delivery of features
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, 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, 2013GBP 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, 2014EUR 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, 2020In 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
“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 became more important than the principles they were meant to serve. 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.
At DEVEDANOS, in our agile approach, we build each feature as a hypothesis to verify, we confront it with the reality of your users, and we adapt the product based on what we observe. The plan evolves in contact with the ground. The specifications evolve with it. The development process is designed to learn, rather than to execute a document that nobody will read again.
How we work
Agile approach: we decide together what to build
Priorities
The classic approach
A project manager decides, based on a document written months ago (waterfall, V-model)
Our approach
You are the product owner: you know your market, you drive user research, you decide what has the most value. Every week, we choose together the next hypothesis to test. We observe what users actually do in the software. When their needs do not match your priorities, we tell you
Change of direction
The classic approach
Amendment, additional cost, delay
Our approach
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
Our approach
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
Our approach
You open the application at any time and use what has been delivered. Working software in production is the primary measure of progress. Our 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. We therefore build each idea as a minimal increment, put it into production, and observe what your users do. What we learn decides what comes next: continue, adjust or abandon. The maintenance cost of a useless feature is 3 to 4 times its initial development cost (Capers Jones, Applied Software Measurement, 2008). A flexible scope and iterative development are not a luxury: they are the only lean mechanism that stops this haemorrhage and ensures customer satisfaction. Together, we form an agile team. The agile practices we apply cover the entire software lifecycle.
Each feature is an iteration: a complete development cycle
We define together what the software should do.
We investigate, plan and synchronise continuously, through the work itself.
We identify what has the most value for your users right now and break it down into deliverable user stories.
For that feature, we formulate concrete criteria: what must the software do, exactly, so that you can validate the work? These criteria are translated into automated tests. If the tests pass, the work is deliverable. If not, it is not.
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. Acceptance tests and integration 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. Only features that conform to the criteria defined in step 1 reach you.
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.
If the result meets your expectations, we make the new version visible to your users. The code is already deployed via automated deployment (Git, Docker, GitLab CI); it awaits your go-ahead to be activated. Ideally, at least one production release per week. Nothing goes live without your approval.
What continuous improvement produces in 6 months
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.
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 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 person who wrote the code is the person who answers you.
Covered
- Any feature approved in review that changes behaviour due to a subsequent modification
- Fix deployed in hours rather than weeks
Not covered
- Feature requests (counted as regular work, not as a regression)
- Third-party service failures (hosting, external APIs)
Your monthly budget is fixed and known from the first conversation. We define it together during the discovery call, for 15 development days per month.
15 days to form your opinion. No invoice if the result does not convince you.
The first month is a trial period. We scope the work with you, then we develop and deploy continuously. You review every feature. If the work does not convince you, no invoice is issued and you owe nothing.
Sébastien Nobour
Software Developer · Founder of DEVEDANOS
The person who writes the code is your point of contact.
Frequently asked questions
Do you provide estimates?
We do not fix a number of days per feature. We fix your monthly budget and our commitment to deliver the most valuable features for your business every week. You test, you approve, we deploy. If your priorities change, we change with you. You know your exact spend before starting: a fixed monthly budget that we determine together during the discovery call. The content of each delivery, however, evolves in contact with reality, because your priorities will evolve. And that is precisely what protects you.
How does your model work?
A fixed monthly budget, a flexible scope. When scope, budget and timeline are locked at the same time, the project has no room to adapt. The estimation-based pricing model locks the scope before anyone understands the problem. Missing features become a second contract, and fragile code generates billable maintenance.
We fix the monthly budget and deliver the most valuable features for your business every week. You change direction whenever you want, with no amendment. You review every feature before it goes to production. And you can end the subscription at any time by simple written notice.
Can we change priorities along the way?
At any time. You reorient priorities whenever you want; the contract does not change, neither does the price. Every week, we choose together the next hypothesis to test.
What happens if your lead developer becomes unavailable?
The continuous delivery pipeline is the living documentation of the project: test automation that describes the expected business behaviour, continuous deployment across multiple environments, infrastructure as code. A competent developer can resume development within days on a project whose test suite passes green and whose deployment runs in one click. The source code, infrastructure, deployment pipeline and documentation are your intellectual property from the first payment. The pipeline continues to verify every future change, regardless of which developer works on it.
What is the difference between your approach and a classic agile project?
A classic agile project locks the scope in a backlog, breaks the work into sprints, and measures the team’s velocity. Iterative development produces increments, but the scope remains locked by the initial contract. Our approach maintains a fixed budget and a flexible scope: the development team delivers the most valuable features every week. Priorities change with your market, not with a document written months ago. We commit to keeping the software in a deployable state at all times and to delivering working software in production every month.
Am I locked into a minimum contract period?
None. 15 days to form your opinion. No invoice if the result does not convince you. After that, the subscription is monthly, cancellable at any time by simple written notice. Fixed monthly budget, defined together based on your project.
Ready to see the difference?
30 minutes. We listen to your problem and tell you whether we can help.