Procurement is not usually where you look for evidence of dramatic cycle-time reduction. Which is what makes the agile sourcing case record unusual: the published numbers are genuinely strong, they are attributable, and they have been sitting in the open for years without much of the market acting on them.
They also come with a boundary condition that gets left out of most retellings, and that boundary is the more useful half of the story.
What agile sourcing is
Agile sourcing applies sprint-based, cross-functional working to procurement cycles that would traditionally run for months. Rather than a sequential process of requirements, then RFI, then RFP, then evaluation, then negotiation, each with its own waiting period, the buying organisation and shortlisted suppliers work in the same room, or the same call, against a defined problem.
The compression does not come from cutting steps or lowering rigour. It comes from removing the queue time between them, and from making the trade-off conversations happen with all the decision-makers present rather than being relayed through a procurement function acting as a message bus.
The published record
- Organisations following the Lean-Agile Procurement model have reached a signed ERP contract in as little as four weeks.
- A public-sector award, competitively bid, in forty-five days.
- One documented case took a 9% savings target and delivered 15%.
The evidence base spans the Agile Business Consortium’s Swiss Casinos Group and Air France KLM Martinair Cargo case studies, the LAP Alliance’s published Zalando case, a CMS Medicare payment-systems modernisation, AGCO’s pandemic-era supply chain response, and CIPS’s own guidance on agile and crisis-ready procurement.
The third figure is the one worth pausing on. Compressed timelines are usually assumed to cost you commercially: less time to negotiate, less leverage, a worse price. That case shows the opposite, and the mechanism is not mysterious: when suppliers are in the room solving the actual problem rather than responding to a specification written six months earlier, they propose things the specification would have precluded.
Speed, in this model, is a by-product of a better conversation. It is not the objective, and treating it as the objective is how the method gets misapplied.
Where it does not fit
This is the part that matters more than the case studies, and the part most enthusiastic write-ups skip.
Agile sourcing is not the right tool for every category. Choosing correctly is as much a part of the method as running the sprint.
Highly regulated procurement. Where the process itself is the control, as in some public procurement regimes, regulated financial services and defence, the sequence and its documentation are not overhead to be compressed. They are the point. You can bring agile disciplines to the preparation, but the award mechanism stays conventional, and the forty-five-day public-sector case was possible because the regime permitted it, not because the regime was worked around.
Genuinely complex technical integration. Where the requirement cannot be adequately understood in a sprint’s timeframe, compressing the cycle compresses the discovery, and you sign confidently against the wrong specification. Fast.
Low-value, high-volume categories. A sourcing sprint occupies senior people from several functions for a concentrated period. That is an expensive instrument. Pointed at a category where the total addressable saving is small, it loses money on the process cost alone, however well it runs.
Single-supplier renewals with no real market. If there is no credible alternative, there is no competitive dynamic for the sprint to exploit. What you need there is negotiation leverage and a genuine walk-away position, which is a different discipline entirely.
The honest summary is that agile sourcing suits categories that are commercially material, competitively contested, and definable inside a few weeks. That is a real and substantial slice of most organisations’ spend. It is not all of it, and a procurement function that runs everything as a sprint will produce worse outcomes than one that never heard of the method.
What it demands from the buying side
One further caveat, because the case studies tend to under-report it.
Agile sourcing transfers effort forward and concentrates it. It requires decision-makers rather than delegates, available for the duration, a problem statement that has already been agreed internally, and a governance structure willing to approve inside the sprint rather than at a monthly board two weeks later.
Organisations that cannot commit that tend to run a sprint that stalls at the decision gate, which produces the worst of both worlds: the intensity of the compressed process, followed by the delay of the conventional one.
Whether that commitment is available is a question about the operating model, not about procurement. Which is usually the real reason the method has not been adopted more widely, and it is worth diagnosing honestly before running the first sprint rather than after.