How a Digital Transformation Can Bankrupt Your Company

Lessons Learned From the Waternet Fiasco

Look at this picture of how Waternet, a water company for Amsterdam and the surrounding area, proudly presents its digital transformation journey to the outside world:

What’s not to like about these playful pictures with blue colors? It’s in Dutch, but don’t worry I’ll fill you in on the important parts:

• Waternet wanted to be the best public service provider by 2020.

• Waternet wanted to be customer-centric, improve every day, leveraging Lean, Agile, and Scrum to deliver better results.

The picture is brimming with ambition and aspiration, supported by enticing buzzwords like Lean, Agile and Scrum.

You’d think this organization would be on the road of success, right?

WRONG.

Do you know what happened instead of them becoming the best service provider for water?

A few years after the creation of this picture they went (technically) bankrupt.

Despite hiring many ‘brilliant’ consultancies and practitioners, their Agile transformation helped accelerate their demise. They currently busy deciding how to restructure the organization so can become profitable and better performing again.

How did they make a full 360 degree turn from these pretty and ambitious pictures of a digital transformation to going bankrupt?

Let’s dig in!

Digital Transformation Gone Wrong

I want to stress, it’s difficult to point fingers or assign blame on any single thing. The organization was struggling before their transformation started. But it’s still good to recap what went down to see what we can learn from their demise.

In 2015, Waternet started digital transformation journey. Inspired by tech companies like Amazon, they wanted their customers to be able to do everything online. They spent 25 million on this project, without any significant results to show for.

But the real big problems began in 2018, when they decided to rebuild their invoicing system for collecting taxes. In 2021 they started using the new system, while the old invoicing system was already phased out. Big fucking mistake.

Finishing this new invoicing system took more than 6 years. Waternet couldn’t send all invoices in 2022, 2023, 2024, because the new invoicing system didn’t work. As a result, they missed out on the collection of 653 million Euro.

Because Waternet was bleeding money without collecting taxes, they had to take out a loan to stay afloat. The interest on this loan without sufficient income coming in ultimately made them go belly up.

In January of 2024, they had sent 99% of all overdue invoices. Even after 6 years they weren’t completely done rebuilding the system. Some people received invoices 3 years later than the year the invoice should have actually been sent.

What can we learn from this big hot mess?

What Can We Learn From the Bankruptcy of Waternet

Remember the picture at the beginning of the article containing: ‘Lean’, ‘Agile’ and ‘Scrum’?

Something really important was missing from this picture: they were not doing Lean, Agile or Scrum at all, because they were doing SAFe (Scaled Agile Framework).

So that’s their first mistake: trying to adopt SAFe (Scaled Agile Framework).

Lesson #1: Watch Out When Organizations Use SAFe

Dysfunctional organizations like doing SAFe, and they believe it will fix their problems, but the problem with SAFe is that it can be anything you want it to be. It’s like a beautiful rug you can sweep all your existing problems under, and that’s precisely what happened at Waternet, and is still happening at many other Dutch government organizations that love working with SAFe.

When you try to solve a problem with SAFe. BOOM! Now you’ve suddenly got three problems you must take care of:

1. You didn’t fix your original problem.

2. You made it harder to fix your original problem, as you’ve added unnecessary complexity, which makes it harder to troubleshoot what’s going on.

3. You’ve introduced new problems by introducing SAFe.

Another good example is the Belastingdienst (Dutch Internal Revenue Service). They are using their own version of SAFe called SABel (SAFe Agile Belastingdienst). The Belastingdienst is an organization with many organizational problems that is highly criticized in the Dutch media.

As a telling example of their Agile inadequacy: The Dutch government wanted to introduce legislation for adjusting the VAT for vegetables and fruit, but that wasn’t possible because the legacy IT systems of the Belastingdienst couldn’t support this change.

I want to stress, I’m not making the case that SAFe causes these problems. The Belastingdienst likely have lots of legacy systems with crippling technical debt. But I’m making the case that highly dysfunctional organizations are more likely to adopt SAFe because it promises them to help fix these problems in ways they are able to comprehend, which is precisely why they will never fix their real problems. They stay stuck in the same bureaucratic paradigm that caused these problems in the first place.

