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 . . .
Katherine’s Latest Post
Start Here: Rapid Learning Cycles 101
I live in the Pacific Northwest, the home of Starbucks and many small craft coffee roasters. I like my coffee strong and dark. When I travel, I bring my own coffee and mini coffee maker so that I can enjoy my first cup of the morning just the way that I like it. Yet this […]
Teams adopting the Rapid Learning Cycles framework for the first time often stumble over the basics of how to manage a program that has such an unconventional structure. Rapid Learning Cycles are, by definition, fast and cyclical. I’ve written elsewhere about how traditional project management tools, like Gantt charts are not designed to handle programs […]
Agile for Physical Products
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.”