How a Belgian delivery company transformed with Scrum

When a Belgian postal and parcel delivery company decided to experiment with Scrum, they weren’t chasing buzzwords — they were searching for a way to break free from late deliveries, high technical debt, and a frustrating disconnect between business and IT. The product in question was Tracked Mail, a critical service supporting two major business units: Mail Operations and Key Accounts.

The journey wasn’t smooth. The first few Sprints left leadership wondering if they had made a mistake. But over 18 months, a combination of structural changes, deeper collaboration, and a strong stand on quality transformed Tracked Mail into one of the most trusted product teams in the organization.

This is how it happened — and what you can learn from it.

The initial setup split the Tracked Mail developers into two teams of roughly 11 people each, aligned with their respective business units.

• One Product Owner (from IT) coordinated priorities with both business leads.
  
  
• One Scrum Master (an Agile coach) supported both teams.
  
  

From a technical standpoint, this separation made sense: certain applications were exclusive to each unit. But the first two Sprints failed to deliver much. The change in workflow exposed deep-rooted problems that had been hidden in the old process.

Lesson: Early productivity dips are normal when adopting Scrum. They often reveal hidden issues that need to be addressed before real progress can happen.

One of the most impactful early moves was inviting key business stakeholders to the Sprint Retrospectives. At first, management doubted the value — but these sessions gave the business a raw, unfiltered look at the challenges developers were facing:

• High technical debt from years of quick fixes.
  
  
• Poor engineering practices due to lack of time and tools.
  
  
• Slow, rigid requirements gathering with late discovery of misunderstandings.
  
  
• Accountability without decision-making power for the teams.
  
  

Lesson: Direct, regular interaction between developers and business stakeholders builds empathy and shared ownership of problems.

To build momentum, the teams agreed to:

• Dedicate one Sprint to installing new tools for better engineering practices.
  
  
• Allocate 10% of every Sprint to continuous improvement.
  
  
• Assign Business Leads to work closely with developers during the Sprint.
  
  
• Involve enterprise architecture to simplify the application landscape.
  
  

By Sprint 5, delivery rates were steady. By Sprint 10, engineering practices, collaboration, and architectural clarity had improved significantly.

Lesson: Reserve time for technical excellence and collaboration — even when delivery pressure is high.

The 2008 financial crisis forced budget cuts, and inconsistent demand from the two business units caused delivery fluctuations. A workshop with developers and business leads revealed a deeper issue: the team was still split along departmental lines instead of focusing on the product as a whole.

The solution:

• One Product Backlog for Tracked Mail.
  
  
• Two guiding goals: maximize value and improve technical excellence.
  
  
• Four smaller, cross-functional teams to share knowledge and standards.
  
  
• One synchronized Sprint with shared planning, reviews, and retrospectives.
  
  

Lesson: Organizing around the product rather than business silos enables better prioritization and reduces waste.

As the economy recovered and new competitors emerged, the business wanted to accelerate. Some stakeholders suggested cutting quality to deliver faster — the same shortcut that had caused problems before.

This time, the team resisted. They used their track record to argue for better prioritization instead of cutting corners. The key structural change was appointing one true Product Owner with final say on priorities and return on investment.

Lesson: High performance gives teams the credibility to defend quality. One empowered Product Owner helps resolve conflicts between competing business demands.

Even though the wider organization still followed traditional handovers between business and IT, Tracked Mail had developed its own Agile culture bubble — daily collaboration, shared goals, and a common Definition of Done. Their reputation improved so much that other teams wanted to collaborate with them.

Lesson: Teams can model Agile culture and influence the broader organization without waiting for a company-wide transformation.

1. Expect initial turbulence — early Sprints expose hidden issues.
   
   
2. Involve the business directly in retrospectives to build empathy.
   
   
3. Invest in engineering practices to enable sustainable delivery.
   
   
4. Organize around products, not departments, for better prioritization.
   
   
5. Defend quality during market and budget pressures.
   
   
6. Model Agile culture — success stories inspire change elsewhere.
   

The transformation of Tracked Mail was not about applying Scrum rituals mechanically. It was about using Scrum as a framework to surface problems, foster collaboration, and create a shared sense of purpose. The journey from two disconnected teams to one high-performing product team took resilience, tough conversations, and a refusal to repeat past mistakes.

In the end, Scrum was not the magic fix — it was the mirror that showed where the company needed to change, and the vehicle that helped them get there.