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 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.
The meeting took place at 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.
Our client, their head of product, 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.
The product line that’s our focus 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 obtaining permission to pivot, etc. All good Lean basics.
But in our latest meeting, I realized the head of product 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 the client 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 our client 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, this team is a Lean island in a company where the Waterfall still dominates. While this group 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.
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.)
- It is the individuals who were creating the value (finding solution/mission fit), not the processes and reports.
- However, the process and reports are still essential to management above him.
- Having the teams build incremental and iterative MVPs is more important than obsessing about early documentation/reporting.
- Allowing teams to pivot to what they learned in customer discovery rather than blindly follow a plan they sold you on day one is essential.
- Progress to outcomes (solution/mission fit) is non-linear and not all teams progress at the same rate.
With not too much convincing, our client 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 our client’s team would continue to share progress reporting across the teams so they could learn from each other.
In sum, the radical idea was that the head of product’s 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 the product head to report progress back up to his leadership in a way they wanted to see it.
I knew the lightbulb had fully gone on near the end of the meeting. The client 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.