I use the phrase “continuous improvement” daily. The idea resonates with me on a deep level. But I’ve come to the conclusion that improvement is rarely continuous over an extended period of time. Our attempts may be continuous, but the actual improvement is not. In fact, things often get worse—or
How do you know when a team effectively hit's the local maximum? is there not always something small they can improve? To the house example there is always something else that can be revamped it is truly "continuous" well in my house anyway 😅
Maybe for larger improvements it should be considered delayed improvement vs continuous improvement 🤔
Love the scaffolding metaphor (and probably overuse it)
I think it’s important to be intentional about whether the scaffolding will be permanent, ephemeral or adaptable over time.
With scaffolding to support the building work like you mention, it’s vital that you have a plan to take it down again before you put it up. And worth remembering that the building work always takes way longer than estimated, and the scaffolding stays around even longer.
I'm trying to slow things down on purpose, or a least not doing everything that is requested of me as a consultant ("we have to implement all the dozens of rituals of this scaling framework and launch 10 new teams applying those practices in the next quarter"): it might get me kicked out from some discussion tables and opportunities, but I do believe in the concept of discontinuous improvement — that the idea of "forced improvement" that is often implicitly sold through agile consulting is just magical thinking ("we are agile therefore we improve").
I don't see much difference, but perhaps it's because my definition of continuous isn't a mathematical one implying a positive slope in the graph of improvement. I see continuous improvement as a summation of multiple bets the team is making, of which an individual bet may produce a negative value, but the overall sum of is much more likely to be positive.
For example, some realistic and common areas a team could be seeking improvement might be code quality, getting better quantitative user feedback, and better understanding achieved outcomes. Let's drill into one of these more, let's say getting quantitative user feedback. You can place three bets on how to get better at this. Let's say tracking page view time, putting a star rating popup at the end of a flow and having a live chat option and see how often it's requested.
Two of these may be total failures but one might produce something of value. So yes, two of those didn't lead to improvement, but one led to some acquisition of new knowledge and some improvement. You may have reached a "local maximum" on getting quantitative user feedback by tracking page view times, but you haven't through star ratings. Is this discontinuous improvement? Seems like a harsh positioning of the situation because overall there is improvement.
Your last statement would ring more true if you adjusted it to say, "Sustainably keep trying, but don’t expect continuous improvement in every bet you place"
How do you know when a team effectively hit's the local maximum? is there not always something small they can improve? To the house example there is always something else that can be revamped it is truly "continuous" well in my house anyway 😅
Maybe for larger improvements it should be considered delayed improvement vs continuous improvement 🤔
Love the scaffolding metaphor (and probably overuse it)
I think it’s important to be intentional about whether the scaffolding will be permanent, ephemeral or adaptable over time.
With scaffolding to support the building work like you mention, it’s vital that you have a plan to take it down again before you put it up. And worth remembering that the building work always takes way longer than estimated, and the scaffolding stays around even longer.
I'm trying to slow things down on purpose, or a least not doing everything that is requested of me as a consultant ("we have to implement all the dozens of rituals of this scaling framework and launch 10 new teams applying those practices in the next quarter"): it might get me kicked out from some discussion tables and opportunities, but I do believe in the concept of discontinuous improvement — that the idea of "forced improvement" that is often implicitly sold through agile consulting is just magical thinking ("we are agile therefore we improve").
Always an enjoyable read. Thank you.
I don't see much difference, but perhaps it's because my definition of continuous isn't a mathematical one implying a positive slope in the graph of improvement. I see continuous improvement as a summation of multiple bets the team is making, of which an individual bet may produce a negative value, but the overall sum of is much more likely to be positive.
For example, some realistic and common areas a team could be seeking improvement might be code quality, getting better quantitative user feedback, and better understanding achieved outcomes. Let's drill into one of these more, let's say getting quantitative user feedback. You can place three bets on how to get better at this. Let's say tracking page view time, putting a star rating popup at the end of a flow and having a live chat option and see how often it's requested.
Two of these may be total failures but one might produce something of value. So yes, two of those didn't lead to improvement, but one led to some acquisition of new knowledge and some improvement. You may have reached a "local maximum" on getting quantitative user feedback by tracking page view times, but you haven't through star ratings. Is this discontinuous improvement? Seems like a harsh positioning of the situation because overall there is improvement.
Your last statement would ring more true if you adjusted it to say, "Sustainably keep trying, but don’t expect continuous improvement in every bet you place"