You can read all of the articles and subscribe to receive the entire series on the Agile for Hardware Development series page.
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.
Software teams also generate value by creating knowledge in the form of things like algorithms and user interface designs. But they have a natural repository for that knowledge in the form of their code library. Once that library has been developed, it can be replicated and reused over and over, with very low transaction costs. They can test the library using automated regression testing, and they can easily change it, then test whether or not the changes had any unintended side effects.
That’s not the kind of knowledge this research team built. They were working to build knowledge around a biological process, in vitro, so that their company could perhaps identify a target for drug therapy. They were running biochemical experiments that attempted to model human biology, but these lab experiments were well-understood to be models.
There would be years of work to turn this knowledge into a new therapy, and the final result would look nothing like the models. But without this foundational work to answer important questions about these biological processes, those therapies could never be developed.
What Are the Critical Questions?
This research team had a portfolio that called out specific sets of questions to answer. The scientists on the team designed experiments to answer these questions and then technicians carried out the lab work and data collection. Then the scientists analyzed their results.
These stages lend themselves naturally to a kanban board with these columns: Backlog, Experimental Design, Experiment, Analysis, Done. So far, so good. But these experiments were expensive and time-consuming, with the risk that an experiment would lead to inconclusive results. The team reduced that risk via peer reviews and some external reviews before the experiments were run.
This means that even “Experimental Design” took several weeks. The experiments themselves took much longer. The team quickly realized that the kanban board wasn’t helping as much as they thought. They could see the work on the board, and at first that had been exciting, but it wasn’t moving.
One solution that’s often used in situations like this is to break the work packages down into smaller pieces that move more often. The team didn’t like that idea — it didn’t make sense at all to them. There wasn’t a lot of value to them to see the individual tasks — they wanted to see the flow of the research questions.
Visualize the Flow of Questions to Optimize the Flow of Knowledge
They also saw that optimizing the flow of specific tasks was not the best way to speed up their research. Instead, they had two opportunities to tune their process so that they could build more knowledge. The first was in the sequence of questions themselves.
The answers to one question feed into other questions. Visualizing this sequence made it much more obvious where they had opportunities to optimize the sequence of their experiments. The sequence changed often, so sticky notes on a whiteboard was the best way to manage this flow. They ditched the backlog fairly quickly, replacing it with a simple diagram showing how the experiments flowed into each other.
The second place to speed up was in the Experimental Design, when the experiments were planned. That was the opportunity to consider a different approach, such as a smaller, rougher experiment to validate an idea before doing a more extensive, rigorous experiment.
This means that the first shifts we made transformed the focus of a Sprint from doing to learning. Instead of “how much can we get done?” the team started asking “how much can we learn?”
“How much can we learn?” changes the game
Teams stopped focusing so much on specific activities inside work packages. Instead, they began challenging themselves to learn more, and more deeply. They began challenging each other: “Do we need this long experiment, or can we run this shorter experiment first? Maybe if we learn enough, we don’t need the long experiment.” They began finding faster, cheaper ways to learn. They started to become a lot more effective, as measured by their research productivity.
That’s where Knowledge Gaps came from: the specific questions that the early teams set out to answer. From there, it wasn’t a big leap to begin thinking about chains of questions to answer as they worked out the sequence, and then recognizing that those questions ultimately fed into decisions being made about the direction of the research.
“What do we need to learn to make this decision?”
On the Lean side, Dr. Allen Ward had long advocated for the practice of building knowledge prior to making decisions on a development program. His research at Toyota showed that they spent much less time in rework loops of revisited decisions. Instead of waiting to the end to validate their decisions, they tried to learn as much as they could before committing to a decision. As a result, Toyota was able to speed through execution of a new car model with many fewer problems in late development than their peers.
This is because most product development has a lot of long learning cycles: teams make decisions in early development that don’t get validated until later in development. Then they have to go backwards in the process to fix the problem, causing project delays, cost overruns and disappointing results.
This problem is inherent to “waterfall” development in both hardware and software. It is, in fact, the very problem that the early proponents of Agile Software Development wanted to eliminate, and the reason why “waterfall” is a dirty word in the Agile world. The solution to this problem is also the same — at the level of the principle behind decisions — but the implementation of that solution is completely different.
Build Knowledge Before Making Decisions to Eliminate Waterfall Development
The inherent problem of waterfall development is that it forces a team to make decisions without the knowledge needed to make those decisions with confidence. The solution is to wait to finalize decisions until you have the knowledge you need. The concept of the Last Responsible Moment comes out of the writings of Mary Poppendieck, who wrote several books on Lean Software Development. These books explained why Agile works, using Lean principles, and she referenced Dr. Ward’s research in her work.
Agile Software teams solve the problems with waterfall by building their software incrementally, making only the decisions around the specific work packages they’ve chosen to complete in a Sprint. They delay even the decisions about what work packages or user stories to implement, choosing them out of a backlog at a Sprint Planning Meeting. They get immediate feedback first from their own tests and then from the users at a demo to validate their decisions. When the code passes all the tests and users have validated that it works for them, then it’s done-done.
The research team started out with a similar approach, but soon realized that the knowledge they were building could not be validated in a single cycle. Individual work tasks could be done-done, but that wouldn’t improve the quality of their decisions, or help them optimize the flow of knowledge through their research program so we didn’t even try to do it. The answers to the question, “What are we doing?” were not very interesting or useful to a team that is so focused on building knowledge.
Instead, we worked together to design a system to develop better answers to the question “What are we learning?” so that they could make better decisions about the direction of their research. The first breakthrough element of the Rapid Learning Cycles system was in place.
This team was going well, but when I applied the same ideas to a product development program, with hard deadlines and deliverables, this learning-driven approach proved to be necessary but not sufficient. We had to dive deeper into how to use this knowledge to make better decisions.
Hat tip to Kathy Iberle, who was my partner on this program, helping to steer this team towards useful interpretations of Agile principles when the practices were not workable. Today she is a Rapid Learning Cycles Certified® Advisor, and the co-author with me on our book When Agile Get Physical.
