Steve Blank AgileFall – When the waterfall goes back into agile



This article has already been published in the Harvard Business Review

AgileFall is an ironic term for program management where you are trying to be agile and lean, but you continue to use cascading development techniques. This often gives a result that looks like a combination of floor wax and dessert topping.

I just attended a project management meeting where I saw AgileFall perform first hand. The good news is that some adjustments in progress have put us back on track.


I just spent half a day with Henrich, product manager of a Fortune 10 group company. We help them convert one of the critical product lines of an existing division of one. Traditional cascading project management process with lean management.

Henrich is smart, innovative and motivated. His company is facing the disruption of new competitors. He realized that the traditional development of Waterfall was not appropriate when the problem and solution had many unknowns.

This product line has 15 project leaders overseeing 60 projects. Over the last few months, we have helped him apply the basic lean principles to these projects. All are Horizon 1 or 2 projects: they create new features for existing products targeting existing customers or redirect existing products, tools or techniques to new customers. Teams are now creating Minimal Viable Products (MVPs), coming out of the building to actually talk to users and stakeholders, get permission to rotate, and so on. All the good Lean basics.

AgileFall in real life
But at our last meeting, I realized that Heinrich was still manager his project managers using a cascade process. The teams only registered – wait – every three months during a formal review of the schedule. I heard Henrich mention that the teams complained about the volume of paperwork that he had them fill out for these quarterly journals. And he was dissatisfied with the quality of the reports because he felt that most of the teams had written the reports the night before the exam. How, he asked, could he get even more performance measures and timely reports from project leaders?

At first glance, I thought, what about more and more data? Is not that what we want – evidence-based decisions? I was about to let myself be led on the path of seduction by suggesting even more efficiency measures when I realized that Henrich still had a process where success was measured by the reports, not the results. It was the same reporting process as the one used to measure projects that used a linear, step-by-step waterfall.

(To be fair to Henrich, his product team is a lean island in a company where Waterfall still dominates.Although his groups have changed the mindset and pace of the organization, the people he brings back must not not yet learning agile / lean learning and the results – they just want to see the paperwork.)

In both cases, we needed a very different project management mentality.

Lean Project Management Philosophy
So our discussion was fun. Over the course of the conversation, we agreed on ways to manage projects using some operating principles of Lean / Agile project management (never mentioning the words Lean or Agile.)

  1. It is the individuals who create the value (find the solution / mission ft) and not the processes and reports
  2. However, the process and the reports were still essential for top management.
  3. It was more important for the teams to build incremental and iterative MVPs that are obsessed with the documentation / preliminary reports.
  4. Allow teams to use what they learned when discovering customers rather than blindly following a plan that they sold you on the first day
  5. Progress towards results (solution / mission ft) is non-linear and not all teams progress at the same pace

Rotate the process
Without much convincing, Henrich agreed that instead of conducting quarterly reviews, the management team would speak to 4 or 5 project managers each week and review 16 to 20 projects. This meant that the interaction cycle – even if it was still long – would go from the current three months to at least once a month.

More importantly, we decided that he would focus these conversations on results rather than reports. There would be more verbal communication and a lot less paper. The reviews would focus on frequent deliveries, incremental development, and how leadership could remove barriers. And Henrich's team would continue to share progress reports between teams so that they can learn from each other.

In sum, the radical idea for Henrich was thathis role was not to bring down the paperwork. It was to push the direction towards the results, and then to translate its progress in the chain.. Although it was great for the teams, it prompted Henrich to report progress to his leaders in the way they wanted to see.

At the end of the meeting, Henrich asked his team, "What are the good team members to handle a lean process versus a waterfall?" managed by fewer people able to operate in a chaotic learning environment, as opposed to a process-driven execution environment.

I can not wait for the next meeting.

Lessons learned

  • AgileFall is an attractive trap: it uses some Lean processes, but retains the expensive elements of Waterfall.
  • The goal of leadership in lean product management is not to reduce paperwork. It is to push the direction towards the results and to translate its progress in the chain

Classified in: Customer Development, Harvard Business Review |