Steve Blank

This article previously appeared in the Harvard Business Review

AgileFall is an ironic term for program management where you try to be agile and lean, but you keep using waterfall development techniques. It often produces a result that’s like combining a floor wax and dessert topping.

I just sat through my a project management meeting where I saw AgileFall happen first-hand. The good news is that a few tweaks in process got us back on track.

I just spent half a day with Henrich, the head of product of a Fortune 10 company. We’re helping them convert one of the critical product lines inside an existing division from a traditional waterfall project management process into Lean.

Henrich is smart, innovative and motivated. His company is facing disruption from new competitors. He realized that traditional Waterfall development wasn’t appropriate when the problem and solution had many unknowns.a

This product line has 15 project managers overseeing 60 projects. Over the last few months we’ve helped him inject the basic tenets of Lean into these projects. All are Horizon 1 or 2 projects – creating new features for existing products targeting existing customers or repurposing existing products, tools, or techniques to new customers. Teams are now creating minimum viable products (MVPs), getting out of the building to actually talk with users and stakeholders, and have permission to pivot, etc.  All good Lean basics.

AgileFall in Real Life
But in our latest meeting I realized Heinrich was still managing his project managers using a Waterfall process. Teams only checked in – wait for it – every three months in a formal schedule review. I listened as Henrich mentioned that the teams complained about the volume of  paperwork he makes them fill out for these quarterly reviews. And he was unhappy with the quality of the reports because he felt most teams wrote the reports the night before the review. How, he asked, could he get even more measures of performance and timely reporting from the project managers?

At first glance I thought, what could be bad about more data? Isn’t that what we want – evidence-based decisions? I was about to get sucked down the seductive path of suggesting even more measures of effectiveness when I realized Henrich still had a process where success was measured by reports, not outcomes. It was the same reporting process used to measure projects that used linear, step-by-step Waterfall.

(To be fair to Henrich, his product team is a Lean island in a company where Waterfall still dominates. While his groups has changed the mindset and cadence of the organization, the folks he reports up to don’t yet get Agile/Lean learning and outcomes. They just want to see the paperwork.)

In both managing down and up we needed a very different project management mindset.

Lean Project Management Philosophy
So our discussion was fun. As the conversation progressed, we agreed about the ways to manage projects using a few operating principles of Lean/Agile project management (without ever mentioning the words Lean or Agile.)

1. It was the individuals who were creating the value (finding solution/mission ft) not the processes and reports
2. However, the process and reports were still essential to management above him.
3. Having the teams build incremental and iterative MVPs was more important than obsessing about early documentation/reporting
4. Allow teams to pivot to what they learned in customer discovery rather than blindly follow a plan they sold you on day one
5. Progress to outcomes (solution/mission ft) is non-linear and not all teams progress at the same rate

Pivoting the Process
With not too much convincing, Henrich agreed that rather than quarterly reviews, the leadership team would to talk to 4-5 project managers every week, looking at 16-20 projects. This meant the interaction cycle – while 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 outcomes rather than reports. There would be more verbal communication and a lot less paper. The reviews would be about frequent delivery, incremental development and how leadership could remove obstacles. And Henrich’s team would continue to share progress reporting across the teams so they could learn from each other.

In sum, the radical idea for Henrich was tha this role was not to push the paperwork down. It was to push an outcome orientation down, and then translate its progress back up the chain. While this was great for the teams, it put the onus on Henrich to report progress back up to his leadership in a way they wanted to see it.

I knew the lightbulb had fully gone on when near the end of the meeting Henrich asked his team, “Going forward, who are the right team members to manage a Lean process versus a Waterfall?” And I smiled when they concluded that Lean could be managed by fewer people who could operate in a chaotic learning environment, versus a process-driven, execution one.

I can’t wait for the next meeting.

Lessons Learned

• AgileFall is a seductive trap – using some Lean processes but retaining the onerous parts of Waterfall
• The goal of leadership in Lean product management is not to push the paperwork down. It’s to push an outcome orientation down and translate its progress back up the chain

Filed under: Corporate/Gov't Innovation, Customer Development, Harvard Business Review |