5 Delivery Methods - AI Changes Everything - Pick Your Poison Wisely

Disclaimer The nature of AI projects is invasive. More often than not they are close to the value driver of your company. Stress and situational awareness are high when people are tinkering with your company’s source of income. You might want maximum safety and assurance. Unfortunately ML and most of AI is … temperamental. We don’t have the perfect solution. We can’t guarantee success. Even after 20+ years of ML R&D we are still encountering surprises. Not all in a good way.

This article has one goal. To show that: We understand you! We feel your pain!

Update 2026.Iun.07 We added the “Executive IC” reference. Thank you Jean-Michel Lemieux for sharing

Delivering AI projects successfully requires navigating complex trade-offs - there’s rarely a perfect approach that fits all situations.

Each methodology is a different flavor of poison - you just need to choose which side effects you can live with. From the soul-crushing rigidity of Waterfall to the adrenaline-fueled chaos of YOLO runs, every approach has its unique way of keeping you up at night. Understanding these trade-offs is the difference between a costly failure and a manageable one.

We’ll break down five distinct approaches to AI delivery, examining where each fits and where it breaks. No sugar coating, no silver bullets - just practical insights to help you choose your poison wisely.

Waterfall

In short: Perform tasks sequentially: system requirements, software requirements, analysis, architecture, coding, testing, and operationalization. [Read the next sentence in a highly ironic tone:] Each step, if done thoroughly, will guarantee success—on time and on budget!

In this blog we discuss the popularly accepted version of the waterfall methodology , not the original concept proposed in the seminal paper .

Nickname: Waterfail

Apocryphal story: Allegedly created because a lazy DoD clerk copied only the first two pages of a scientific paper into their report.

Why it’s appealing: It’s simple from a high-level perspective. Each step is clear, their succession is defined, and costs are easy to estimate. Success seems achievable, on paper. Full blown Legibility bias.

The reality: Waterfall often leads to horrendous time and cost overruns and high rates of failure.

Typical use cases: Civil construction projects, where the cost of refactoring is prohibitive. Government contracts also tend to follow the waterfall structure.

Famous quote: “I believe in this concept, but the implementation described above is risky and invites failure.” - Dr. Winston Royce (1971), author of the “Waterfall Paper,” about what later became known as the waterfall methodology.

Famous companies: Boeing’s Starliner project .

Fitness for AI projects: Waterfail. A strong NO. It might work only for small-scale customizations where data, business cases, and market factors are well understood and measured.

Fitted for: Project with zero unknowns, done for the n’th time.

Agile

In short: Based on The Agile Manifesto .

Why it’s appealing: Highly predictable and extremely popular in software engineering.

Typical use cases: Standard digitalization consulting projects.

Requirements for success: (1) The problem must be broken into homogeneous tasks, and (2) the team must be homogeneous in skills. In AI/ML projects, these two criteria are often unmet, causing friction.

AI projects are predominantly data-driven, which makes predictions and estimations challenging. The high failure rate of experiments often leads to friction within teams and increases pressure on establishing a clear “definition of done.”

Drawbacks: Lack of innovation, extreme risk aversion, and high friction when tasks involve unknowns.

Famous quotes:

“We are a family here!”
“ … the correct term is ‘scrum gentle forward nudger .’ ” Jovan Cicmil, on X .

Fitness for AI projects: “Scrum is hell.”

Fitted for: Small to large teams; sometimes used for end-to-end project delivery.

While this is the most common methodology in software today, its application to AI/ML projects presents challenges. Still, with some adjustments, simpler AI/ML problems might be manageable. Introducing some specific changes in the scrum process will reduce friction and give engineers more room to work. This can foster innovation, raise team morale, and produce better outcomes, despite the expected pushback from Scrum Masters.

Executive Individual Contributor

In short New kid on the block in leadership and management. Surfaced in the 1st half of 2026 amid the LLM-pilled “AI” boom.

Why it’s appealing: Combines the Nobel-generating “Circumscribed Freedom” with startup “Founder mode” to get things done

Who? Jean-Michel Lemieux joined Spellbook and took this role. He talks about this role .

In this chapter we read between the lines and try to dig what’s beneath this fancy position.

What is it about?

There are several patterns that show up in almost any high-performing organization:

In teams, there are always frictions and waste, even in high performing ones, with zero human issues because of incomplete information and limited human “context window”.
In any organization, climbing high enough and politics will surface. Every time a resource is scarce (budget, hiring, firing quotas) Gareth Morgan’s “Organizations as Political Systems” chapter applies.
Put one+ geeks (’tists) at a problem and they will re-define the notion of over-delivering! Paper clip optimization is a human invention, after all. Despite absolute best intentions and the brilliance of a well executed technical solution, this is wasteful.

An Executive IC is a person with:

great technical and political authority.
Extremely nosy (strong requirement for the role), can get context from any part of the org.
Unbounded by org chart or processes.
Enough authority that he/she can stay at a board meeting and steer things around.
No “stake” in career (already executive level), but Individual Contributor. She/he is viewed as a peer by delivery teams.

Why only now?

