Up to this point in the story, I had assumed that the Knowledge Gaps would go into a backlog that the team would manage in the same way that software teams manage their backlog of user stories. As soon as we had the right list of Knowledge Gaps (the ones driven by the need to make Key Decisions) we could see that wasn’t enough. We also needed to visualize when each Knowledge Gap needed to close, so that we could make decisions at the right time.

Agile Software methods, including Scrum, usually include a backlog: a prioritized list of work packages or user stories. In the software world, the best work packages and user stories are independent of each other: they can be executed in any order. And on a software development team, the person assigned to implement a user story is, to some extent, flexible. You may have people who are stronger in one area than another, but for the most part, they can all write tests, write code and offer intelligent feedback when reviewing others’ code.

Agile Software Development Assumes Independent Work

In pure Scrum, the user stories represent independent features that can be implemented in any order — so the correct order is the one that will deliver the most customer value earliest in the program. The Product Owner takes on the role of determining what customer value will be delivered in a Sprint (the Sprint Goal), and the team pulls the User Stories out of the backlog that they need to deliver this value (the Sprint Plan).

This works well to the extent that the user stories are truly independent, and the team members are truly flexible to deliver any user story. In fact, Agile coaches work with teams to improve the independence of their User Stories as one way to improve the effectiveness of Agile Software Development.

It’s rarely this clean, even in software. Some things (security, basic architecture work) have to be done first. Then you don’t want to keep a UX designer idle because the Sprint Plan calls for improving key algorithms to deliver faster, more accurate results. So, most teams incorporate resource inflexibility into their Sprint Plans, allowing the UX Designer to work ahead on some things while the others work on the guts of the algorithms. The more dependencies and resource constraints you have, the more inflexibility you have.

Physical Product Developers Have Dependencies to Manage

Physical product development has many more dependencies and much more inflexibility. I have seen over and over again that physical product developers end up tripping over the backlog for this very reason. The backlog can only manage the simplest of dependencies via prioritization: I must do A before B; therefore, A has a higher priority than B until A is done. What happens if B is also dependent on C, which is dependent on both A and D, and so on? If you don’t visualize this chain of dependencies, it’s hard to even recognize most of them.

In some of the worst cases, the teams have completely lost track of their dependencies, to the point of failing to deliver the CAD models needed to build major system prototypes in time to start production on time. More often, I’ve seen that the Project Leader has a Gantt Chart hidden away someplace where their misguided Agile Coach can’t find it. This hidden Gantt Chart drives the Sprint Plan even if the team is performing all the “ceremonies” of backlog-based planning.

Why Do We Need a Backlog When We Have a Plan?

In 2011, I interviewed Suzanne von Egmond at Philips for my first book. She had developed a system called “lean scheduling” that combined the best of backlog-based planning with the need for a schedule. Was this the answer to the need for an Agile plan that worked for physical products?

The distinguishing feature was a multi-level plan:

• Top Level Plan that covered the entire program through launch and production ramp, that forecast the team’s path through the Philips phase gate process.
• 2^nd Level Plan that covered the current phase of work, typically six months or so in early development, focused on the decisions that needed to be made in this current phase, to hit the next gate.
• 3^rd Level Plan that focused on the major activities and deliverables for the next quarter or so within this plan.
• 4^th Level Plan that represented the activities to be done on a daily basis for the next Sprint, which could be managed on a kanban board.

There was no backlog, except at the lowest level, and that backlog was populated from the work to be done in the 3^rd Level Plan. Everything else was mapped out on a rolling basis: the 2^nd Level Plan when the team entered a new phase, the 3^rd Level Plan once a quarter, the 4^th Level Plan once a Sprint.

Physical Product Development Plans Are Multi Level Plans

I immediately adapted Suzanne’s work to fit the Rapid Learning Cycles framework we were building, and that led to the 3^rd breakthrough: time-based multi-Level Plans with “ceremonies” around Knowledge Gaps AND Key Decisions.

• Top Level Plan — established at program charter and changed only rarely.
• 2^nd Level Plan — established at the start of a phase in a Kickoff Event, and reviewed often, that mapped the flow of Key Decisions through this phase of the program.
• 3^rd Level Plan — also established in the Kickoff event but updated more often, that assigned Knowledge Gaps to specific buckets of time within the phase.
• 4^th Level Plan — to map out the activities to be done to close Knowledge Gaps and complete the team’s deliverables.

In practice, we’ve found that most teams don’t use the 4^th level of the plan. Individuals take responsibility for closing Knowledge Gaps, including the plans to close those gaps. There are better ways to manage their effectiveness at closing Knowledge Gaps than managing their time at an activity level.

We’ve also found that adding major deliverables into the 2^nd Level Plan can help, and that as a team shifts into execution mode, the 3^rd Level Plan will include more mandatory activities and deliverables, with a Gantt chart to manage them.

Events Pull Knowledge Through the Program

Finally, the four levels of plans naturally led to the events we needed to pull more effective learning and decision making:

• Top Level: Gate reviews focused on the major deliverables for a phase.
• 2^nd Level: Integration Events focused on making Key Decisions.
• 3^rd Level: Learning Cycle Events focused on sharing the team’s work to close Knowledge Gaps.
• 4^th Level: Status Events for reporting progress on activities and getting help where needed.

With these additions, we had a stable structure that began to deliver repeatable results: when we introduced it to physical product development teams, they either got faster or they knew exactly what had gotten in the way. They had many fewer long, slow loopbacks and when they did encounter one, they could trace it back to its root cause to keep it from happening on future programs.

They were able to achieve this because they knew what Key Decisions they needed to make, when they needed to make those decisions, and what knowledge they needed to make the best possible decisions. Then they had an actionable plan to build that knowledge, a structure to ensure the knowledge got built, and the right events for sharing knowledge and making decisions.

The Rapid Learning Cycles Framework Is Agile for Physical Products

For some time now, I had been calling this evolving framework “Rapid Learning Cycles” because Scrum and Agile both led to misunderstandings, especially among people who had only seen this work in software. With the switch away from backlogs towards time-based multi-level plans, the transformation was complete. We were using all of the principles, but few of the practices of Scrum.

Today, I see Rapid Learning Cycles as part of the Agile universe and resting on the same principles, but distinct from Scrum or its derivatives, Scrum-at-Scale, SAFe and Disciplined Agile. All of these methods help software teams with the Agile execution of activities, and work best in software or other areas, like service development, where rapid, customer-facing iteration is valuable and teams learn by doing.

The Rapid Learning Cycles framework shifts the team’s focus from doing to learning. It is Agile knowledge creation, tailored for those environments where a prototype is only as valuable as the knowledge you gain from it vs. the time and cost of producing it, and where the most useful experiments may look nothing like the final product.