Senex Rex
  • Team
  • Blog
  • Resources
  • Contact

Agile Supply Chains Take the Lead

Posted on June 9, 2015 by Dan Greening Posted in Advocacy 7 Comments

Make Your Supply Chain Agile, or (zoom) Roadkill

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.

Agile Base Patterns

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.

Share this:

  • Click to print (Opens in new window)
  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Reddit (Opens in new window)
  • Click to email a link to a friend (Opens in new window)
  • More
  • Click to share on Tumblr (Opens in new window)
  • Click to share on Pinterest (Opens in new window)
  • Click to share on Pocket (Opens in new window)
« Agile Cancer: Stop Whining and Cure It
Experiment to improve »

7 thoughts on “Agile Supply Chains Take the Lead”

  1. Ramesh Chandran says:
    July 29, 2015 at 12:29 pm

    Couldn’t agree more. In my previous Company, we observed we weren’t overcoming unforeseen delays in a project as well as we wanted. That’s when the Head of Vertical and I decided that pooling of resources and working on changing mindsets thereon without disturbing the Organisation structure was the way forward – in short ‘become agile’. It not only helped getting over delays, we accelerated the project and were ready for every surprise. The crowning glory was bonding and team building was stupendous.

    It is axiomatic that, if we don’t think and work agile we would get into a quagmire. In supply chain it obviously would yield copious benefits. In a larger perspective it implies expanding on the concept ‘get out of mindsets, do out of the box thinking and understand the essence of all processes in addition to comprehending the metrics ‘per se’.

    Log in to Reply
  2. Vince McGevna says:
    July 30, 2015 at 11:29 am

    Excellent general overview of what I, with 40+ yrs in engineering product development, would call a proactive organization: nos. 1 and 3 are the essence of being proactive with 2 and 5 being necessary to deal with the real world. And, in product development, nos. 3 and 4 are strongly interrelated.

    In a proactive product development organization, WIP is limited by having a roadmap and accompanying funnel process first identify and then to start on the most important projects when the resources become available. Agreement on the roadmap constitutes agreement on resource assignments that eliminates a lot of unnecessary people shuffling. When an organization does not limit the work to what is doable with the resources available, then people constantly get shuffled around.

    Success requires understanding the five characteristics, understanding your organization, and applying the characteristics appropriately. What works in one organization might not work in another.

    Log in to Reply
  3. Derek Smyth says:
    July 30, 2015 at 11:31 am

    Thank you very much Dan for posting this.

    Log in to Reply
  4. Tushar Jain says:
    July 30, 2015 at 11:38 am

    Thanks Dan for such a good article.

    Log in to Reply
  5. Ian Jones says:
    July 30, 2015 at 12:15 pm

    The value of this context, for me, is that it takes the role of agile in enterprise transformation out of the abstract, philosophical realm, into a specific systems area where benefits are measured and tracked.

    I will study it carefully, then talk to you some more.

    Log in to Reply
    • Dan Greening says:
      July 30, 2015 at 12:16 pm

      I’m finding a lot of enjoyment taking these agile patterns and demonstrating how they apply directly to non-software situations. Try it sometime!

      Log in to Reply
  6. Pierre E. NEIS says:
    July 30, 2015 at 12:17 pm

    Great post. Thanks for sharing.

    Log in to Reply

Leave a comment Cancel reply

You must be logged in to post a comment.

Continue with Facebook
Continue with LinkedIn

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Pages

  • 5 Points
  • Account
  • Agile Capitalization
  • Agile Capitalization Video: Greening and Rudd
  • Agile Training
  • Agility Language
  • Call for Papers: Agile/Lean at HICSS (Kauai, January 5-8, 2016)
  • Call for Papers: Agile/Lean at HICSS
    (due June 15, 2016)
  • Certified Enterprise Coaching
  • Clients
  • Contact Us
  • Courses: Agile Capitalization Workshop
  • Courses: Agile Development
  • Courses: Agile Product Management
  • Courses: Executive Introduction to Agile
  • Courses: Scrum@Scale Practitioner
  • Dan R. Greening
  • Enterprise Scrum: Scaling Scrum to the Executive Level
  • Glossary
  • Home
  • Jeff McKenna
  • John Horton
  • Kay Lynn Gabaldon
  • Login
  • Logout
  • Members
  • Password Reset
  • Premium Content
  • Premium Content 2
  • Privacy Policy
  • Register
  • Release Duration and Enterprise Agility
  • Resources
  • Rob Myers
  • Senex Rex Team
  • Short Course: Agile Manager
  • Sign up for Premium Content
  • Software Moneyball
  • Subscribe
  • The First of Five Challenges to Large Organizations that Force Agility
  • Troy Magennis
  • User
  • Vincent T. Mills
  • Senex Rex Blog Posts
  • Rapid Agile Forecasting