Human context window is augmented by AI (AI is doing RAG and wetware is doing the actual judgement)
AI enhances 100x the capabilities of an already 10x Engineer. One can afford to dive deep into an issue without needing to ask for permission.
Building is cheap, so 2-week data lake mining is done over a relaxed lunch, with BigFour-level polished report.
All of this might have been possible before. But the AI craze and recent tectonic shifts in corporate practices opened the Overton window for experimentation.

Why not XYZ?

Lead/Staff Engineer - No political authority and maybe accidentally bound to the mission of the company. Can influence only through committees.
CTO - Too political. Budgets, HR, team allocations. Besides technical steering. Her/his influence can be seen as coercing, when approaching grassroots teams.
Technical CEO - CEO has ONE purpose. To sell. Everything else is procrastination.
External expert - External is the keyword. Not bound to the mission, not real power even if hired by the board. Most optimize for billable hours over company mission.
Technical Change Manager - Change managers have a lot of “soft skills” to navigate political waters but they rarely have technical excellence.

Is it THAT easy?

Well, we do not believe so:

Extreme technical+business expertise can be forged only in production. They know how to build a business from ground up and don’t want to. Rare combination.
There is an upper cap on how much “context window” an EIC can handle. Large corps probably need more EICs.
How one grows such a person in an org?
Unproven “technology” for now, but very appealing in theory.
Corporate “beast” might spit out such a person because he/she cares too much about the mission and does not align with fiduciary duties of the board.
Threat to corporate climbers. EIC can leak “inefficiencies”, acting like a permanent whistleblower. Huge political friction especially if they join an established org.

YOLO Runs

In short: Go all-in on one direction, skipping intermediate validation steps. Make it or break it! See Jason Wei on X and Brad Porter on Linkedin . YOLO stands for You Only Live Once. Or You Only Look Once but this is for Computer Vision versed.

Also known as: Going Founder Mode.

Key traits:

Fast but unpredictable results (influenced by skill, problem difficulty, and luck).
Requires “rockstar” engineers or founders operating in GOD mode (Growth, Optimization, Destruction).
May lead to solutions that are interesting from an engineering standpoint but impractical as business.

When acceptable: When you only have one chance: limited runway, last straw, no fallback.

Famous quote: “We only got one shot. And if you have one shot, that chip has to be perfect.” - Jensen Huang, Nvidia

Warning: Beware of survivor bias! While this method mostly fails, notable successes include Nvidia, SpaceX, and OpenAI.

Fitness for AI projects: Potentially suitable for delivering a PoC when executed by highly skilled engineers. However, it’s not sustainable, akin to hopping across river rocks . A single slip can derail progress, leading to lost momentum and decreased confidence from stakeholders.

Fitted for: 100x engineers, technical founders, small teams of A+ players, companies in crisis, or short-term projects.

Lean

In short: Build-Measure-Learn-Iterate. Focus on validated learning and reducing waste, with the client always involved. Draws inspiration from scientific methods and Six Sigma. Popularized in startup management by Eric Ries in “Lean Startup” book.

Why it’s appealing: Encourages systematic innovation while reducing waste. Emphasizes practical improvements over breakthroughs.

Perception: While less trendy in Silicon Valley, the approach remains relevant in R&D as a blend of “boots on the ground” pragmatism and waste reduction.

The method may seem inefficient short-term. Many experiments fail, leaving unused code and abandoned features. Over time, the wins compound. You find what actually works, faster than teams that never tried.

Famous quote: “If things are not failing, you are not innovating enough.” - Elon Musk

Famous example: SpaceX. Known for blowing up prototypes (short term “I told you so”) to achieve long-term efficiency and speed (absolute launch market domination).

Fitness for AI projects: Yes. Often referred to as “Unified Methodology” in corporate settings.

Fitted for: Startups, consulting, and teams of all sizes. Works well as both a methodology and business strategy.

When working with us, this is the methodology you should expect. This is our playbook .

Circumscribed Freedom

In short: A research management approach granting researchers broad autonomy (“long leash”) within a defined set of critical, mission-aligned questions (“narrow fence”). Balances creativity with a focused research mission. See “How did places like Bell Labs know how to ask the right questions? ”

Why it’s appealing: The only method proven to produce Nobel prizes (GE Research) or groundbreaking innovations such as the transistor (Bell Labs). That also got a Nobel.

Challenges:

Highly unpredictable: no one knows when or where a breakthrough will occur.
Requires a full ecosystem (talented individuals, resources, and freedom to exchange ideas with the scientific community)
A manager who is at least a competent scientist .

Famous quote: “A watched pot never boils. ” - Yann LeCun

Famous examples: Bell Labs, Meta FAIR, Future Ventures , Answer.ai (story ).

Fitness for AI projects: Best. Particularly suited for cutting-edge, fundamental research.

Fitted for: Extremely well-funded startups focused on foundational research; corporate research centers.

Conclusion

Lean fits AI best. Most organizations run Scrum, and for predictable work, it’s fine. Neither kills you the same way. Know your team’s risk appetite and your stockholders’ tolerance for ambiguity before picking. Match the methodology to the uncertainty level, not the org chart. Pick your poison, then commit.