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.

Most of what passes for “Agile for Hardware” is really Scrum for Hardware: organize work into sprints, manage tasks with backlogs, and perform the “ceremonies” of Agile: daily scrums, etc. Or they impose another Agile method, asking the hardware teams to conform to a process built for software.

And I get that, because in 2010, that’s where I started, too. But when it was clear that it didn’t work, I asked “why?”. The answers to those questions were transformative and morphed “Scrum for HW” into the Rapid Learning Cycles framework.

The Starting Point: Scrum

Scrum is the Agile method that I’ve used the most personally, so when the call came to apply Lean and Agile to an advanced R&D organization, that’s where we started:

• Four-week Sprints.
• Daily standups which quickly became weekly standups.
• Backlog of work packages, that rolled up into a larger Epic. We didn’t call them User Stories — instead, we called them Hypotheses.
• Kanban board for tracking progress on tasks within a Sprint.
• Sprint demo, planning session and retrospective at the end of a Sprint.
• We attempted to use story points to calculate velocity, and a burndown chart to track progress, but that was quickly abandoned.

If you’ve worked with Scrum, all of those elements will look familiar to you. Yet immediately we ran into problems. At first, we thought these were the normal problems teams have when settling into the process. But it soon became clear that we had bigger problems:

• Much of the execution of a work package spent a lot of time in Waiting that was outside the team’s control — for supplies, for equipment, for external analysis, for feedback from reviewers, etc. Not all of this waiting time was predictable. So, in practice, the researchers had several things “in progress” or “waiting” at the same time — and on the Kanban board, it didn’t look like the team made much progress week-to-week.
• Some of the experiments took a long time — much more than a single sprint — with hands-on involvement the entire time. It felt artificial to break them up, and that made it harder to manage them since we had to manage pieces instead of the entire work package. They were also more expensive to run, in both time and money.
• Most experiments were not independent. They were part of dependency chains that constrained the backlog. The backlog doesn’t have a good way of tying related items together. We could address simple dependencies through prioritization but that was clearly inadequate to manage the program.
• The team was an alliance of specialists, who could help each other in small ways but could not actually do each other’s work. Sprint planning was more an exercise of asking these individuals to make their own sprint plans, but without the visibility into dependencies they needed to make good decisions on their own.

Despite these shortcomings, they liked the process. They liked the ceremonies as times to get together, learn about each other’s work and get coordinated. The visualization of their work had been a revelation. They, and their managers, could see what they were doing at any point in time, and that was helpful for them.

So, this team didn’t abandon Scrum. Instead, they began to transform it. And I accelerated their progress by running other experiments with other teams at different companies making products that also had to be produced in the physical world, then feeding back the results.

Along the way, we had three core breakthroughs that led to the development of the Rapid Learning Cycles framework:

• “What will you learn?” not “What will you do?”
• “Make decisions at the right time, with the right people, and the best available knowledge.”
• “Visualize the flow of knowledge from idea to launch.”

Over my next series of articles, I’ll describe those breakthroughs one by one, showing how the tension between Agile Software theory and the teams’ on-the-ground experiences led to the breakthrough. I’ll share how each one strengthened the framework, making it more resilient, more effective and more repeatable, achieving the goals of Agile by using different means.

A Mature Agile System for Delivering Physical Products

Finally I’ll share how the teams I coach have integrated the framework into an Agile system that serves innovation and product development teams making physical products — not just hardware, but also agricultural products, pharmaceuticals, specialty materials and more — anything that has to be sourced, produced and shipped to the next user in the value chain.

You’ll learn what it takes to build an effective system of Agile for Hardware that delivers on the promises of flexibility and responsiveness that are embedded in the Agile Manifesto and the Lean / Agile Principles of the Scaled Agile Framework, so that your organization doesn’t just perform the ceremonies of Agile. You experience the superior results that arise from agility.