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.

When I started applying the lessons from my “Scrum for Knowledge Work” in product development teams with deadlines, it became clear right away that some things were working better than others. The structure made it possible to implement Dr. Ward’s vision for “learning before commitment.” But teams were overwhelmed with the number of questions they […]

I was fortunate to work in an Advanced R & D lab first, because the entire mission of such a lab is to learn, and then share what they learn. All the burden of execution belongs to other teams. This makes them a clean test case for how to apply Agile principles to an organization that generates value by building knowledge. We were fortunate to have a program that led so naturally to our first breakthrough.

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 . . .