Most of the transformations I've seen announced were changes.
I use the two words differently.
A Change is an adjustment to a Tool: a new process, a new platform, a new org chart. A Transformation is an Attribute that measurably moved: the software became more Timely, the organization more Aligned.
It usually takes several Changes to produce one Transformation. And plenty of Changes produce none.
In one organization I led, we changed how work was tracked, how leaders made decisions, and how work was prioritized and sequenced. Those were Changes.
They were aimed at three of the ecosystem's Attributes: Transparency, Alignment, and Focus. Ecosystem Attributes are harder to measure, and you rarely get a clean before-and-after number. But improving them stabilizes the foundation, which gives the Attributes above it something solid to move on.
The Transformation ultimately showed up in the pillars. The software became more Timely: release cycle time dropped from 14 days to 10. It also became more Innovative and Maintainable. One measure of both was the ratio of new feature work to maintenance, and new feature work overtook maintenance.
Transformations fail when an organization makes a Change and declares victory without checking whether the Attribute moved. The new process is in place. Everyone is following it. Delivery is no more predictable than before.
Treat every Change as an experiment, and only call it a Transformation once you've measured it.
I created the House of Software Value Delivery to keep those two things separate.
