So how do I go about explaining people that the slow-means-safe line of thought is wrong?
I've come up with a little model I'd like to go through here.
I start off with defining a Rate of Development, which we'll assume is constant throughout the model (leaving out factors as motivation and skill).
Now, having a high rate of development is not worth anything if we're not Doing the Right Thing. This symbolizes working in the right direction, and our Performance ultimately is decided by Doing the Right Thing at our Rate of Development. Performance represents the long term success of our organization.
So so far we've got RoD x DtRT => Performance
Now we won't pick at the RoD in this model (assumed to be constant), but rather look at DtRT: Doing the Right Thing encompasses all the hundred little decisions we make every day, from whether or not we should rename this method, which OS we choose on our servers, to which feature we choose to develop. So what tells us what is the right thing to do? Answer: Feedback.
Feedback => DtRT
Feedback comes from customer (support, sales, social media), developers (retrospectives, standups), monitoring metrics and logs on the product, doing user experience testing, market response and stuff like that. This feedback gives us the intelligence we need to Do the Right Thing.
How can we increase Feedback? Answer: With more Frequent Releases. This is fairly intuitive, releasing more frequently will increase the mass of Feedback in most channels.
Frequent Releases => Feedback
At this point traditional management will cross their arms and say hold on, it's not that easy: We can't risk releasing more often, it's too dangerous. So, let us consider Safety as a parameter for that.
Safety => Frequent Releases
Safety means no nasty bugs or deployment botches. The problem with management is that they mix up what is the cause of the effect here. They see Frequent Releases as a driver for Safety going down, while in reality it is on the other side the factors lie.
So let's dig a bit deeper and see what leads to Safety. Here are the typical factors:
- Tests (automated tests, unit-, integration-, as well as manual testing where necessary)
- Good Code (fewer unexpected side-effects from making changes)
- Small Feature Set
The first two there are fairly obvious. The last one is a pill management has a hard time swallowing:
Releasing a Smaller Feature Set means more safety, because there are fewer features to figure out, develop, and to test in parallel. Fewer moving parts that can malfunction, so to speak.
Now the model is complete. Have a look at the complete thing:
(You can also draw a line from Doing the Right Thing leading back up to the factors increasing Safety.)
Typical objections from management that object to this model (exercise for the reader: are these fallacies or not?):
- Doing the Right Thing is better decided by planning/strategy/architecture, than by Feedback.
- Safety increases linearly with QA: 10 times as many features is just as well tested by 10 times the QA.
- Good Code is irrelevant to Safety. (Refactoring is actually regarded as a minus to safety in some places).
While Frequent Releases are the result of Safety and the drivers behind it, traditional management unfortunately sees it as a lever they can turn down to increase safety.
So, I'm not sure if the model will be of any help to you. For me it's just a nice way to explain the benefits of frequent releases to non-developers.