What every Agile team can learn from Europe’s fastest learners
I’m always curious and wanted to know why some companies keep learning while others slow down?
So I went looking. Not in theory, but in practice.
Talks... Engineering blogs... Case write-ups. Even annual letters.
I followed the trail of teams that use data to get better, not just look busy.
Five names kept returning: ING, Spotify, Booking.com, bol.com, About You. Different industries, same pattern. They didn’t start with dashboards. They started with a reason to change. They built habits around experiments.
They used data as a conversation, not a command. And over time, that changed their culture (and their results).
Below are five short research stories in one shape:
Why they changed. What they changed. What got in the way. What it delivered. What we can copy.
I wrote them like field notes. No theatre. Just what matters.
You can use this as a map of inspiration. Then draw your own map.

1. ING — From control to learning
Why they changed
Mobile-first banking shifted expectations. bunq, N26 and Revolut moved faster than banks were used to.
ING had trust and reach, but not rhythm. Projects inched through approvals while customers sped ahead.
What they changed
In 2015, ING reorganised around product outcomes. Squads, tribes, and chapters.
Smaller releases. Feature flags. Real users in the loop before a big rollout.
What got in the way
This proces had pains! Old habits resisted. Stand-ups slid into status. Retros without any reflection.
Autonomy arrived before clarity. Leaders still asked for reports instead of lessons.
What it delivered
Shorter time-to-market. Higher engagement. Tighter feedback loops across journeys and countries.
Speed with consistency inside regulation.
What we can copy
✅ Tie every release to a one-line hypothesis.
✅ Put leaders in retros and ask, “What did we learn?”
✅ Make experiments small and safe so they happen often.
✅ Reward honesty over certainty.
2. Spotify — Learning as the real product
Why they changed
Their agile model wasn't designed for the long run. Hypergrowth created fragmentation. Hundreds of squads shipped fast. Alignment frayed. Speed without shared insight is motion, not progress.
What they changed
They pushed hypothesis-driven work into the inner loop.
Experiments were part of rollouts and platform tooling.
Alongside delivery speed, they tracked learning velocity. how quickly a squad forms a belief, tests it with users, and adjusts.
What got in the way
Overlapping tests. Peeking too early. Treating experiments as optional.
They tightened design, added guardrails, and made the learning story visible, not just the win.
What it delivered
Failure became normal and useful.
Hundreds of experiments each month. Most fail quietly. Some shape the product for millions.
The real win... A product rhythm that adapts faster than competitors can copy.
What we can copy
✅ Measure the rhythm of learning, not only the rate of delivery.
✅ Treat rollouts as experiments with guardrails.
✅ Share learning stories in demos, not just release notes.
✅ Build safety before autonomy so curiosity can breathe.
3. Booking.com — Making it cheap to be wrong
Why they changed
At their scale, guesses are expensive. A tiny conversion shift moves millions.
They needed confidence they could explain, not charisma they could sell.
What they changed
They built a company-wide experimentation platform.
Every change is testable. Hypothesis first. Stop rule defined upfront.
Success is reusable learning, not a single green arrow.
What got in the way
When tests become easy, they multiply. Noise. Overlap. Wins without a story.
Leadership added learning metrics. Each test must state the knowledge it will create.
What it delivered
Tens of thousands of controlled experiments each year.
Faster decisions. Fewer taste debates. Higher reliability.
A shared language across design, engineering and data science.
What we can copy
✅ Write the decision rule and stop rule before you start.
✅ Track learning you can reuse, not just lifts.
✅ Publish failed tests so others don’t repeat them.
✅ Treat “less wrong” as real progress.
4. bol.com — Doubt as a system
Why they changed
Growth brought noise. Projects multiplied. Opinions too.
The loudest voice often won. Teams shipped a lot while learning little.
What they changed
They made doubt a ritual. Before decisions, ask: How do we know this is true?
PowerPoint gave way to prototypes.
Limit live experiments and add clear kill conditions.
What got in the way
Experiments lingered without stop rules. Energy scattered.
They capped work in progress, closed tests that didn’t teach, and shared the lesson.
What it delivered
Evidence-based decisions rose sharply. Lead times dropped. Fewer failed launches.
The bigger win curiosity felt safe again.
What we can copy
✅ Ask the doubt question in every refinement.
✅ Cap active experiments to restore focus.
✅ Celebrate a clean kill like a clean launch.
✅ Turn knowledge into a shared asset.
5. About You — Scaling a mindset, then selling it
Why they changed
The product grew fast. The engine began to groan.
Too much custom work. Too little repeatable speed.
What they changed
They productised their internal stack.
That became SCAYLE. A platform brands can use to move at About You’s pace.
Experimentation and data discipline turned from internal habit to external product.
What got in the way
Turning creative process into reliable product is hard.
Documentation, shared data models, quality at scale.
Teaching brands exposed their own blind spots (which they fixed).
What it delivered
SCAYLE powers a long list of brands and became a second growth engine.
About You sharpened its practice by exporting it.
What we can copy
✅ If your way of working creates value, package it.
✅ Teaching forces maturity.
✅ Feedback from platform customers improves your own teams.
✅ Share your system to sharpen your system.
Patterns I kept seeing
Purpose before process.
Experiments before dashboards.
Safety before speed.
Dialogue before decisions.
None of these companies are perfect.
They simply learn in public, and they keep going when it gets awkward.
That’s the part worth copying.
A simple frame to start today
I use The Experiment Triangle when teams want to move from measuring to learning.

Why
What do we want to learn, and what will we change if the answer hurts?
When
Are we calm and honest enough to look at this together?
What
What is the smallest test that teaches us the most?
If one side is missing, start there.
Small tests. Short loops. Real conversations.
Try this with your team
Pick one metric that feels safe but says little.
Bring it to your next retro and ask
👉 What should this number actually tell us?
👉 What would need to change for it to have meaning?
That’s enough for the first week.
One conversation. One habit of honesty.
Closing
Data doesn’t make teams better. People do...
Choose one honest question. Run one small test. Have one good conversation.
That’s how learning starts. That’s how teams grow.
