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

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. But here’s the thing: understanding these trade-offs can mean the difference between a costly failure and a manageable challenge.

I’ll break down five distinct approaches to AI delivery, examining where each one shines and where it falls short. No sugar coating, no silver bullets – just practical insights to help you choose your poison wisely.

Follow me on LinkedIn for more unfiltered insights on delivering AI solutions in the real world.

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.

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: Solopreneurs, small teams, large teams, and corporations.

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, leading to significant challenges.

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 create a more supportive environment for engineering teams. This, in turn, can foster innovation, enhance team morale, and improve the overall quality of project outcomes despite some expected push back from Scrum Masters.

In the future I will show some methods that will reduce friction while handling the unknowns.

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.

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—e.g., limited runway or a “last straw” scenario.

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 in the short term, as many experiments result in failures, leading to unused code and abandoned features. However, in the long run, it significantly enhances efficiency and productivity by fostering innovation and uncovering effective solutions.

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.

Circumscribed Freedom

In short: A research management approach granting researchers significant autonomy (“long leash”) within a defined set of critical, mission-aligned questions (“narrow fence”). Balances creativity with strategic alignment. 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 — difficult to determine 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

While Lean methodology resonates most strongly with AI constraints, the reality is that most companies are deeply invested in Scrum. Both approaches have their merits – Lean excels at nurturing systematic innovation, while Scrum brings the familiarity and structure many organizations need. The path to optimal AI development isn’t straightforward, but every step toward improvement counts.

In the future I will show how to reduce friction and improve delivery while working within your current framework. These adjustments won’t revolutionize your AI development overnight, but they’ll make your team’s journey notably smoother. Because sometimes, making things better is a pragmatic first step toward making them right.

Follow me on LinkedIn for practical tips on adapting your existing Scrum processes for AI development.