The Lean Waterfall Anti-Pattern: Why Agile Doesn't Work in Enterprise
Every department thinks they're iterating. Nobody's actually learning.
By Tristan Kromer · Quick Answer: Agile doesn’t work in enterprises because companies implement it only within the engineering silo while the rest of the organization stays in waterfall. Requirements still flow linearly from product managers to designers to developers to marketing, creating a “lean waterfall” anti-pattern where every department iterates internally but no cross-functional learning reaches the customer. As product managers, we need to break down silos and refocus on validated learning about customer value — not just faster software delivery — making hypothesis validation the true unit of progress.
More and more enterprise scale companies are drinking the lean Kool Aid and starting to implement Lean Startup methodology. In doing so, they are failing at the most basic level. Why agile doesn’t work? Lean methodology is not lean startup. An MVP is not learning. A Business Model Canvas is not business model innovation. These things are just artifacts. They are workarounds. These workarounds, applied poorly and/or inappropriately, can result in some wonderful anti-patterns. One of my favorites is that
Lean Startup for the Enterprise Explained in 5 Minutes from Tristan Kromer - Kromatic on Vimeo.
The Waterfall
Your enterprise probably works in a waterfall development methodology. Here is the waterfall in it’s grandeur: 
We move down the waterfall from idea, to design, to development, to marketing, and hopefully…finally…to the customers. (Your waterfall may have additional levels such as Q&A, architecture, etc. But let’s keep it simple for now.) Since at least 2001 when the Agile Manifesto was created, pretty much everyone decided that waterfalls are a great way to create bad software that no one wants. There are a few holdouts, but that’s life. The issues are at least very well known.
Enter Agile
Given these known problems including brittle architecture, high defect rates, perpetually delayed releases, along comes the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In attempting to kill off waterfall, various methodologies such as paired programming, Test Driven Development, Scrum, etc, etc, were used with great effect idealized in small iterations on continually improving software. Ta-DA! 
Software did indeed get delivered faster, but the key word from the manifesto is “valuable.” In cases where value to the customer and the requirements were known, Agile methodology produced (and continues to produce) great results. However, in an enterprise where agile is implemented only in the development silo by engineers alone, the complete process looks a bit different. If you zoom out a bit, it looks like this: 
Agile, when executed by just the software development team, looks suspiciously like waterfall if the requirements are still being handed over from the rockstar product manager with the business plan, over to the guru designers, then to the agile ninja development team, and finally to the marketing diva. Software quality is improving thanks to continuous integration and improvement, but in terms of value being delivered to the customer, we’re still in waterfall and we have little benefit in terms of real improvement of validated learning, or even a better delivery schedule.
”But that’s not Agile!”
You might object that this would be a poor implementation of agile philosophy and why agile doesn’t work. That’s quite correct! Agile is a philosophy. Scrum is a methodology. Scrum is an implementation of agile philosophy. If the team is truly agile, they would focus on the keyword “valuable” and refuse to implement any requirement not grounded in validating learning about what the customer finds valuable. But we’re talking about reality here, not philosophy. (Disclaimer: I have a philosophy undergrad and love it, but it will hopefully not shock you to learn that philosophy is often not grounded in practicalities.) When companies implement Agile, they often implement an Agile methodology such as Scrum without necessarily embarking on the culture change than needs to accompany it. If it is the engineering department and only the engineering department that implements Agile methodology, how will they determine if the requirements given to them will actually provide value to the customer? Will they talk to customer support? Will they talk to sales? Does the design successfully convey the value proposition? Has the value proposition been defined at all? Or is that left to the marketing team?
Lean All Over the Enterprise
So what’s next? Let’s add Agile UX! (Or a poor implementation of Lean UX if you prefer.) 
Yep…still in waterfall. But at least the designers and engineers feel better. Clearly the problem isn’t in their departments. They are iterating!
Lean Enterprise Anti-Pattern - The Lean Waterfall
The implementation of Agile (or lean thinking if you prefer) will continue in this vein until you arrive at a fully implemented Lean Waterfall where everyone thinks they are being lean and focusing on continual improvement, but busily blaming every other department for delays in deliverable handoffs that prevents their department from iterating effectively.
Breaking the Anti-Pattern
How do we get out of this? Back to the philosophy. The Agile Manifesto states (again):
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
But what is value? That payment may be in terms of cash, their time spent, private data freely given, or any other means, but payment is the ultimate arbiter of value. In these terms, no department, in and of itself, can provide value. It takes a multitude of disciplines. It takes business people to determine needs and establish feasibility. It takes designers to make the product easy to use. It takes engineers to create functionality. It takes marketers to make sure customers can get their hands on it and to set customer expectations.
Enter Customer Development (and Lean)
The great insight of Steve Blank and Eric Ries was that for most new products, the definition of value was unknown. The software engineer doesn’t know, the Product Manager doesn’t know, sometimes the customer doesn’t know! In the case of extreme uncertainty, where the the definition of value is unknown, any activity that does not focus on learning to identify true value for the customer is wasteful. So the primary function of a startup is to discover a sustainable (and scalable) business model, and the unit of progress is the # of hypotheses validated or invalidated. 
If there are handoffs, approval committees, brand police with “do not pass go” stamps, and legal sharks waiting to veto, you’re still in waterfall. Start breaking down silos.
Frequently Asked Questions
Why doesn’t agile work in enterprise companies?
Agile doesn’t work in many enterprises because it gets implemented only within the engineering silo while the rest of the organization remains in waterfall mode. Requirements still flow down from product managers to designers to developers to marketing in a linear handoff process. As a result, we end up with what’s essentially a “lean waterfall” — each department iterates internally but the overall process still fails to deliver validated customer value.
What is the lean waterfall anti-pattern?
The lean waterfall anti-pattern occurs when every department in an enterprise adopts its own agile or lean methodology — agile engineering, lean UX, iterative marketing — but the organization still operates in waterfall because work is handed off sequentially between siloed teams. Everyone believes they’re being lean while blaming other departments for delays, and no cross-functional learning actually reaches the customer.
What’s the difference between lean methodology and lean startup?
Lean methodology, agile processes, and tools like the Business Model Canvas are just artifacts and workarounds — they’re not the same as lean startup thinking. We can implement Scrum or create MVPs without ever validating whether we’re building something customers actually value. Lean startup focuses on learning and hypothesis validation as the unit of progress, not just faster delivery of software.
How do you break out of the waterfall anti-pattern in enterprise innovation?
We break out by refocusing on the Agile Manifesto’s core principle: delivering valuable software to customers. This means breaking down departmental silos so that business, design, engineering, and marketing work together as cross-functional teams. Following Steve Blank and Eric Ries’s customer development approach, we treat validated learning about customer value as the primary unit of progress — not deliverable handoffs between departments.
Why is implementing Scrum not enough to be truly agile?
Scrum is just one methodology that implements agile philosophy — it’s not agile itself. When we implement Scrum without the accompanying culture change, engineering teams iterate on software quality but still accept requirements that haven’t been validated with customers. True agile requires teams to question whether requirements are grounded in real customer value, which means talking to customer support, sales, and actual users rather than just executing a backlog handed down from above.
Comments
Loading comments…
Leave a comment