Dustin Mattison interviewed me on how one could apply agile principles to supply chain management. The interview shows how to map Agile Base Patterns to a non-software field.

You can listen to the podcast here: The Five Characteristics of Sustainable Agile Methods, from the Future of Supply Chains blog.

Transcript

Dustin Mattison: It’s nice to speak with you today, Dan. I’m looking forward to hearing your views on the five characteristics of all sustainable, agile methods. Can you first provide a brief background of yourself?

Dan: I have a Ph.D. in computer science; I studied chaos theory and optimization techniques and parallelism back when I was a super nerd. More recently, I’ve been looking at the best ways to organize software-development organizations. As I did that, I realized that the overall organizational structure, too, had many opportunities available to it, so I started spreading out my focus to look at organizations as a whole and how they could more rapidly adapt to changing circumstances in the marketplace.

Just a little bit of background on that. I was the head of agile coaching for Skype. Before that, I was the head of agile coaching for Citrix Online, and I’ve worked with a bunch of other companies as well.

Dustin: What are the five characteristics of all sustainable, agile methods?

Dan: Maybe one of the things we should ask is: What’s the purpose of agility? Agile companies or creative organizations or people all rapidly sense changes in their environment, which is usually a marketplace; sometimes it’s your teams. They adapt to that rapidly—so they change configuration, they change the types of products they offer—and then they create rapidly as well. When you can do all those things rapidly, you can usually beat the crap out of your competitors. That’s one of the reasons why, in one of the most fast-moving creative environments we have—which is software development, and, particularly, software development on the Web—we see agile practices adopted all over the place.

One of the challenges for me was that agile is described in field-specific ways. The software industry has practices like Scrum and XP, which are software-specific, but Toyota Motor Company also has an agile practice called the Toyota Production System, and fighter pilots have a thing called OODA. Quality control has other practices as well.

When I started trying to characterize agile practices, I studied all of those things to come up with basic principles that all of them share. This discussion is really about what defines agile regardless of what industry you’re working in. One thing we wanted to eventually talk about is how this might relate to supply chains, since that’s a specialty of yours.

Here’s what agile practices all do. The first thing that you need to have to create an agile organization is clear metrics that relate to your economic progress. I use the term economic metrics to refer to the things that really drive your business. A nonprofit can have economic metrics, and those economic metrics are related to its mission. If it tries to save more people from malaria, then counting the number of people who’ve been saved from malaria by the organization is something that you would want to increase. That’s one of the metrics in your economy.

If you have an economy and you have metrics, that’s really great, but one of the issues you have is, you need to measure your progress against the economy. Here’s where you need leading indicators that you’re doing something that’s on the right path. You can’t use things like stock price to measure economic progress because it lags so far behind the actual work you’re doing that it doesn’t help you adapt fast. That’s the first principle that an agile organization has to have. If you don’t have that, you can’t build, the other patterns really build on that.

The second pattern is that agile entities proactively experiment for improvement. They measure their progress but then they look at that progress and say, “What could we change in the way we do things, the things we’re producing that might increase the metrics that we think are relevant, the metrics in our economic progress?” When they’re experimenting, they might experiment on a long-time cycle. A big, behemoth company that has a lot of slow-moving parts, it might take a while for it to actually reinstrument or reconfigure its organization to try something new. Yet you can experiment—and good companies do experiment—but it might take them a while to get that experimentation done. We don’t have an agile situation quite yet, if we just do the first two things. We can’t yet rapidly adapt to changing market conditions and create something new, because it could take a long time to complete your experiment.

The third property is the thing that really gives us a minimal agility, and that is limiting work in process. For example, the inventory in our supply chain is work in process. It’s something that someone actually delivered to a distribution center, but then it’s just sitting there with asset value, I guess, but it’s not really being deployed right away, so that cash flow is locked up in that inventory.

This is one of the things that, of course, Toyota pioneered: this idea of reducing inventory, limiting work in process by actually implementing just-in-time manufacturing. Toyota qualifies as an agile entity, and they did all of these three things. That’s pretty good. If you can do all those three things, you are agile.

One of the things that we’ve discovered in the software industry is that it’s really easy to lose agility. We have software developers, they’re very creative, people value them, and then executives may swoop in and take your most valuable contributor on a team away to work on some special project. When that happens, it can disrupt a team so much that it is no longer able to sense what’s happening. It might not be able to create something new because that disruption, which seemed almost innocent—“We needed this person to handle this important fire we were fighting”—it disrupts them so much that all the other team members really can’t do anything to create something new.

We see that sustainable agile in organizations adds a fourth pattern: this idea of embracing collective responsibility. This is pretty subtle and, I think, sort of philosophical and cultural for an organization. It says this: “When I join a team, I am implicitly signing a contract that says, ‘By joining a this team, I agree that whatever the team produces, I will feel personally responsible for making sure that the collective product is good.’”

If I am a tester and I join a team, by signing this contract I can no longer see myself as “just a tester.” If one of the developers is out and, as a result, we’re not actually able to produce something of value, then my sense of collective responsibility will motivate me to learn what I can to make up for the fact that that person is missing. That sense of collective responsibility drives learning in teams and organizations to make up for someone who’s missing; or if the market changes radically and we just don’t have anyone with the skills that we need on the team, my sense of collective responsibility will motivate me either to learn how to contribute in a way that’s needed or I will be motivated to help the team find someone to hire into the team to make that work. That fourth thing really helps stabilize agility in a team or an organization.

