Why Constructive Agility Is Not a Process Framework

Agility does not arise from process.

There is no such thing as an agile process.

Let me say that again: there is no such thing as an agile process. It is nearly an oxymoron.

Agility arises from how people escape process.

Let’s consider an example:

Suppose that a company makes 100 products, and has 300 product development teams.

Now suppose that someone on one of those teams realizes that a component used by the product needs to change. For example, suppose that the component is a software “core microservice” that is used by most of the other digital products; or instead suppose that the component is a hardware assembly such as a controller that is used in several machinery products. In any case, it needs to change. Let’s not investigate why—that’s not the point. That point is that there is a new issue that is blocking development, and to address the issue requires making changes that will affect other teams—possibly lots of other teams and even other products, perhaps in multiple lines of business.

What should be done to resolve this issue?

A process-based approach is usually performed by circulating a change request, or waiting for the next integration planning. Both of these approaches take months to resolve the issue.

In contrast, what could happen is that the person who discovered the issue can identify which other teams are likely to be affected. If she reaches out to those, they will probably say “that’s unfortunate, but we are busy and don’t have time to deal with this, because it is not a problem for us”. So she might reach out to her own leadership. At this point, they might respond in one of these ways:

1. “Create a change request”.
2. “Let’s bring that up in the next integration discussion—six weeks from now”.
3. “Let’s find out who needs to be involved and start a discussion about that right now”.

Approach number 3 is an agile approach. There is no waiting. The issue is addressed right away, and just the right people are pulled into the discussion—no one else. There is no process: it is entirely ad hoc.

This is actually what happens at SpaceX—one of the most agile companies there is.

Agility Results From Behavior—Not From Process

In the above example agility arose from behavior: the tendency of individuals to proactively raise issues, bring the right people together, and push for an expeditious solution.

At this point things could get stuck: they might not be able to reach consensus or be sure of how to fix the problem. In the case of SpaceX, they do not wait until they are completely sure that a solution will work. Instead, they have a “51% rule”: if they are 51% sure that something will work, they try it to see what happens. So they never get frozen by uncertainty.

These are behaviors. But behavior is a result of culture—and also influences culture. In this case, the culture needs to be collaborative and tolerant of mistakes. It also needs to be one that places a high value on speed and outcomes—over being right or following a process.

Agility therefore results from behavior, and also from organizational culture. But behavior and culture are not enough. If you ask someone who is trained in waterfall methods how to improve quality, they will pull from the mental toolbox and tell you to increase reviews and checkpoints. But if you ask the same question of someone who is trained in Lean and Flow methods, they will tell you to increase your automated test coverage and your test frequency. Their mental toolbox is different. Those “Lean” and “Flow” methods are patterns for solving problems.

A pattern is not a template to reuse because it will look different in every situation. Instead, a pattern represents an idea for how to solve a problem. Patterns like that are what one can extract from Agile frameworks; but patterns should not be copied: their essential idea should be gleaned and then applied where it is useful. Each application is unique.

So there is a trifecta that is needed: culture, behavior, and knowledge of effective patterns.

Process Matters Too—But Don’t Start There

If you have the right behavior and it is supported by the culture, and if you have the right knowledge, you will create the processes that you need. Process is not the place to start. Start with your objectives, and decide what is the minimal process that you need for your current situation.

Process needs to change over time, depending on what you are doing—you should not have a static process. For example, when SpaceX developed the Dragon capsule, they had very rapid development with almost no process at all. But as the vehicle approached flight certification, they added process—a lot of process. In other words, they adjusted their process over time to match the needs of the moment, including the risks.

If you adopt someone else’s process, you have skipped the learning.

Process needs to be minimal for the needs of the situation.

A critically important thing that is often overlooked is that in the course of creating your own process, you learn. If you adopt someone else’s process, you have skipped the learning.

That’s why Constructive Agility is about learning, trying—in the form of creating your own strategies and processes—reflecting, adjusting, learning more, and so on.

The result is that you learn what your process needs to be, and you will naturally fine-tune it according to what is needed.

And you will do most things without process—behavior is how most activity will occur, because people have learned what they need to do, and have learned agility-promoting behaviors, patterns, and judgment, supported by their culture.