The other day I was talking to someone about release processes. Specifically, about convincing non-technical stakeholders that frequent releases are more desirable than less frequent ones. My friend said his stakeholders (correctly) saw their current quarterly releases as painful and error-prone, so they didn’t want those to happen more often.
I offered the argument that the aim was for smaller releases (which were more frequent) which would therefore be less painful and error-prone, but my friend said he’d tried that, and hadn’t been successful. Still, he continues to pursue it.
Clearly this was a more complicated conversation than it appeared, at least for those of us who have experienced small frequent releases and for whom the benefits are “obvious”. So I thought I’d have a go at mapping out the arguments. Here they are as a causal loop diagram. (Click to download a larger version.)
The way to read this is that “s” means “same” and “o” means “opposite”. An “s” arrow from one thing to another means that an increase in the first leads to a increase in the second, and a decrease in the first leads to a decrease in the second (same direction). An “o” arrow means an increase in the first leads to a decrease in the second, and a decrease in the first leads to an increase in the second (opposite direction).
When I started this, my expectation was that I would have 2-3 things on the left linked directly to 2-3 things on the right. One valuable outcome from the diagramming process was that more and more issues popped up as I tried to draw what was in my head. I’ve got a fair bit of experience in release processes, but I did not immediately consider some of the issues when I spoke to my friend, and I certainly didn’t articulate their relationships.
Clearly this is complicated, and that helps explain why a conversation on this topic can be slippery and frustrating—it’s unlikely either party has a map of all the issues in their head, and it’s even more unlikely they share the same map.
Also, to stop the diagram getting even more spaghetti-like, I’ve entirely omitted the question of how long is spent on releases: larger releases take up more time but less often… how much time is left for core development? It’s complicated. Another question omitted is errors that arise not from the feature bugs, but from mistakes in the release process. So this diagram could be even bigger.
But even as it stands, the diagram forces us to face some uncomfortable truths, which need to be discussed with anyone on the other side of the argument. For me the most obvious of these is that bigger releases deliver more value than smaller releases. The counter-argument, of course, is that smaller releases happen more frequently—and they tend to happen earlier, so the value is delivered earlier. But, still, this is a discussion that has to happen.
As before, I’ve found that drawing out a dynamic situation in a causal loop diagram does not produce a slam-dunk answer of what’s right and what’s wrong. But it is very helpful to have the issues mapped out clearly for all to see, and that should help everyone have a conversation that is much better grounded in common understanding.
niksilver.com 