This article is part of a new series on Agile for Hardware Development. I invite you to sign up to receive the entire series if you want to learn more about how Rapid Learning Cycles fits into the Agile universe.

When people with Agile experience see the Rapid Learning Cycles framework, it looks familiar. That’s not an accident.

Our first attempts with Rapid Learning Cycles used Scrum. We knew that some people in the Scrum world, including some well-known consultants, were zealous in encouraging teams to adopt every element of Scrum exactly as written or “it’s not really Scrum.” 

Yet we learned within a few cycles that Scrum had potential but that it would require heavy adaptation in order to work well, because the nature of the work was different.

Now we see the same pattern with other Agile methods, including Scrum-at-Scale and the Scaled Agile Framework. Nothing we’ve seen has convinced us that these method are any more appropriate for hardware development than Scrum.

The Nature of Work: Learning vs. Doing

Scrum and traditional project management tools all manage projects by managing activities: what a team is doing. Traditional tools assume that the project planner knows what the team should be doing, that the plan can be locked down, and then changes can be managed via controlled plan revisions. 

Agile tools assume that the plan will change — and should change — often as new information comes in. But Scrum, SAFe and other Agile methods still manage what the team is doing: implementing user stories.

For Rapid Learning Cycles teams, managing at the activity level meant that teams spent their time together talking about what they did, instead of focusing on what they learned. It’s far more important for a team using Rapid Learning Cycles to spend team time talking about Knowledge Gaps, Key Decisions and what they can do to learn faster.

Rapid Learning Cycles Needed Its Own Vocabulary

We learned fast that Rapid Learning Cycles required its own program management methods because the nature of the work was learning instead of doing. This means:

• The unit of work is the Knowledge Gap — the piece of knowledge the team needs to build so that the team and its decision makers have greater confidence in the decision. There is no value in attempting to convert a Knowledge Gap into a user story.
• Most Knowledge Gaps roll up into Key Decisions, and managing the flow of these Key Decisions is the best way for the program manager to manage the health of the program. There is no analog in Agile because Agile assumes that user stories can be implemented by anyone in any order. Epics are not good proxies for Knowledge Gaps.
• The effort to develop and manage a complex Gantt chart at the activity level — or prune an activity-based backlog — is almost entirely waste, and drives team members to fulfill the plan instead of seeking out better, faster ways to learn.
• The discussion at the events that close Sprints / Learning Cycles need to be focused on what the team is learning instead of what they have done. Demos are interesting but reporting the results from learning activities of all kinds are far more valuable.

Different Language to Reflect Different Results

This diagram shows how we converted the activity-focused structures of Scrum into the knowledge-focused elements of the Rapid Learning Cycles framework.

If you have software teams running Scrum, we encourage you to use the vocabulary of Rapid Learning Cycles, to reflect the fact that the nature of the work is different from the work of implementing user stories.

That will keep the Scrum purists from complaining to your leaders that you’re “not doing Scrum” as your teams learn as fast as possible to get as much value as possible from the time they have to learn.

You’ll still have to contend with those who think you should “just use Agile” for everything — but you owe it to your teams to protect their ability to use the best tools and practices for the nature of their work.