When you’re stuck in a dysfunctional paradigm, SAFe is a poor choice. Since SAFe can be whatever you want it to be, all you end up with is a dysfunctional SAFe blanket on top that doesn’t fix any of the real problems you’re having. You’re still stuck in the same bureaucratic paradigm of control and coordinate, instead of moving towards empowered teams who are jointly adapting and collaborating.

But hey at least you can present pretty pictures and talk about being Agile like Waternet was doing.

And that’s why many companies do when they do SAFe: it looks pretty on powerpoint slides, executives are happy, and you don’t have to really fix your existing dysfunctions.

Just shove all of your work in a pretty release train, choo choo! and watch it go. That’s exactly what happened. When the new invoicing system was being launched, the executives were unaware of the impact it would have on their invoices until it was too late to do anything about it.

Lesson #2: Beware of Rebuilds

The second problem is that rebuilds are a terrible idea. In the words of Joel Spolky:

“When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don’t have shippable code. You might as well just close for business for the duration.

You are wasting an outlandish amount of money writing code that already exists.” - Joel Spolky, Things You Should Never Do Part I

This fits with my experience. Rebuilds from scratch are a terrible idea. I’ve been involved in six of them, and only one of them I would consider a success. The others were complete failures making companies lose anything in the realm of millions to tens of million Euros.

The Waternet debacle is an excellent example of rebuilds being a terrible idea. Rebuilds almost always take longer than expected, and in their case, it took more than 6 years to rebuild their entire invoicing system, which is insane.

Plus, rebuilds are usually a sign something went terribly wrong in your organization. They are a symptom of something else. When you are in the position that considering a complete rebuild becomes a viable option, the first question you should ask yourself: how did we end up in this situation and what can we learn from it so it doesn’t happen again?

Because you should not be ending up in that situation if you spend enough time gradually rewriting and addressing technical debt. You don’t want to do a rebuild, only to be in the same situation 5 years from now because you didn’t address the underlying issues that put you in the pole position for a rebuild.

And even if somebody would give the green light for the rebuild of your invoicing system, the first thing you should ensure is that invoicing remains working for the entire duration of the rebuild, even if it’s manual work, or keeping the legacy invoice system operational.

It’s too risky to rely on delivering the new invoicing system on time, especially in the kind of dysfunctional organizations that are likely to back themselves in a corner where a rebuild appears as necessary.

Lesson #3: Beware of Any Frameworks Being Presented the Solution

Agile frameworks, like scaling frameworks, don’t fix your problems. If Lean, Agile and Scrum are presented as the golden ticket to fixing your problems and becoming more customer centric, then it’s pretty safe to say you won’t get there.

Organizations are complex systems, this means two things:

1. Expertise matters, but isn’t enough to propose and make the right changes for your organization.

2. What works in another organization, might not work for your organization.

In short, you must experiment and discover what works for your situation. This takes time and isn’t easy, but copy-pasting Agile frameworks or Agile scaling frameworks is guaranteed to not delivering the results you’d want.

It’s much more useful to run a Dysfunction Mapping workshop, and then work on fixing your actual problems before introducing any Framework or Scaling framework.

Frameworks are easy to package and sell, but that doesn’t mean they are the right solution for your problems.

Agile Transformations Are Difficult

When I was writing this article, I was left with one nagging question: would the company have gone bankrupt without doing a digital transformation?

I honestly don’t know.

I do believe, after reading many articles on what happened, that the digital transformation accelerated their demise. Being in the fake Agile, Lean and Scrum slipstream produced an dangerous cocktail of excitement and hubris that made them bite off more than they could chew.

To be fair, Agile transformations are extremely difficult. The Waternet story is a harrowing story of a digital transformation that completely backfired and caused the company to go bankrupt.

The most important lessons from Waternet: when you’ve got a dysfunctional organization, focus on resolving your dysfunctions. Don’t expect any framework or scaling framework to do that for you. I’ve given enough talks at companies all over world to confidently say this approach is guaranteed to fail.

The more problems you have, the less sense it makes to roll out any scaling framework.

Focus on your problems, not the promised land of a solution that will slowly be devoured and dragged down by all your pre-existing dysfunctions.