Discontinuous Improvement
Please log in to watch this conference skillscast.
Continuous improvement is based on balancing what we desire with the practicalities of time and effort. Continuous improvement gives us control of our changes and our situation, guided by feedback and reflection. But change is not always ours to control and, if we are honest, some changes are better carried out discretely than discreetly.
Change from outside can arrive gradually and then all at once. It can be a surprise because we could not have known, or it can be a surprise because we chose not to know. Most changes described as disruptive were there all along and, in truth, are only disruptive because of attitude and entrenchment. But whether the change forced upon is sudden and catastrophic because it is sudden and catastrophic or simply because we didn't know better, we may find that evolution is forced upon us.
How can we respond?
Q&A
Question: Do you think companies and the people inside of them don't really want to be agile? Change inspires fear and discomfort, are there ways to get people to embrace the uncertainty of true agile?
Answer: I think there is an element of truth here, but that truth is well hidden. While some people explicitly don't want to change, for many that resistance is not so obvious (even to them). Humans are messy, and we often find that we can both want something but at the same time work against ourselves getting it. Fear and discomfort tend to work at this level, so they're harder to see and account for.
Question: Any tips for ways to estimate business value (without breaking laws of physics)?
Answer: Like other estimations, a good tip is to look at the past: both for (i) what did we say? (ii) what did it turn out to be? and for what is the range/shape of variation. That'll give you the appropriate humility and scepticism to temper estimates of future value. And, as with any estimate, don't rely on a single point value on a linear scale to be your estimate. Estimates are probability distributions, so acknowledge that by estimating with a range, three points or a non-linear scale.
Question: Could we suggest that the reduction in company lifespans is related to missing a big step/radical change at the right time, instead of focussing on continuous everything?
Answer: As mentioned, continuous is often a way of saying discrete with smaller-than-what-we're-used-to steps. So, the steps are getting smaller with time, and the amount of what can happen in a period of time increases with increased connectivity, which is a fairly good description of many trends of the 20th and 21st centuries.
Question: Just wanted to pick up on the idea of 'travelling light' or having less stuff. I've been thinking about this recently, in terms of how do you avoid an ever growing pile of code. I wonder if companies die quicker because we can type quicker now, so they drown in technical debt that stifles their agility faster. Any practical tips on how to deprecate code / systems / features faster?
Answer: So the amount of what can happen in a given time is going up, but our habits/complacency might be preventing exactly that awareness of the right time. Well, typing is not the bottleneck in software development :) But our ability to create and connect more stuff and connect more people to it effectively increases the amount and pressure on the stuff that we create. We are more pressured to add in the short term, but neglect removal and retirement of code, dependencies, frameworks, systems, etc., which is often what is needed for the long term.
I think we have to increase our awareness of the code and the feature set through techniques such code analytics (see Adam Tornhill's book Your Code as a Crime Scene), ADRs (Architecture Decision Records), marking features as experimental/deprecated/etc. (and meaning it), runtime monitoring (what actually is going on in our code, and what gets used?), dependency management (we need to reduce our depend-on-everything unconditionally approach, e.g., npm) and so on.
YOU MAY ALSO LIKE:
Discontinuous Improvement
Kevlin Henney
Programming · Patterns · Practice · Process