I interviewed Dan R Greening who discussed The Five Characteristics of all Sustainable Agile Methods.
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?
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.
What are the five characteristics of all sustainable, agile methods?
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 done 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 and tried 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 of the things we wanted to eventually talk about is how this might relate to supply chain since that’s a specialty of yours.
Here’s what agile practices all do. The first thing that you need to have an agile organization is that you need to have 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 adaptively 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 a situation quite yet if we just do the first two things to actually 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 progress. Limiting work in progress means that if we have a lot of inventory in our supply chain, that inventory is work in progress. 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 progress 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 and take that person away to work on some special project. When that happens, it can actually 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 property: 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 team, I agree that whatever this team produces, I will feel personally responsible for making sure that collective contribution works.’”
If I join a team and I know how to test software, for example, which I happen to know, and then the team also has developers on the team and 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 early 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 what I need to know to contribute in a way that’s needed or I will be motivated to help the team find someone to hire and bring 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. It’s not common to have a sense of collective responsibility for the things that 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. Even if you have an organization that doesn’t have a sense of collective responsibility and then you have a team full of people who feel that way, those team members become kind of vulnerable. What can happen is, if you have the blame culture in the organization and then you have a bunch of people volunteering that they will take responsibility for a problem and they start fixing it, they say, “Well, I could’ve done this, and I’m going to do that in future,” and then they start doing it, they’re very vulnerable to getting fired, unfortunately. It’s very sad.
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 these things. 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. You can take any agile practice, 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.
Thanks for sharing today. Do you have any final recommendations for supply chain executives or professionals?
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 think systemically that bottom property on the list, we actually think not 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.
What we see sometimes—Amazon does this and Overstock.com does this—they have these internal systems that they built for themselves to deliver. 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 supply chain solutions that we provide for ourselves are things we can provide to customers as well,” and they started making those 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’s able to fulfill them from the distribution center, but they’re actually used books that were contributed by someone working with 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. Supply chain looks at problems systemically; that’s really awesome. Collective responsibility is also important, and you see this in 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 progress. 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 systems 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 our thing. I think that most supply chains that don’t fix their supply chain to being more agile are going to be roadkill in the future. Ultimately, you have these 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 supply chain market or they’ll be disrupted by their own competitors, who decided they’re going to be agile. That’s what I got.
Great, thanks again for sharing today.
Sure, I hope it was entertaining.
About Dan R Greening
Dan R Greening
Managing Director at Senex Rex