Why “agile” transformations failwithout an adaptive approach built on 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
Bent Flyvbjerg, How Big Things Get Done, 2023 (16,000 projects)
52.1%
of projects exceed their initial budget
Bent Flyvbjerg, How Big Things Get Done, 2023 (16,000 projects)
1/3
of ideas tested at Microsoft improve the target metric. One third has no effect. One third makes it worse.
Kohavi and Thomke, Harvard Business Review, 2017
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, teams practising Extreme Programming, a software development method, 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 Leguédois, agile coach and trainer).
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. The House of Commons Public Accounts Committee 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.
National Audit Office, 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.
French Court of Audit (Cour des comptes), 2020In contrast, organisations that practise continuous delivery achieve measurable results:
182x
more opportunities to better understand your users and adjust the product to their needs
8x
fewer production failures
2,293x
faster recovery when failures occur
DORA (Google Cloud’s research programme), Accelerate State of DevOps Report 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, co-author of the book Continuous Delivery, “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 the first month of development
- Value-driven scope
- Your priorities evolve with your market
- Executable specifications
- Your approved 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. 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
Approval
The classic approach
Bulk delivery at the end of the project (tunnel effect). Your only choice: sign the acceptance report
With DEVEDANOS
We test and sign off every feature before it goes live. If you’d rather not delegate this, you do it yourself
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
At Microsoft, of the ideas tested by controlled experiment, only one in three improved the target metric. One third had no effect, one third made it worse, according to Ronny Kohavi, who led Microsoft’s experimentation team, and Stefan Thomke, professor at Harvard Business School. There is no way to know which ones will deliver the expected value without putting them into production.
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 (Lientz and Swanson, Software Maintenance Management, 1980; more recent work, such as Capers Jones's in 2008, states the same finding as a percentage). 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 a complete development cycle
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 approve 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.
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.
We test and sign off, then we go live.
We 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.
Once the feature has been accepted and approved, we update the application in production. The code is already deployed via our automated deployment pipeline and awaits this go-ahead to be activated in production. If you’d rather not delegate this step, you test and approve each feature yourself.
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
What does adaptive development with continuous delivery produce?
Your users stay and your revenue grows
Your software contains what your users need. As soon as a feature goes live, the feedback we gather from your users tells us what to do next: remove it, adjust it, or add a new one.
You set the pace for your competitors
You occupy the ground. You iterate faster, at a sustainable pace. That is what keeps your customers with you rather than going elsewhere.
Every euro 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 approved feature 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 at no extra cost before moving on to another feature.
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)
Your monthly budget is fixed. The overall budget is planned over a horizon we define together.
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?
We fix your monthly budget and our commitment to deliver the most valuable features continuously. Each feature is signed off, then deployed. If your priorities change, we change with you. Your fixed monthly budget is built with you, from your numbers, over a horizon planned together. The content of each delivery evolves in contact with reality. That is precisely what protects you.
What does this model change for me?
A fixed monthly budget built with you, no estimate to validate. A flexible scope where you change direction whenever you want, with no amendment. Every feature tested and signed off before it goes live. And the option to terminate the contract at any time by simple written notice.
Why this approach? Classic project management locks scope, budget and timeline at the same time. The estimate at signing fixes scope before anyone really understands the problem. With no room to adapt, every unexpected event becomes a billable exception: missing features become amendments, fragile code generates recurring maintenance.
Can I change priorities along the way?
At any time. Client needs evolve, the scope adapts. You reorient priorities whenever you want; the contract does not change, neither does the price. We choose together the next hypothesis to test.
What happens if the developer of my application becomes unavailable?
The deployment pipeline is the living documentation of the project: test automation that describes the expected business behaviour, automated 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 once the first monthly invoice is paid. 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 fixes the budget and the feature list when the contract is signed, based on estimates of development time. But those estimates are only guesses, and nothing guarantees these features will be useful to your users: the list is written when the least is known about them. That is why we use a different approach: a fixed budget for a flexible scope. The software is usable within a month, then we adjust it continuously to what matters most to your users.
Am I locked into a minimum contract period?
No minimum duration. The contract has no fixed end date and is cancellable at any time in writing. A trial period of up to 15 working days in the first month: no invoice if you do not want the deliverables. Fixed monthly budget, defined together based on your project.
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.