Rapid Learning Cycles is Agile for Knowledge Work.

Many Agile experts would disagree with this statement. Rapid Learning Cycles has evolved far away from its roots in Scrum and dictates few of the tools that fall into the Agile toolkit. In fact, I’ve had clients — and prospective clients — tell me that they were told “We can’t use Rapid Learning Cycles because we have to use Agile.” Whenever I see this, I know that the organization is following Agile practices and tools but has not internalized the Agile principles.

It’s not just Rapid Learning Cycles. Any practice or tool that is not on the approved list of Agile tools — especially if they were used in the past to support “waterfall” development — is at risk of being put on the “not Agile” list of tools to avoid. If you don’t know the principles behind Agile, then you don’t know why the practices and tools work. If you don’t know why they work, then any change to them threatens your ability to deliver benefits from Agile.

I’ve encountered many advocates for Agile, including many consultants and coaches, who treat Agile like it’s a religion, one with rituals that must be adhered to strictly, beliefs that cannot be questioned, and strong boundaries to protect the Agile teams from outside influences that would dilute the team’s use of Agile practices and tools. Such advocates have confused the rituals and beliefs with the principles behind them. They believe that when they expand Agile into new spaces, they are bringing the rituals, beliefs, practices and tools — not the principles.

They’ve fallen victim to the cognitive trap of The Law of the Instrument.

The Law of the Instrument: If You Have a Hammer, Everything is a Nail

Most of us have heard “If you have a hammer, everything is a nail.” This expression has been around since at least the 1800s. The first documented use of this quote comes from Abraham Kaplan, an expert on research methods in the 1950s and 1960s who often said, “Give a small boy a hammer and he will find that everything he encounters needs pounding.” He called this The Law of the Instrument. Psychologist Abraham Maslow refined this to “If all you have is a hammer, everything looks like a nail.”

The Law of the Instrument applies to business processes and methodologies especially well. It’s a principle that consultants and thought leaders are especially prone to trigger, because we make money by selling our expertise. It’s natural for any business to look for opportunities to grow their  markets and expand their influence. We are no exception. We naturally look for situations where our systems might be applied. This is a cognitive trap.

The Law of the Instrument is a Cognitive Trap

I’ve been deeply engaged with two communities where the Law of the Instrument has been triggered: the Lean community and the Agile community. They both have in common a set of principles that are sound and broadly applicable. Lean is focused on eliminating waste through better problem-solving. Agile focuses on continuous delivery of value in a flexible structure that accommodates change. They actually have common roots in applying insights from queueing theory (reduce batch sizes), using standard work for repetitive tasks and empowered, self-organizing teams. They even share the concept of a daily stand-up meeting.

Every area of a business has waste, and every area benefits from continuously delivering value. So, it’s no surprise that Lean started in Manufacturing but has always seen itself as a comprehensive enterprise management system that should be used everywhere. Agile started in Software but now sees itself as an enterprise management system that should be used everywhere. At the level of principles, they are on solid ground. The problem is at the level of practices and especially the tools.

Same Principles — Different Practices and Tools

Here is one example that I’ll cover in-depth in a future article: in general, we know that continuous flow is better than big batches. We see lots of examples of this in the physical world, and in the virtual world. In Lean, this is the principle of “one piece flow.” In Agile, this is the continuous delivery of value, by organizing work into small iterations.

Lean practices and tools that support one piece flow include kanban systems to coordinate upstream and downstream processes, value stream maps to highlight waste and rapid tool changeovers. In Agile, the main practices are Sprints, Sprint Planning and Demos, Test-First Development and Daily Builds. The main tools are things like kanban boards and automated regression tests.

You’ll note that “kanban” overlaps here although the words are used differently based on context. This is not a coincidence. This is what happens when you try to bring a tool from one problem domain to the other: it gets adapted so heavily that it loses its original meaning. A Toyota line worker would have a hard time recognizing what a software team calls a “kanban” and has never seen a kanban board, even though the concept originated there. The thing they have in common is the principle of continuous delivery / one piece flow.

In Agile, we’re seeing the same thing happen with “user story” and “demo” — when you take the practice or tool out of context, it has to be adapted beyond all recognition. There’s a better way: focus on the principles, and then develop the practices and tools you need to fulfill them.

Rapid Learning Cycles Applies the Principles of Agile to Knowledge Work

Rapid Learning Cycles also embraces the principle of continuous delivery — the continuous delivery of knowledge. We organize our work into short Learning Cycles with real-time knowledge capture. The short Learning Cycles drive more continuous flow of knowledge, by giving structure to the time a team has for learning and helping them organize their learning into a sequence that maximizes their ability to use the time they have to build the most important knowledge.

Real-time knowledge capture ensures that the organization realizes the value from closing a Knowledge Gap, which is not the prototype or the lab report. For knowledge work, the value comes from interpreting the lessons learned from the prototype or lab report to generate the knowledge needed to make better decisions.

Continuous Delivery of Tasks vs. Continuous Delivery of Knowledge

Continuous delivery of tasks does not inherently deliver value to this form of knowledge work the way it does on a manufacturing line or a software team, which learns by building and testing code. The fact that a drawing is done means much less than the fact that a software module or subassembly is done and passed all the tests. The software and manufacturing teams are done-done. The hardware team’s work is only done to the extent that the decisions embodied in the drawing are good decisions, that rest on solid knowledge.

This is the core difference between Rapid Learning Cycles and most other Agile methodologies: we organize around knowledge, not tasks. In hardware development and in domains like it, decisions have lasting consequences and changing them late is expensive. The way to achieve agility is to make good decisions that stick, within a workflow that supports building the knowledge you need to make decisions with higher confidence.

We use the principles of Agile to improve decision-making, just as Agile Software Development practices help software developers make better decisions in their domain and Lean Manufacturing practices help manufacturing workers make better decisions in their domain.

Over these next weeks, I’ll demonstrate how the Rapid Learning Cycles framework adapts the principles of the Agile Manifesto for hardware development and other areas that share its combination of high uncertainty and high cost-of-change. These are places where Agile Software practices and tools are hammers when the team just needs a screwdriver.