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 . . .
Last week I had a frustrating conversation with an Agile Software Development expert, focusing on Agile for Hardware, who shall remain nameless. In that conversation, the person argued that organizations didn’t need — and didn’t want — more than one framework for program management. They should Just. Use. Agile. The conversation felt all too familiar.
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.”