You can't build on emerging platforms with waterfall processes. Not because agile is trendy. Because the technology literally demands different ways of working.
After ten years of building on emerging platforms—Alexa, Android Automotive OS, Apple Watch, AI—we've learned this the hard way: traditional development and undefined platforms are incompatible.
The Platform Reality
Emerging platforms have:
No documentation (or documentation that's wrong, incomplete, or changing daily)
APIs that change weekly (what worked yesterday breaks today)
Undefined design patterns (no one knows "best practices" yet)
Rapid evolution (platform adds features, changes models, deprecates APIs)
Community knowledge doesn't exist (no Stack Overflow answers, no tutorials, no blog posts)
You're building in uncertainty. Constantly.
What Waterfall Requires
Traditional waterfall development requires:
Stable requirements (define everything upfront, change is expensive)
Documented systems (reference documentation, understand behavior)
Defined patterns (follow established best practices)
Predictable timeline (plan the full project, estimate accurately)
Sequential phases (requirements → design → build → test → deploy)
These are reasonable expectations when building on mature platforms. They're impossible on emerging platforms.
The Incompatibility
Try to build an Alexa skill in 2016 with waterfall:
Phase 1: Requirements (2 weeks) You write a detailed spec for voice interactions, expected user flows, response patterns.
Phase 2: Design (2 weeks) You create detailed designs based on those requirements.
Phase 3: Build (8 weeks) Developers build according to spec.
Problem: By week 6, Amazon has changed the voice interaction model. Your spec is obsolete. Your designs don't match the platform capabilities. Your build is targeting APIs that no longer work the way you planned.
By the time you reach Phase 4 (Testing): The platform has evolved. Your carefully planned feature set is either impossible to build as specified or misses new capabilities that competitors are already shipping.
This isn't theoretical. We've seen it happen.
Why Agile Actually Works for Emerging Platforms
Agile practices work on emerging platforms not because they're a better philosophy, but because they match the reality:
1. Iterative Development
Build in small increments. Ship something minimal. Learn. Adjust. Repeat.
When Alexa's interaction model changed in week 3, we'd only built 2 weeks of features. Pivot cost: small. If we'd planned 12 weeks upfront, pivot cost: massive.
2. Continuous Learning
You don't know what works on a new platform until you try. Agile builds learning into the process.
We shipped early voice skills to test users. Discovered people didn't interact the way we assumed. Adjusted immediately. Waterfall would have discovered this in user acceptance testing—far too late.
3. Pairing Transfers Knowledge in Real-Time
When documentation doesn't exist, you can't go read it. You discover through building.
Two engineers pairing: one discovers API behavior, immediately shares with partner. Knowledge spreads in real-time. Solitary development: everyone discovers the same things separately. Massive waste.
4. User Stories, Not Requirements Documents
"As a user, I want to ask Alexa for PGA Tour scores" is flexible. The implementation can adjust as we learn what works.
"System shall provide voice interface with following exact interaction model..." is rigid. Breaks when platform changes.
5. Continuous Deployment
Ship changes immediately. Platform breaks something? Fix and deploy today. Don't wait for next release window.
Waterfall quarterly releases on emerging platforms: By the time you ship, you're shipping outdated features.
The Ford Example: Agile Works Even in Regulated Industries
"But we're in automotive / healthcare / finance. We can't just iterate rapidly. We have regulations."
Ford proved this wrong.
Automotive software is heavily regulated. Safety-critical. Long product cycles. You'd think waterfall is required.
But we brought modern agile practices to Ford's testing processes:
Automated testing (catch issues immediately)
Continuous integration (know if code breaks)
Rapid feedback cycles (iterate on automotive constraints)
The regulations didn't change. The practices that work within those regulations did.
You can be agile in regulated industries. You just need practices that work within your constraints.
Healthcare organizations doing continuous delivery with compliance built-in.
Financial services shipping weekly while meeting regulatory requirements.
Automotive teams iterating rapidly with safety gates.
The constraints are real. Waterfall isn't the only way to meet them.
What Happens When You Try Waterfall on Emerging Platforms
We've watched organizations attempt it:
Scenario 1: The Six-Month Voice Project
Large company decides to build Alexa skills. Months of planning. Detailed requirements. Full design phase. Development begins.
By month 4: Amazon has deprecated key APIs. Added new capabilities. Changed certification requirements. Competitors have shipped, learned, and iterated three times.
By month 6: They ship. Users don't interact the way spec assumed. But the project is "done"—no budget for iteration. Skill gets poor ratings. Abandoned.
Scenario 2: The Apple Watch App That Missed Launch
Company wants to be on Apple Watch at launch (2015). Spends months planning "the perfect wearable experience."
Meanwhile, we shipped a basic app on launch day. Learned what actually works on wrist. Iterated based on real user behavior. By the time their "perfect" app shipped (3 months after launch), we'd learned from three iterations and they were copying patterns we'd discovered.
Scenario 3: The AI Feature That Took Too Long
Financial services company wants AI-powered insights in mobile app. Extensive planning. Architecture documents. Full requirements specification.
By the time they're ready to build: LLM capabilities have evolved, competitors have shipped similar features, user expectations have changed. Their planned approach is already dated.
The Pattern
Emerging platforms demand:
Learning by doing (can't learn from documentation that doesn't exist)
Rapid iteration (platform changes require quick adjustments)
Continuous deployment (ship and learn fast)
Pairing for knowledge transfer (spread discoveries in real-time)
Flexibility over rigid plans (requirements change as you learn platform)
These aren't agile buzzwords. They're survival mechanisms for building on undefined platforms.
Why This Matters Now
AI is today's emerging platform. LLM capabilities evolve monthly. Best practices don't exist. Documentation is incomplete. Platform providers (OpenAI, Anthropic, etc.) change APIs and models regularly.
Organizations trying to build AI features with waterfall planning: By the time they ship, the platform has evolved. Competitors have shipped, learned, iterated.
Organizations using agile practices on AI: Ship minimal AI feature. Learn what users actually do. Adjust prompts, models, approaches. Ship again. Stay current as platform evolves.
After Ten Years
We've built on enough emerging platforms to recognize the pattern:
Waterfall fails on emerging platforms. Not because it's "old-fashioned." Because it requires stability that doesn't exist.
Agile works on emerging platforms. Not because it's trendy. Because it matches the reality of building when documentation is thin, APIs change, and you learn by doing.
This isn't ideology. It's physics.
Emerging platforms are fluid. Your development process needs to be fluid too.
After ten years at the edge: You can't build on emerging platforms with waterfall processes. Agile isn't optional—it's the only approach that works.