Loading ...
Sorry, an error occurred while loading the content.

5055FW: [scrumdevelopment] Frequent Releases

Expand Messages
  • Shimmings, Ian
    Oct 29, 2004
    • 0 Attachment

      My current hobby-horse!  Release as soon as it is possible.

       

      Ian

       


      From: Ron Jeffries [mailto:ronjeffries@...]
      Sent: 29 October 2004 12:07
      To: scrumdevelopment@yahoogroups.com
      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
      know.

      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.

      Bottom Line

      If we're not shipping our software when it's ready, it's poor business
      practice.

      If we're not sure whether our software is ready, it's poor software
      practice.

      Ron Jeffries
      www.XProgramming.com
      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
    • Show all 6 messages in this topic