Great Scrum teams know that Scrum’s essence is learning and ongoing improvement. Scrum and agile have propelled the Japanese term kaizen into the limelight to be much more broadly recognized today than it was 20 years ago. While literally meaning just “getting better,” the Toyota culture uses the term as a slogan, and the international use of the term has taken on the sense of continuous, incremental improvement.
Both continuous and incremental resonate well with the agile software milieux. But first, it’s important that even Toyota views improvement as progressing in discrete quanta interspersed by periods of practice, learning, and normalization. Takeuchi’s Extreme Toyota portrays the improvement process as a staircase with discrete steps:
Change — both good and bad — causes disruption, and the “institutionalize and practice” plateaus tend back towards normalcy. We change one thing at a time to seek both better results and a return to statistical control as we absorb the disruption.
Agile folks also emphasize that changes unfold through incremental, piecemeal improvements. Yet powerful change is not always incremental. We speak of “re-making the organization.” Hurricanes and fires wipe life from the land but plants again take root and a fresh ecosystem quickly bounces back. We’re looking for optima, but incremental approaches alone easily settle into local optima rather than finding a path to the greatest good.
And that brings us to another Japanese word and philosophy of change: kaikaku — radical change. Such change might mean disrupting the lives of distributed team members to instead create collocated teams, or abolishing development management, or discarding job titles. It may remove the boundaries between development, testing, and delivery so that every developer does all three.
If you’ve been paying attention, such properties are fundamental to a true Scrum transformation. Scrum prefers collocated teams; it has no development management; it recognizes no job titles within the Development/Delivery Team; and there are no testing teams or DevOps teams — the Development/Delivery Team does it all. In most organizations, these provisions in themselves spell out changes beyond incremental kaizen. It’s kaikaku. You have to break a few eggs to make an omelette. Every organization has eggs that must be broken — and you don’t break eggs incrementally.
Organizational change follows one of three paths: reject, rationalize, or replace. Organizations that reject the opportunity to become agile risk being put out of business by more savvy competition. The largest groups are rationalizers, who implement suboptimal mixtures of old and new because, for example, it’s just too large of a discontinuity to fire development managers or to give total product control to the Product Owner. And then there are those who are willing to throw it all away: to replace the status quo with something better.
The key to reducing risk is in the “to be willing” part. You may discard everything you are doing, but not all at once. And maybe you are already doing some things right. But attend to continuous discontinuity — alternating radical change and incremental refinement.
The fly in the ointment is that several old practices may be intertwined and must be retired together. The more old practices you retain at the beginning, the greater the entanglement of practices, and the lower the chance that you’ll ever completely escape the old ways. Just as manufacturing work cells displaced assembly lines, so a Scrum organization displaces development management. It does not evolve from it.
So as you embrace agility, soberly consider whether an incremental approach alone might leave you at a local Scrum-butt maximum. As Thomas Jefferson quipped, a little revolution now and then is a good thing.
