19 December 2011
Breaking through the Wall of Release Mediocrity
In my last post I discussed the problem of overestimating the quality of your software development and release process. In that scenario the time period allotted for a release is simply too short for a successful result. Of course, you can go wrong the other way as well.
Let’s say that you are the new configuration manager at a small software house. The managers feel that their release management is conducted a bit “ad hoc” and they have brought you in to restore order. You, on the other hand, Mr Big Shot CM, have been trained for years on how to perform professional release management at the big enterprise with lots of engineers. Real engineers, mind you, not fakey information ones. After you have assessed the situation you dictate that releases may only occur at most twice a year with a two-month stabilisation phase each. The developers shake their heads, but you are the professional so hopefully you know what you’re doing.
Let’s think about it, was this a wise move? Yes, this probably makes releases more regular and dependent (for a while at least), but is that really something the customers have requested? They will get their software later. The organisation will also have to take on the challenges of coordinating big batches of work and a lot more work going on. This is unnecessary work and costs money. So maybe the only thing you managed to create with your “professional” release process was a loss of customer and business value?
From both these examples we may draw a more general conclusion: Release problems occur when you misjudge the maturity of your development and operations process. You may think it’s less mature than it actually is, and mandate an unnecessarily long release period, which will lead to ceremony and unneeded work, or you may think it’s more mature than it really is, and mandate a unrealistically short release period, which will lead to instability and emergencies.
* * *
Instead, the length of your release phase has to be in synch with the maturity of your process. And the maturity, in turn, is correlated to your context. In a small, informal, risk-free environment, say an prototyping experiment, your process can and should be very “immature”. There is no point having a mature process. In a complex, formal, life-and-death context, say software for pace makers, your process has to be very mature. The problem is that people typically don’t know what mature looks like.
This can be illustrated as a graph of Ideal Release Period Lengths vs Process Maturity/Context Complexity below:
Let me explain. On the low end of the scale, you have hacking. There are lots of bugs but you fix them continuously, right there, in production. Very immature (maturity M is zero), but remember, complexity C is also zero. This is a small and unimportant setting and it’s fine. The ideal release period length (IRPL) is zero.
As things get more complicated, your process needs to mature too. More stakeholders and more servers demand it. More people are involved and you have to agree on how to do things. Both C and M increases (we move to the right). The IRPL gets longer. Of course, this is not only a good thing from a customer perspective, they have to wait longer for their software, but most companies accept this as if it were a natural law.
Some companies, in highly complex environments, will go to extremely bureaucratic procedures and in that situation, for their maturity, very long release periods are actually ideal (companies in the pharmaceutical arena come to mind). Some are even proud of having very long release phases, their judgement clouded by words like “professionalism” and “best practices”. This is the peak of the graph, which I hereby dub “The peak of release mediocrity”. It is mediocre because in reality it pays maximum bureaucracy for medium maturity.
These companies don’t realise that they are mediocre, because what is on the other side is protected by a sort of wall. It’s a wall of tradition, culture, management practices, and, most of all, of mindset. It takes real effort to jump over it.
At some point, in some organisations, teams do manage to break down the wall. What I think happens at this point is that these organisational heroes stop looking out for their own self-interest (long release periods is a kind of protection) and start looking honestly at what is best for the customer. It’s just that they start to view the world differently. They are determined to improve everything, everything from their understanding of user needs to the release process. And they do. They gradually improve. Process maturity M increases again. C, though, cannot get any higher and stays the same on the entire right hand side of the graph.
One day soon they realize that “Hey, we’re pretty good. We can take advantage of that and release more often without risking anything.” They are again finding that their IRPL has decreased. When they fully understand the benefits of this capability they get addicted to it. They fight like crazed cats to get that cycle time between releases down. As mentioned above, some manage to take it all the way down to minutes between releases. In effect, the same times as for hacking in production.
So, don’t kid yourself. Acknowledge where you are on the graph and strive to set your release periods accordingly. Of course, if you want to be great, strive to move past the wall of release mediocrity. This is where the disciplines of lean and agile development fit like a glove.
Comments are closed.