Archives

  • August 2018
  • February 2018
  • February 2017
  • March 2016
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • February 2015
  • August 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • April 2012
  • March 2012
  • December 2011
  • July 2011
  • March 2011
  • February 2011
  • September 2010
  • August 2010
  • May 2010
  • April 2010
  • March 2010
  • January 2010
  • May 2009
  • March 2009

Categories

  • Advocacy (11)
  • Agility (10)
    • Agile Base Patterns (7)
  • Calls for Papers (4)
  • Enterprise (23)
  • Events (5)
  • Job Search (1)
  • Marketing (2)
  • Metrics (12)
  • Personal (7)
  • Personal Improvement (2)
  • Portfolio Management (11)
  • Product Management (9)
  • Quality (6)
  • Scrum (31)
  • Software (4)
  • Training (2)
  • Uncategorized (5)

WordPress

  • Log in
  • WordPress

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Pages

  • 5 Points
  • Account
  • Agile Capitalization
  • Agile Capitalization Video: Greening and Rudd
  • Agile Training
  • Agility Language
  • Call for Papers: Agile/Lean at HICSS (Kauai, January 5-8, 2016)
  • Call for Papers: Agile/Lean at HICSS
    (due June 15, 2016)
  • Certified Enterprise Coaching
  • Clients
  • Contact Us
  • Courses: Agile Capitalization Workshop
  • Courses: Agile Development
  • Courses: Agile Product Management
  • Courses: Executive Introduction to Agile
  • Courses: Scrum@Scale Practitioner
  • Dan R. Greening
  • Enterprise Scrum: Scaling Scrum to the Executive Level
  • Glossary
  • Home
  • Jeff McKenna
  • John Horton
  • Kay Lynn Gabaldon
  • Login
  • Logout
  • Members
  • Password Reset
  • Premium Content
  • Premium Content 2
  • Privacy Policy
  • Register
  • Release Duration and Enterprise Agility
  • Resources
  • Rob Myers
  • Senex Rex Team
  • Short Course: Agile Manager
  • Sign up for Premium Content
  • Software Moneyball
  • Subscribe
  • The First of Five Challenges to Large Organizations that Force Agility
  • Troy Magennis
  • User
  • Vincent T. Mills
  • Senex Rex Blog Posts
  • Rapid Agile Forecasting

Archives

  • August 2018
  • February 2018
  • February 2017
  • March 2016
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • February 2015
  • August 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • April 2012
  • March 2012
  • December 2011
  • July 2011
  • March 2011
  • February 2011
  • September 2010
  • August 2010
  • May 2010
  • April 2010
  • March 2010
  • January 2010
  • May 2009
  • March 2009

Categories

  • Advocacy (11)
  • Agility (10)
    • Agile Base Patterns (7)
  • Calls for Papers (4)
  • Enterprise (23)
  • Events (5)
  • Job Search (1)
  • Marketing (2)
  • Metrics (12)
  • Personal (7)
  • Personal Improvement (2)
  • Portfolio Management (11)
  • Product Management (9)
  • Quality (6)
  • Scrum (31)
  • Software (4)
  • Training (2)
  • Uncategorized (5)

WordPress

  • Log in
  • WordPress
Copyright ©2013-2015 Senex Rex LLC. All Rights Reserved.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Do not sell my personal information.
Cookie SettingsAccept
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
CookieDurationDescription
cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytics
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Others
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
SAVE & ACCEPT