A painful modernization story
Leadership at one company wanted to modernize their core platform. There was an obvious way to do it.
They chose the other way.
After years of investment, the modernization had delivered nothing, millions had gone to consultants, and the company was downsizing.
What went wrong?
The obvious way
This is not a unique story. A lot of companies overcomplicate their modernizations.
At this company, they already had a high-performing Scrum team managing their core product. The obvious move was to engage their existing Product Owner and empower them to lead the modernization effort with the current Scrum team. They already understood the business, the customers, the edge cases, and the real constraints. They had the empirical knowledge that only comes from delivering value Sprint after Sprint, and they'd just wrapped up a major initiative successfully.
Done right, this was a chance to energize the team that already knew the product best. They could have started replacing the existing system a piece at a time and learning as they went. If leadership wanted to move faster, they could have added additional staff and support to the existing Scrum team.
The other way
Instead of engaging their existing Scrum team, the company formed several new Scrum teams to do the modernization effort. Leadership then decided that because the new Scrum teams were just rebuilding the current product, they didn't need a Product Owner.
They worked for six months without a Product Owner, but nothing usable was delivered. When the organization finally did add Product Owners, they weren't really empowered to make real business decisions. It was too little, too late.
Here's what went wrong:
Siloed teams. Not only were they separated from the current team, but the new teams were formed around technology silos which created unnecessary dependencies.
No empowered Product Owner. No one was empowered to steer the modernization effort.
Big-bang thinking. Unrealistic, leadership-defined deadlines, no incremental delivery.
Ignoring the people closest to the work. Money and Vice Presidents instead of engaging the team that already knew the product.
No Empirical approach. They didn't adjust their delivery approach beyond just surface-level changes when things weren't going well.
Development and testing were in separate Sprints. They hired a design firm who put together a front-end design and html in one Sprint, and then back-end development and testing was done in the following Sprint. Repeatedly what was delivered couldn't be used and had to be sent back which caused delays on top of delays.
I have watched versions of this story play out before, and throwing more money at it is not the answer and siloed teams rarely work well.
The result of getting the structure wrong
Ignoring existing institutional knowledge and starting over with a group that had no empowered Product Owner was not “saving money.” It was the most expensive decision they could have made.
In the end, the company wasted so much money that it led to downsizing.
They never got their modernization. Instead, they got restructured.
How to get it right
Great modernization efforts don't happen by accident. They start with the right structure and the right people already in place.
Start with good structure
First off, a Product Owner is not optional. A Product Owner owns the Product Goal, orders the backlog, and makes strategic decisions. Without an empowered Product Owner, a Scrum Team is just a group of people throwing code around.
Energize your high-performing teams
Leadership should not redesign the org chart every time they get excited about a new technology. Leadership should remove impediments, make sure the team has the resources they need, and make sure the team is working together effectively.
Keep the high-performing teams. Give them the support they need. If the old system truly needs to be replaced, the people who already understand the volume, the data, and the business rules are the ones best positioned to make that transition safely and incrementally.
Plan for Incremental Delivery
A year of work with nothing usable to show for it is not Agile.
Modernization doesn't have to mean a big-bang rewrite. Encourage the Scrum team to break the work down. They should deliver small, usable pieces of the new system, get feedback, and build on it. Let the team plan their own Sprints instead of chasing top-down deadlines set before anyone understood the scope of the work.
Three questions to ask before you modernize
If your organization is about to launch a modernization effort, ask yourself three questions.
Who has organizational knowledge
Who already owns the current Product and has the deepest knowledge of it?
Is the team structured for success?
Are we organizing around the Product or around technology silos? Can we allow them to self-organize?
Are we planning for incremental delivery?
Will we deliver usable increments every Sprint, or are we planning a multi-year rewrite with nothing to show until the end?
Answer those honestly. Then act on the answers.
Otherwise, you already know how the story ends.
