I think the contrast shouldn't be with rethinking fundamental assumptions, which is another good but rare activity. It should be with assuming that things are pretty much as good as they get, or assuming that small wins aren't worth bothering with. Because that's where a lot of businesses are all the time. Computer hardware is very much the exception.
If you want an example of where this matters, the car industry is a great example. In Rother's "Toyota Kata", he has a graph showing productivity per worker among big auto firms. The large car companies all rise together until the 60s and then plateau. Toyota, which had a very strong focus on continuous improvement just kept on rising for decades. This enabled them to go from Japan's post-war decimation to become the world's largest car maker while the others stagnated.
And I should add that continuous improvement is a good way to drive fundamental rethinking. The only way to get long-running continuous improvement is to pay a great deal of attention to how things actually are working. Eventually you will say, "Well, now that we've solved a bunch of little things, the biggest bottleneck is X". But changing X forces fundamental reevaulations.
For example, consider software release. Unreleased software is like inventory just sitting around the factory. You've paid money to make it, but it's not earning any money for you.
Years ago, quarterly and annual release cycles were common. The last part of the cycle was when a large, manual QA team would beat up the whole product. As we have kept squeezing release cycles, this has forced all sorts of innovation. At my last couple of companies, we've used continuous deployment, where every commit to master is automatically tested and deployed to production. These small teams averaged a few releases a day and had no QA people. Etsy has 50+ releases a day [1]. If you were to describe this to people 20 years ago, they'd call you insane; it's a fundamentally different view of how software gets made. But we've gotten there via 15 years of continuous improvement.
To be fair, quarterly and annual release cycles were common when software was a physical product. Games had to sell retail, and enterprise software still needed to deliver disks. Until the early 2000s there was no point in continuous integration because your release process still had to be waterfall - you were gated by extremely slow physical processes like retail outlet logistics.
Once continuous deployment to the end user was possible (via the internet), the industry started following suit. And nowadays there is still something similar for iPhone developers - you're gated by the Apple app store, which doesn't have to be slow, but somehow still is. (This has important implications like having to backload a huge amount of testing before app submission because you can't be certain of how quickly you'll be able to release a frontend patch).
Sure, the shift in delivery mechanisms provided a lot of incentive to move to faster deployment.
But I should note that a great deal of software in ye olden dayes was in-house software, and that still ran on 3-18 month cycles. And that wasn't because of technological limitations; my dad was delivering new versions of software every few days even in the 70s. It's just that the conceptual model and the dogma pushed in the direction of long, heavily-planned release cycles. The Internet's main contribution here was to make short cycles not only possible for commercial releases, but competitively advantageous in an obvious way.
Comments
I think the contrast shouldn't be with rethinking fundamental assumptions, which is another good but rare activity. It should be with assuming that things are pretty much as good as they get, or assuming that small wins aren't worth bothering with. Because that's where a lot of businesses are all the time. Computer hardware is very much the exception.
If you want an example of where this matters, the car industry is a great example. In Rother's "Toyota Kata", he has a graph showing productivity per worker among big auto firms. The large car companies all rise together until the 60s and then plateau. Toyota, which had a very strong focus on continuous improvement just kept on rising for decades. This enabled them to go from Japan's post-war decimation to become the world's largest car maker while the others stagnated.
And I should add that continuous improvement is a good way to drive fundamental rethinking. The only way to get long-running continuous improvement is to pay a great deal of attention to how things actually are working. Eventually you will say, "Well, now that we've solved a bunch of little things, the biggest bottleneck is X". But changing X forces fundamental reevaulations.
For example, consider software release. Unreleased software is like inventory just sitting around the factory. You've paid money to make it, but it's not earning any money for you.
Years ago, quarterly and annual release cycles were common. The last part of the cycle was when a large, manual QA team would beat up the whole product. As we have kept squeezing release cycles, this has forced all sorts of innovation. At my last couple of companies, we've used continuous deployment, where every commit to master is automatically tested and deployed to production. These small teams averaged a few releases a day and had no QA people. Etsy has 50+ releases a day [1]. If you were to describe this to people 20 years ago, they'd call you insane; it's a fundamentally different view of how software gets made. But we've gotten there via 15 years of continuous improvement.
[1] http://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day
To be fair, quarterly and annual release cycles were common when software was a physical product. Games had to sell retail, and enterprise software still needed to deliver disks. Until the early 2000s there was no point in continuous integration because your release process still had to be waterfall - you were gated by extremely slow physical processes like retail outlet logistics.
Once continuous deployment to the end user was possible (via the internet), the industry started following suit. And nowadays there is still something similar for iPhone developers - you're gated by the Apple app store, which doesn't have to be slow, but somehow still is. (This has important implications like having to backload a huge amount of testing before app submission because you can't be certain of how quickly you'll be able to release a frontend patch).
Sure, the shift in delivery mechanisms provided a lot of incentive to move to faster deployment.
But I should note that a great deal of software in ye olden dayes was in-house software, and that still ran on 3-18 month cycles. And that wasn't because of technological limitations; my dad was delivering new versions of software every few days even in the 70s. It's just that the conceptual model and the dogma pushed in the direction of long, heavily-planned release cycles. The Internet's main contribution here was to make short cycles not only possible for commercial releases, but competitively advantageous in an obvious way.