Lean Enterprise Anti-Pattern: The Lean Waterfall

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.

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.

The Waterfall

Your enterprise probably works in a waterfall development methodology. Here is the waterfall in it’s grandeur:

waterfall in the enterprise Lean Enterprise Anti Pattern: The Lean Waterfall

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!

agile software development continuous deployment loop Lean Enterprise Anti Pattern: The Lean Waterfall

 

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 in the enterprise Lean Enterprise Anti Pattern: The Lean Waterfall

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. 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 in the enterprise Lean Enterprise Anti Pattern: The Lean Waterfall

Yep…still in waterfall. But at least the designers and engineers feel better. Clearly the problem isn’t in their departments. They are iterating!

Welcome to the 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 lean waterfall Lean 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.

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.

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.

BML Loop Lean Enterprise Anti Pattern: The Lean Waterfall

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

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.

So…what should I post next? Tweet to tell me what to write:

Show me how to test product market fit!

or

How can I do lean startup in my friggin' huge company?

38 comments

  1. Pingback: Lean Startup in the Enterprise Anti-Pattern: Th...

  2. Hi,

    Good article, good images. Thanks for writing!

    A quick comment, which I’m sure you will as a philosophy undergrad appreciate, Scrum is not a methodology. Yes, some people represent it as one, meaning that there are certain practices you must follow. Scrum is a framework, giving an appropriate scaffolding for managing work within a complex domain. A person using Scrum will have to define the practices they will use themselves. Many Scrum books do give examples of possible practices and they are sometimes called “Book Scrum”, but they are merely a starting point. And there’s all these other things that need to be added, like Lean Startup, Lean thinking, and XP, plus integration with other parts of the delivery chain, to make it really work. Your article is a good illustration how important all of that is.

    • Tristan says:

      Good point! I buy that. We can put frameworks somewhere between philosophy and a strict methodology.

  3. Pingback: Lean Startup in the Enterprise Anti-Pattern: Th...

  4. Rami Gazit says:

    Fantastic article!

    I would add to the last twit:

    To be a lean enterprise, silos must be broken down into a single team capable of validating a hypothesis WITHOUT THE FEAR OF INVALIDATING IT.

    Rami
    Chief mentor BizTEC Technion Israel

    • Tristan says:

      Excellent point. Perhaps worth a whole other post because I can’t fit that in a clicktotweet link!

      • gary says:

        Rami’s point is critical. In the Enterprise, I have found that fear of failure is the single biggest barrier to successful lean/agile practices.

  5. Rammohan says:

    Awesome post Tristan, thanks for that

    • Tristan says:

      Thanks for the kind words Rammohan!

  6. Pedro Thormodsen says:

    Great post. Not sure if I agree with this thou

    “But what is value? Value is determined by the customer in the act of paying for a product. 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.”

    This definition of value leans towards me, the developer, getting something back from the customer. Thats value for me. Value for the customer in the meantime might be high, even if there is no transaction back to the developer. Art comes to mind as an example. Or am I missing the point?

    • Tristan says:

      This is a pragmatic definition based on a lean focus on learning about your customer and your business model. How do you know if it’s valuable unless someone pays?

      If no one is paying with their money, their attention, their time, is it art? Or is it just crap that no one wants?

      Last time I checked, good art is quite pricey.

  7. VM says:

    Most agile projects that I have heard and seen have not lived up to the manifesto as there are quite expensive, impractical, overcomplicated, misleading and irrelevant in mission critical business environments.

    The irony being that the Agile philosophy is being portrayed as a holy grail in providing value a different type of approach compared to traditional approaches to product development, and in that process only deliver very less marketable piece of software, resulting in waste of significant time, effort and money.

    Adopting Agile is like designing, building and trying to sell a car to a customer in piecemeal approach, the reality being no customer will want his car to arrive in pieces at different points in time as it is not going to be useful. The customer will only interested in a car which is complete and has good amount of functionality. The same analogy applies to product or software development.

    Most major product organizations continue to adopt traditional (definitely not Agile), time tested iterative development (which is different from Agile) as there is a full SDLC in each iteration for a given set of functionalities, good amount of time spent on testing integrated functionality, documentation, etc. and business will always be happy to see value, as they will have enough functionality.

    Business always needs good amount of functionality (critical mass) and richness which they can then take it to the market, sell to acquire new customers. With an approach of delivering piecemeal functionality, compromising on functional richness and completeness, it is certainly not worthwhile for organizations to adopt Agile.

    • Tristan says:

      The original advocates of lean philosophy are quite adept at using it for incremental and leapfrog innovation at Toyota and have used it consistently for decades to reduce defect rates and speed development.

      I find that most agile projects I have heard and seen that did not live up to the manifesto were not agile projects. It’s right there in your sentence, “did not live up to the agile manifesto.”

      • VM says:

        Toyota used Lean for waste elimination, and towards reducing defects in their production cycle, not for software development. The objective was much different.

        If you try to adopt Lean for developing a business critical application/product, then it is definitely not a right strategy as the agile manifesto is incompatible, misaligned and irrelevant

        • Tristan says:

          I haven’t been in a car without software in a very long time, so I can’t speak effectively to this. Nor have I been in a non-mission critical car for that matter. My life literally depends on my car functioning properly!

          I have found lean easier to apply in mission critical products. The more critical, the easier to find the pain point, the appropriate value proposition, and avoid building unnecessary features.

          It’s when the value proposition is very minor that I find lean almost impossible to apply and inappropriate.

          Games for example. It’s very difficult, although not impossible, to apply lean to game development.

    • Anirudh says:

      Its called the minimum “viable” product for a reason.

  8. Tristan what a fantastic piece! It came very opportune as I prepare my next blog entry about discovering a gold mine of projects ready for part open, part proprietary software developments.

    • Tristan says:

      Thanks very much Miha!

  9. mark terry says:

    Nice post…. and two thoughts.
    1. Perhaps we could make more use of ‘anti-patterns’ in the lean community to help people better understand the principles & tools: Lean Waterfall is a great example.

    2. Enterprises will always struggle to implement lean best practices given their departmental structured approach. Actually – not just Enterprises – two person start ups can still act in silos… with similar results :-(

    • Tristan says:

      Good observation. Who was it that said that any group of 3 or more people has organizational politics?

  10. Pingback: Lean Startup News | LaunchHack

  11. Pingback: Content Strategy for Mobile: reread | Naga

  12. Pingback: # of hyphotheses | Management Briefs

  13. This is a very good analysis of the limits of silo-based learning loops. Your diagrams remind me of work done on “Concurrent Engineering” where the goal was to get all of the different engineering, manufacturing and test disciplines collaborating in the same iteration loop on a product team.

    This is a great insight:

    “Value is determined by the customer in the act of paying for a product. 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.”

    • Tristan says:

      Is that different that concurrent set design? Where you have multiple teams running iteration loops with different, but overlapping, feature sets?

      I am recalling Mary Poppendieck’s explanation of the Polaris submarine development.

  14. Pingback: Stephen Darori Early Stage Threshold Curve Model

  15. Pingback: Agile Anti-Pattern: The Lean Waterfall | Projec...

  16. Pingback: SKMurphy, Inc. » Quotes For Entrepreneurs–November 2013

  17. Pingback: Quotes For Entrepreneurs–November 2013 | WiseGen Informatics Private Limited

  18. Pingback: Agile Anti-Pattern: The Lean Waterfall | Agile ...

  19. Pingback: Trading Waterfall silos for Agile silos | jay.manaloto.ibm

  20. Pingback: BRINKLEY WARREN | Impactful Innovation & Lean Startup Zen

  21. Pingback: Agile Anti-Pattern: The Lean Waterfall | Agile ...

  22. Hannes Seeberg says:

    Add the human figure in the middle of the loop too. It will work as a reminder of what the lean is all about.

    Also, using the word “Customer” is a bit tricky, as the customer is not always the end-user.

  23. Thierry Dagaeff says:

    Excellent. Actually, your point is made very obvious just by looking at the graphics. And I so totally agree!

  24. Pingback: Lean Startup in the Enterprise Anti-Pattern: The Lean Waterfall by @TriKro | SIMULACIÓN EMPRESARIAL

  25. Anita Wijayanti says:

    Dear tristan.
    Do you know about fuzzy analytic hierarchy process in marketing mix?
    Please help me if you know that.
    Thx :)

    • Tristan says:

      Sorry, never heard of it!

Leave a Comment

Your email address will not be published. Required fields are marked *