You've taught your teams to inspect and adapt. Every two weeks, you're looking at what's going right or wrong. Your sprints are humming along, your retrospectives are generating real improvements. So why does it still take six months to get materials from suppliers? Why can't the rest of your organization learn to produce their work as fast as your development teams?
Here's the brutal truth: your Scrum teams are really only as agile as the slowest learning loop in the entire value stream. And right now, that loop is probably your supply chain.
Hi, I'm Lance Dacy, otherwise known as Big Agile. Today we're going to walk through how companies like Schneider Electric and P&G are teaching their supply chains to learn at the speed of Scrum—not necessarily by copying the ceremonies, but by understanding the system principles that make agile work just about anywhere, regardless of the type of work.
What We'll Cover
We're going to explore three key areas where organizations struggle:
- Why supply chains need learning systems even more than software teams do
- How to map constraints as learning opportunities, not just problems to solve
- Real companies that have redesigned their supply chain networks using agile principles, and the numbers that proved it worked
Why Supply Chains Can't Just "Go Agile"
Let's address the elephant in the room. If you're a Scrum Master or agile coach, you've probably thought: if Scrum works for software, why doesn't supply chain, finance, or IT infrastructure just adopt it? I hear this all the time, so let's level set on why it's harder than it looks.
The Tooling Reality
Software teams can deploy daily, hourly, even by the minute in some cases. Supply chain decisions have six to twelve week lead times. You can't just pivot when materials are already on a ship from China. Software used to have those problems, but our tools make it easier and easier to deploy if we build processes around that. I can't get a ship from China to the USA with any better technology than what we have yet.
The Commitment Problem
Product development teams can change direction with a backlog refinement session. The code is fully expendable. Supply chain—and many other parts of the organization—have binding contracts, capital investments, and commitments that can't be unwound without significant cost.
Yes, software has contracts, capital investment, and commitment too. But we can usually pivot and change direction more easily without significant costs. There's cost to the waste, but it's not the hard costs you have in supply chain.
The Ripple Effect
Software bugs can get fixed in the next sprint. Supply chain bugs or mistakes ripple through the whole system for quarters. When you order the wrong components, you're stuck with them. You've got the refund and replacement process to deal with.
I'm not just picking on supply chain, by the way. Many parts of the organization face similar challenges. I love supply chain. I worked at FedEx Express for ten years. I got a signed hat from Frederick W. Smith in October 1997 when we opened the third largest air hub in Fort Worth. I really bleed purple and orange. FedEx taught me a lot about how to be efficient amidst chaos—some things you can plan for, some things you can't. So I do have insight into these logistical constraints.
What Supply Chain Leaders Hear vs. What You Mean
When supply chain leaders hear "let's go agile," here's the translation problem:
They hear: "Throw away your forecasts and just react"
You mean: Shorten your planning cycles to match your learning cycles
They hear: "Stop optimizing for costs"
You mean: Optimize for throughput through the constraint, not local efficiency
They hear: "Embrace chaos"
You mean: Build feedback loops that let you sense and respond faster than the market shifts
We've learned how to do this in product development. But here's the key insight: supply chains need learning systems even more than software does because the feedback loops are longer. The cost of learning slowly is catastrophic—not quick. It's even more of an argument for why we need to go this route.
The 2020 Wake-Up Call
Think about what happened in the early 2020s. Global ports around the world stalled. Raw materials sat idle on ships and abroad. Organizations with lean, efficient supply chains actually collapsed because they had optimized for cost and removed all their slack from the system. They thought that's what efficiency was.
They really didn't have learning loops—no sensors and no ability to adapt. They'd streamlined all of that because that's what we learned in business school. We're trained to find the single right plan, then execute it and optimize for inefficiencies. But as we learn through these problems, we understand them better.
The companies that survived didn't have better forecasts. They had shorter feedback loops. They were able to adapt and learn amidst all the uncertainty.
From Linear Chains to Learning Loops
A traditional supply chain looks like a Gantt chart: annual contracts, quarterly payments, procurement, shipping, validation—all structured in a linear process. But what we're trying to do with agile is create a circular network with learning systems rolling, planning weekly, running retrospectives, and maintaining daily visibility.
We're shifting from a traditional waterfall mindset to more of a learning loop—sometimes people think of it like a rollercoaster, constantly moving and adapting.
Constraints as Teachers
In your retrospectives, you identify an impediment. You don't just try to remove it—you ask what this impediment is teaching us about the system. Another critical question: is this the biggest problem to solve? Does this have the biggest bang for the buck?
In agile, we're typically looking for the highest value delivery item with the least amount of cost. When you're making improvements in a complex adaptive system, you have to be really picky about the changes you make because you might change something small somewhere and it affects something you didn't even think about.
The same principle applies to supply chain constraints. I'm a big fan of Donald Reinertsen and his book on the principles of product development flow. He says the goal really isn't efficiency—that's the byproduct. The goal is learning under uncertainty.
The Theory of Constraints Perspective
Every constraint in a supply network is a teacher. The question isn't "how do we eliminate this constraint?" It's "what is this constraint trying to teach us about the overall system?"
Eli Goldratt would say every system has one point that governs its throughput. Once you find that, you design your learning loops around that single throughput point. In agile product development, we call this inspect and adapt. In supply networks, it's more like sense and respond—same principle, different context.
Real-World Example: Schneider Electric
Schneider Electric faced semiconductor shortages. They didn't just try to find more chips. They asked: what is this constraint teaching us about our own system?
The constraint taught them their planning cycles were too slow. They were running quarterly reviews while the market shifted every week. So they changed their learning cadence to match that, building what they called a "control tower model"—almost like an airport control tower.
Here's what matters: it wasn't the technology, it was the ceremonies. The ceremonies or events are instituted for a specific reason.
What They Changed
- Weekly flow retrospectives instead of quarterly reviews
- Each site uses process behavior charts to detect abnormal variations before they become crises
- Cross-functional teams (think scrum of scrums) decide daily reallocation of constrained parts
- Feedback loops at every stage between teams and at the seams of teams
The Results
They achieved 91% customer order fulfillment during shortages while their competitors in the same industry were well below 70%.
Their secret wasn't market resilience. It was response speed built through shorter learning cycles. Notice what they did: they basically took agile principles—sprint reviews, retrospectives, daily scrums—and applied them to the constraint. They didn't copy the ceremonies or call it Scrum necessarily. They understood the system principle: shorten the distance between action and learning.
Feedback Loops: The Nervous System of Agility
Think of your supply chain as an organism, not a machine. It has sensors (your inventory data), muscles (your logistics), and a brain (your decision-making models). But without a nervous system—without feedback loops—it can't learn.
I'm not afraid of metrics. I'm afraid of how metrics are used. If we're using metrics for learning and not just performance measurement, they can really help us.
Process Behavior Charts
Metrics and process behavior charts create the conditions for continuous learning. They help desensitize us to the normal ebb and flow of business and help us answer: is there a real change in the system or not? You can't fix what you can't talk about, and you can only measure after it breaks if you're tracking lagging indicators.
Amazon does a great job of this. They can sense when something's amiss in their whole network just by looking at metrics every day. When you introduce real-time feedback loops—demand signals, lead time variability charts, throughput trends—you move from forecasting to adapting. You stop chasing lagging metrics and start navigating reality.
Three More Companies That Built Learning Systems
Flex: Digital Twin Experiments
Flex built a digital twin of its global network—every supplier, plant, and logistics lane feeding live data into a shared model. But here's what matters: they run two-week sprints focused on throughput experiments, not KPIs.
Local plants test small changes in small batch sizes to allow for adjustments and supplier alternates. Successful patterns get scaled system-wide.
Result: 43% reduction in lead time variance within a year.
P&G: Teaching Suppliers to Sprint
P&G did something even more radical—they retrained their suppliers to work in agile cycles through "collaborative planning sprints."
- Sprint planning: What's the one constraint we can improve this sprint?
- Daily scrums: What's blocking flow today?
- Sprint reviews: Did we actually improve throughput?
- Retrospectives: What did we learn about this constraint?
They took suppliers who had never heard of agile before and taught them how to work in sprints—not because it's trendy, but because the alternative was quarterly planning cycles while experiencing demand shifts every week.
Picture two teams on either side of a whiteboard sharing a sprint goal: throughput improvement.
Result: 32% reduction in order-to-delivery lead time in just six months. Not because they optimized their supply chain, but because they taught their supply chain to learn.
Mars: Measuring Flow, Not Activity
Mars stopped measuring activities and started measuring flow. Many agile teams are still trying to do this in software.
It's not how busy the people are or how busy the port is—it's how fast value moves through the system. Not cost per container, but cash-to-cash cycle time. Radically different metrics than what we learned as leaders and managers.
Their metrics:
- Not utilization, but throughput dollars per constraint hour
- Cash-to-cash cycle time instead of traditional cost measures
This sounds familiar because throughput accounting is another way to look at what agile metrics are solving: how do you measure a system's health when the goal is learning and flow, not resource utilization or efficiency?
The Pattern That Connects Everything
Notice what all these companies share: they didn't start by redesigning their entire supply network. They started by redesigning how fast they could learn, using agile events and ceremonies—the principles.
Five Key Patterns
1. Cadence Before Technology
Learning rhythm matters more than dashboards. Schneider Electric's weekly retrospectives beat any AI forecasting tools. Any company can have those tools—how you'll be hyper-competitive is learning.
2. Cross-Boundary Retrospectives
Reflection includes suppliers, partners, and internal teams. P&G brought suppliers into sprint planning with shared goals.
3. Economic Flow Metrics
Measure throughput and learning speed, not just cost. Mars focused on cash-to-cash cycle time.
4. Empowered Local Teams
Decentralize decision-making but centralize visibility. Flex let local plants experiment within boundaries—self-organizing and autonomous.
5. Intentional Slack
They didn't get there by restructuring their supply chain. They changed their relationship with learning.
The Patagonia Example: Slack as Insurance
Patagonia built resilience through intentional slack:
- Dual suppliers per critical material
- Transparent shared platforms
- Ongoing kaizen weeks with cross-supplier teams
Finance teams often hate this. They see slack as waste. But slack isn't waste—it's optionality.
When Patagonia's dual suppliers gave them flexibility during disruptions, their competitors faced stockouts and lost customers. Patagonia kept thriving.
The math:
- Cost of slack: 5% higher supplier costs
- Cost of stockouts for competitors: 30-40% revenue loss during disruptions
That's not waste, that's insurance that pays for itself. Nobody likes to pay insurance, but when we need it, we're glad we have it.
This is where the theory of constraints meets agile thinking: you don't optimize every part of the system. You optimize throughput through the constraint. Sometimes that means intentionally building in slack everywhere except the constraint.
What This Means for You
You're a Scrum Master, agile coach, or product person trying to deliver value faster, but you keep hitting a wall. Supply chain can't keep up, finance can't keep up. Materials arrive late. Procurement cycles take months. Your sprint reviews show working software, but customers can't get the physical product or access.
Here's what you need to understand: your Scrum teams are only as agile as the slowest learning loop in the value system. And that loop probably spans functions you or your teams don't control.
You can't make your sprints faster if finance still runs annual budget cycles. You can't deliver value continuously if operations still batch deployments quarterly. You can't adapt to changing customer needs if your supply chain plans in twelve-month horizons.
Enterprise agility isn't about scaling Scrum. It's about redesigning the learning loops across your entire value stream. That's something rarely anybody is talking about.
Five Actions You Can Take
1. Start with Visibility
In your next sprint review, invite someone from supply chain or procurement—wherever you're experiencing issues. Show them what you're learning every few weeks. Ask them how long their learning cycles are. You're creating awareness and desensitizing them to your approach.
2. Map the Constraint
Where does value sit waiting in your system? Is it procurement approvals? Material lead times? Deployment windows? Use your retrospectives to identify constraints outside your team's control. Your Scrum Masters or agile coaches can work to facilitate their removal.
3. Propose an Experiment
Don't try to change the whole system. Pick one constraint. Propose one small experiment: "What if we ran a weekly checkpoint instead of a monthly review?" Just for this one supplier or this one sprint. Experimenting is a critical part of agile work.
4. Teach the Language
When you talk to supply chain, don't say "go agile"—that doesn't mean anything to them. Say "let's shorten the feedback loop" or "let's deliver high value as early as possible with the least amount of cost." Don't say "embrace uncertainty"—say "let's build sensors that detect problems earlier."
It's hard to argue against that way of working. Replace the jargon with their language.
5. Measure Flow, Not Activity
Help other functions see that utilization isn't the goal—throughput is. A busy system with massive queues is a slow system. An idle system with fast flow is a valuable system.
The Fundamental Truth
You can't create an agile organization simply by transforming development teams and hoping other functions follow. You have to help those functions redesign their own learning systems, using language that helps them do that.
It all starts with understanding their constraints, not just yours. Speak their language. Show them that the principles that make Scrum and agile work—short cycles, fast feedback, and empirical process control—can work everywhere.
Gerald Weinberg said in "An Introduction to General Systems Thinking" that significant problems cannot be solved at the same level of thinking that created them. Linear optimization can't solve complex network problems.
The companies that survived the past decades of chaos—9/11, the 2008 financial crisis, the 2020 pandemic, semiconductor shortages, port disruptions—they didn't have the best forecasts. They had the shortest feedback loops.
Stop Optimizing, Start Learning
My challenge as an agile consultant and coach: stop thinking "supply chain optimization." Start thinking "supply network learning."
When your system can see itself—when data, teams, and feedback loops are connected—it can anticipate disruption long before it hits, or at least as it's hitting, not just reactively. When it can adapt faster than the market shifts, your resilience becomes your competitive advantage.
Don't ask "how efficient is our supply chain?" Ask "how fast can our supply chain learn?"
Speed of learning is much better than efficiency of execution.
Your Challenge This Week
Find one person in your organization who touches supply chain, procurement, finance, or operations. Ask them this question:
"How long is the feedback loop between when you make a decision and when you know that decision worked?"
Then ask: "What would you have to change for that loop to be half as long?"
You're not trying to fix their supply chain. You're trying to introduce the concept of learning cycles. That's how transformation starts—not with an initiative, a kickoff, and a project. It starts with conversations at the ground level and a feedback loop.
You can't make your system smarter by adding more rules. You make it smarter by shortening the distance between action and learning.
Ready to transform how your entire organization learns?Explore the classes that Big Agile offers to help leaders create organizations where agility is the operating system, not just what your developers do. Change is hard, but you don't have to do it alone.