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

Re: [XP] How to accomodate Agile Process and an Alpha-Beta based Process ?

Expand Messages
  • Steven Gordon
    Thierry, The classical alpha/beta process assumes software will be riddled with bugs (and misunderstood requirements) during development until unleashed on QA
    Message 1 of 7 , Oct 1, 2007
    • 0 Attachment
      Thierry,

      The classical alpha/beta process assumes software will be riddled with
      bugs (and misunderstood requirements) during development until
      unleashed on QA and some special customers, and that the repairs will
      happen after development.

      This is an expensive and inefficient approach, but if it is working
      well enough for any organization, there will be no motivation to
      change it. With each phase given separate budgets, it is easy to
      ignore the post-development costs.

      Agile slices the process orthogonally, so that each feature is
      developed, reviewed and repaired in a short time frame before the next
      feature is attempted. Many have found this to be a more effective way
      to develop software for dozens of inter-related reasons. However,
      this is a big change that impacts the culture of the entire
      organization. Again, if an organization is not experiencing
      significant pain in their current approach, there is not enough
      motivation to work through the pain of culture change.

      It can still sometime feasible for a single project to try the agile
      approach within a "traditional" organization. The end result would
      usually be that the project would appear to be more expensive
      (learning curve and scope changes, as well as QA being done
      simultaneously under the development budget) and the QA, Alpha and
      Beta phases would become unnecessary waste that will not go away.
      Again, if the organization does not feel pain doing it the traditional
      way, such successes will often not be viewed as successes by the
      powers that be.

      So, unless the problems with the current approach are acknowledged,
      agile has very little chance.

      Steve

      On 10/1/07, thierry_cattel <thierry_cattel@...> wrote:
      >
      >
      >
      >
      >
      >
      > Hello,
      > I work in a company where SW is developped along a waterfall
      > classical process :
      > - Gogate
      > - Specification writting and signing
      > - Development
      > - QA manual testing
      >
      > - Alpha Milestone : product feature complete with plenty of bugs...
      > - Beta Milestone : Alpha + no major bugs
      > - Release Candidate : Beta + only minor bugs
      > - Gold Master : RC + ready to ship
      >
      > When presenting a plan based on User Stories (using Mike Cohn books
      > for instance), people ask whether :
      > - all iterations will be delivered before Alpha (they expect it)
      > - bugs will be detected by QA at the end of iteration I and fixed
      > at the beginning of iteration I+1. If the answer is yes, they find
      > challenging to keep the pace of iterations while fixing bugs...
      >
      > Has someone convincing arguments or approach to accomodate both views
      > so that they dont seem antagonistic ? or so that agile is accepted
      > inside a classical one ?
      >
      > Thank you very much in advance
      >
      > Thierry
      >
      >
    • Laurent Bossavit
      Hi Thierry, ... Who are they that you are referring to above ? The customers ? ... Here too, which they are you referring to ? Are you talking about the
      Message 2 of 7 , Oct 1, 2007
      • 0 Attachment
        Hi Thierry,

        > - all iterations will be delivered before Alpha (they expect it)

        Who are "they" that you are referring to above ? The customers ?

        > - bugs will be detected by QA at the end of iteration I and fixed
        > at the beginning of iteration I+1. If the answer is yes, they find
        > challenging to keep the pace of iterations while fixing bugs...

        Here too, which "they" are you referring to ? Are you talking about
        the developers ?

        Here is an argument you may want to explore in discussion with the
        people who "push back" when you suggest agile approaches, depending
        on how technical they are. It seems that the earlier you detect a
        bug, the less it costs to fix that bug.

        So, the usual approach, where we let all the bugs accumulate until
        the "feature complete" Alpha version, tends to be very, very costly.
        Did you find that the testing phases in your project plans never
        seemed enough to find all the bugs, and seemed to always take longer
        than planned ?

        Agile processes in general and Extreme Programming in particular
        suggests doing differently. Find the bugs early, by testing early. If
        you detect a bugs just a minute after you wrote it, it will be very
        cheap to fix. (That's what you get by using Test-Driven Development.)
        If you detect a bug less than two weeks after you wrote it, it will
        still be relatively cheap to fix. (So "ship" a version to the QA
        people, or even better to someone who can use it like the end users
        will use it, every iteration.)

        The more you wait, the more each bug infects the rest of your
        product. The best time to fix a bug is right when you detect it, and
        the best time to detect is is just after you write it... Or even
        better, just before.

        I'd like to stress that this is an idea to explore in discussion.
        Simply ask people "Have you thought of bugs that way before ? If not,
        do you think it makes sense to think of bugs that way ?" Encourage
        people to think of this as a hypothesis that could be confirmed or
        disconfirmed by experiment. Ask people what kind of experiment they
        might try to find the truth of the matter.

        You can worry about "convincing" them later. Explore first.

        Laurent Bossavit
        laurent@...
      • William Pietri
        ... Hi, Thierry. You ve got some interesting answers. I can give you another one, although it s not one I personally recommend. Consider this notion: all plans
        Message 3 of 7 , Oct 1, 2007
        • 0 Attachment
          thierry_cattel wrote:
          > Has someone convincing arguments or approach to accomodate both views
          > so that they dont seem antagonistic ? or so that agile is accepted
          > inside a classical one ?
          >

          Hi, Thierry. You've got some interesting answers. I can give you another
          one, although it's not one I personally recommend.

          Consider this notion: all plans are lies.

          In some sense, this is obviously true. If we're doing anything
          interesting, we can't really know the future. Suppose I say that I will
          deliver these 153 features at 10:32 am on July 11, 2009. I can't really
          know that. However, that's the sort of answer that people want to hear,
          and so that's the sort of answer they often get.

          A lot of times, the people doing the lying aren't consciously doing it.
          They might build a complex plan with lots of Gantt charts and UML
          diagrams to completely obscure the fact that they are passing guesses
          off as fact. They generally do this not out of malice, but because
          people keep demanding the appearance of certainty. So they fool
          themselves as well as everybody else.

          One solution is to make a plan, just like people want. In color, even.
          Then you mainly ignore that and start out doing your agile thing.

          When your alpha date comes around, you release what you have. Sure, you
          might have to do some song-and-dance routine about how things changed
          and you had to cut some low-priority features. Which people are used to,
          because that's what waterfall projects do. But you made your date, and
          you can take that chance to get more input on what you should build
          between "alpha" and "final release".


          That's probably the easiest way to mate an agile development process
          with waterfall-driven expectations. I've seen people do it and it works.
          But personally, I prefer the more honest approach.


          Hoping that helps,

          William




          --
          William Pietri - william@... - +1-415-643-1024
          Agile consulting, coaching, and development: http://www.scissor.com/
          Use your geek-fu to fight poverty: http://www.mifos.org/
        • Phlip
          ... Game development, for one, can turn that sideways. Games are super-complex programs that must be manually tested, both to inspect new art ( assets ) and to
          Message 4 of 7 , Oct 1, 2007
          • 0 Attachment
            > - Alpha Milestone : product feature complete with plenty of bugs...
            > - Beta Milestone : Alpha + no major bugs
            > - Release Candidate : Beta + only minor bugs
            > - Gold Master : RC + ready to ship

            Game development, for one, can turn that sideways. Games are
            super-complex programs that must be manually tested, both to inspect
            new art ("assets") and to continuously ensure a game is fun.

            In a game, you deploy daily to create an alpha, and testing starts
            here. When a given version of the game (or a level within a game)
            passes its alpha testing it is "blessed". This version now moves to
            "beta", for user-community testing. If it passes that it's "blessed"
            again, becoming a releasable.

            So these are orthogonal to milestones. An Agile project is always
            releasable. The blessing system is a pipeline leading away from the
            development arena.

            But I agree with other posters that the original poster has many more
            impediments to agility than just their release system!

            --
            Phlip
            http://www.oreilly.com/catalog/9780596510657/
            ^ assert_xpath
          Your message has been successfully submitted and would be delivered to recipients shortly.