One of the things that we find, however, is that these four things are not common in large organizations. For example, in large companies it’s uncommon for us to have a sense of collective responsibility for the things we produce. We have a role, a job description, and we follow the roles in the job description; we think that we’ve done what we needed to do. The rest of an organization can be hostile to agile practices: policies and procedures about compensation and performance evaluation can inhibit collective responsibility. Even if you have a whole team full of people who feel collectively responsible, those team members become kind of vulnerable in the hostile organization. What can happen is, if you have a blame culture in the organization, and then you have good people who take responsibility for a problem and start fixing it, others may feel resentful that you’re doing the job they’re assigned to do. “Well, I could’ve done this, and I’m going to do that in future, why are you doing my job?” The responsible parties are those fixing the problem fast, and they’re can be vulnerable to getting fired, unfortunately. It’s very sad. And, of course, it destroys a major source of value for the organization.

In order to create an expansive agility, one that, in a sense, defends itself by bringing other people into the tent, we have a fifth pattern called solving problems systemically. There’s a whole collection of things under this pattern. Many people who are listening to this may be familiar with Theory of Constraints, which is a technique that people use in supply chains to identify the most constrained resource and focus the attention of available resources on fixing that constraint. That is a systemic problem-solving tool.

There’s another tool from Toyota called Five Whys, where we try to identify the cause of a problem and instead of just accepting the first superficial answer to the question “Why did this problem happen?” we actually dig very deeply into the causes of that, and we do that through a technique called Five Whys.

The Agile Base Patterns incorporate virtually all agile practices, from Toyota Production System to Lean Manufacturing, even to a personal time-management technique called Getting Things Done. You can fit its practices into these particular patterns.

The nice thing about these patterns is, I can go to any company now and assess their agility. I can assess it at any level of the company. I can start asking questions. Do you measure economic progress? What are the metrics you use? How do those line up with the overall organization’s economy? Do you experiment? I just ask if you’re doing them and ask for the nuances of how you do them. Through these questions, you can discover what opportunities the organization has to improve, because when you improve any of these, you improve the agility of the company.

There you have it. As much as I can compress it, I’ve given you an overview of agility.

Dustin: Thanks for sharing today. Do you have any final recommendations for supply chain executives or professionals?

Dan: Supply chains, of course, involve everything from a manufacturer, all the way through to delivery to a store and, ultimately, a customer. That chain is a long dependency chain. Of course, Toyota Production System has something to say about that with just-in-time manufacturing and limiting inventory. When we look at organizations like that, when we look at systems like that, we’re looking for how long things take to get from the manufacturer to the customer, even from the point of the raw materials to the customer. Economic progress for a supply chain can take us up a level, in a sense. If we’re really trying to provide the best value possible to the customer, and if we’re some element of this supply chain, when we solve systemic problems, that last pattern on our list of Agile Base Patterns, we actually stop thinking just about our little piece of the supply chain, but about the overall supply chain and how we might be able to improve that delivery rate.

We see sometimes—Amazon does this and Overstock.com does this—that companies have internal agile supply chain systems they built for themselves to deliver fast. Amazon wanted to deliver books to customers, so it has all these distribution centers with warehouses and that sort of thing. Then they started saying, “The agile supply chain solutions that we provide for ourselves are things we can provide to customers as well,” and they started making those agile supply chain facilities available to others. Individuals who have extra books can actually ship them to Amazon, Amazon will do all the warehousing for them, and then, as people want to buy those books, Amazon is able to fulfill them from the distribution center, but they’re actually used books that were contributed by the tiniest supplier to Amazon, just an individual with a bunch of books.

Those kinds of innovations are really great, actually, and they create a better flow for all sorts of valuable commodities, in this case. Traditional supply chain looks at problems systemically; that’s really awesome. Collective responsibility is also important, and you see this in agile ecosystems like Amazon and Overstock and others. Overstock, for example, looks at people who manufacture things, mom-and-pop manufacturers, and they want to provide a capability to these people to more rapidly ship things to customers so that the customers feel more satisfied. They created this system—I think they call it SOFS—where they integrate inventory control information with both the manufacturer and the warehouse all the way to the customer, and they can predict for the customer how long it will take to deliver that thing through the entire system. That’s very handy and that was a really nice example of collective responsibility, where Overstock said one of the problems for the manufacturers is getting this stuff to customers rapidly and also telling them when these things might be delivered. They took that responsibility on themselves to help with that.

Fast, just-in-time supply chains, of course, limit work in process. Experimentation for improvement, that does happen and it could happen more if you instrument your supply chain so you know where things are all the time and you aggregate all that data together into business intelligence reports. Then, of course, all supply chains measure economic progress in relationship to the time things spend in the system.

I actually think supply chain is a really good example of a field that could benefit from agility. We’ve certainly seen that some supply chains are not agile, actually. They have big warehouses; they don’t really have good order systems that make it easy for shipping to happen fast, and that’s a problem. I think that companies that don’t fix their supply chain to being more agile are going to be roadkill in the future. You have big companies that are taking this very, very seriously, and either a slower supply chain’s business will be disrupted by a company like Amazon that suddenly decides to go into their market or they’ll be disrupted by competitors who build agile supply chains.

That’s what I got.

Dustin: Great, thanks again for sharing today.

Dan: Sure.

Senex Rex tackles challenging problems at the agile management frontier. We help companies, teams and leaders accelerate and sustain value and quality production, so we can all live better lives. We can coach and train you and your organization for the win. Contact us.