5055FW: [scrumdevelopment] Frequent Releases
- Oct 29, 2004
My current hobby-horse! Release as soon as it is possible.
From: Ron Jeffries [mailto:ronjeffries@...]
Sent: 29 October 2004 12:07
Subject: [scrumdevelopment] Frequent Releases
We've been talking a bit about frequent releases, the notion of "deployed"
vs "deployable", the "cost" of deploying, and so on. I'd like to bring out
just two points.
The most common reasons given and used for infrequent deployment are
evidence of poor software development practice.
Infrequent shipment is evidence of poor business practice.
Reasons Given for Infrequent Deployment
In my experience, and there's been a lot of it, the most common stated
reason for deploying infrequently is "the customers don't want it." In my
experience, the /real/ reason for deploying infrequently is that when we
deployed last time, we nuked the customers with so many defects that they
and we are scared to do it again.
When we face people with this truth, their most common come-back is "But if
we change features, the customers would have to retrain everyone, and we
would have to retrain all our support people. There's more to it than just
bugs." When we look at the truth of this we find that we can readily change
features by adding new items to the menu that people don't have to use, we
can build features that walk you through doing whatever the new thing is,
and that in fact we don't need to build software that requires retraining
every time we release a version.
"Yes, but we have to rewrite the manual and reprint it." I answer: "If your
developers can refactor and develop real running tested code between now
and when the feature is ready, a tech writer can certainly update the
documents in the same amount of time." And I can point to teams that do it
just that way. No one rewrites the manual every time out: they update it.
I can't think of a case I've seen where all the reasons didn't come down to
just one: we're afraid that it won't work.
Fear of Defects is Evidence of Poor Development Practice
If we're afraid of there being defects in the code, that means we don't
know whether there are defects or not. Otherwise we would have said "There
are exactly 11 defects in the code, and we couldn't possibly ship until
they are fixed."
Therefore, our development process is producing code of unknown quality.
That would be bad. Our code is untested, and uninspected. Otherwise we'd
know. But we know, as Agilistas, what to do about that. XP calls the
relevant practices Test-Driven Development, Acceptance Tests, Pair
Programming. Whatever you call them, they are about knowing rather than
fearing what the situation is. They're about rapid feedback.
And we know that the best thing to do after discovering a defect right away
is to fix it right away rather than build on it.
If an organization fears release, it's evidence that they aren't doing the
right things, or that the word has not been communicated. If they don't
know the defect situation, they should fix their practices so that they do
Business Impact of Infrequent Deployment
Undeployed software is inventory. Inventory is now understood to be waste.
When the software is deployed, it starts to bring in value. It might bring
in dollars, it might bring in customer satisfaction. Either way, we
wouldn't be writing it if it wasn't supposed to bring us value. We don't
get the value until we ship it.
If we're not shipping our software when it's ready, it's poor business
If we're not sure whether our software is ready, it's poor software
Comments lie. Code doesn't.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
This e-mail has been scanned for viruses by MessageLabs. The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error, please notify Conchango plc as soon as possible. The unauthorised use, disclosure, copying or alteration of this message is prohibited and may be unlawful. The internet cannot guarantee the integrity of this message and therefore Conchango plc will not be liable for the message if modified.
Reg. Heritage House, Church Road, Egham, Surrey, TW20 9QD T 44 (0) 1784 222 222 F 44 (0) 1784 222 200 E talktous@... No. 2598884
- Next post in topic >>