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

Piecemeal lean startup is just waterfall in disguise Share on X

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:

Waterfall Development in the Enterprise, why agile doesn't work

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.


Agile Software Development continuous improvement loop


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 Development in the Enterprise

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.)

Lean UX and Agile Development in the Enterprise

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.

Lean Startup in the Enterprise Anti-pattern: The Lean Waterfall

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?

Value is determined by the customer in the act of paying for a product. Share on X

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.

Every department must participate in the creation of value. Share on X

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.

Build Measure Learn Loop

To be a lean enterprise, silos must be broken down into a single team capable of (in)validating a hypothesis. Share on X

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.

Become a faster, more confident decision-maker

Learn how to make better pivot or persevere decisions on your real project by building a hypothesis-driven financial model. Innovation Accounting is a six-week training program taught by real entrepreneurs with real experience and you’ll get results you can use right away.
Join the waitlist →