Agility versus stability: Squaring the circle
Delivery-focused people talk a lot about agility in software development. How can we turn on a dime? How we can we respond to the whims of the market before our competitors? How can we learn from our mistakes as fast as possible? Meanwhile, folks managing engineering teams talk about stability. We say that it takes a stable team to build trust, to build and sustain culture, to provide sufficient “ownership” of our systems that people invest time in their improvement and maintenance.
Can we really be agile and stable at the same time?
I think it’s interesting to think about the different cadences that we see in software development and in our related business environment. What inherently goes fast? What inherently goes slowly? What happens gradually, and what happens suddenly? What can we choose to speed up or slow down?
We know that it can take us months to hire people, and months for them to become productive in a new environment.
We know that in, say, two years, a person might come to feel like an expert in a particular technology or system they are focusing on, and also that at this point they might get itchy feet and hope for a new challenge.
High level strategic adjustments might happen on a yearly cadence in a mature organisation. A product organisation might meet to sketch out the season’s plans quarterly, or six monthly.
So far, the cadences we’re talking about are roughly the same order of magnitude. There’s not a huge discrepancy between the cadence of business change at this point and the cadence we might like to see of engineers moving around between systems, or business areas, or technologies.
In many organisations, however, all kinds of abrupt-seeming changes of direction or priority descend from above engineering teams in ways that are irregular and harder to predict. This is where we start to see a conflict between “agility” and “stability”.
In many cases, the sudden changes we see are comparable to the sudden large steering inputs you see from people trying to steer a large boat, like a canal boat, for the first time. A canal boat responds to steering inputs very slowly — people steer a little bit, nothing seems to happen, they steer more, nothing happens. Suddenly the boat is heading into the weeds, so most people instinctively jam the rudder over the other way. Soon they’re retrieving their decorative cushions from the bushes on the other side.
In other words, while some unpredictable changes of direction will always be caused by real external rapidly changing factors, some of them are not at all — they’re just a side-effect of the process of trying to steer the boat.
How, then, do people learn to steer more effectively? The first trick of steering the canal boat is to take a longer term view. Steering towards a further away point gives you smoother steering than trying to take it one little bit at a time. The second trick is to get better at feeling the effects of the steering inputs you make. Once you can feel the tiny incremental direction changes the boat is making, you learn to make tiny incremental inputs and wait patiently for them to give tiny results. Presto! You’ve “got the feel of the boat” and you’re away on your holiday! The smaller the microadjustments you make, the smoother the trip, and the easier it is to change the direction of the boat without ending up in the bushes. You have the agility you need to moor up at the pub successfully before dark, along with the stability of a smooth course that doesn’t pay unscheduled visits to passing shrubbery.
So this is my current “Agile And Stable” resolution:
- Understand and communicate the long term view
- Get better at measuring and reporting on outcomes
- Make small adjustments and have patience waiting for them to take effect
Maybe in a couple of years I’ll figure out whether it worked!
