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

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

Expand Messages
  • Adrian Howard
    Hi, ... I would expect an agile team to have something of release candidate / gold master quality at the end of each iteration. Each iteration would be adding
    Message 1 of 7 , Oct 1, 2007
    • 0 Attachment
      Hi,

      On 1 Oct 2007, at 09:04, 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...

      I would expect an agile team to have something of release candidate /
      gold master quality at the end of each iteration. Each iteration
      would be adding more release-quality features.

      The businesses decision is then when you have enough features to
      release to the world at large. For some kinds of business this might
      be every iteration.

      > 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 ?

      Well - you can't really accomodate both views :-)

      The waterfall style you outlined is based on the idea that scope is
      mostly fixed (probably with a hideously complex change control
      process / contract negotiation fight to deal with the exceptions).
      Nothing available for use until the "big bang" at the end.

      Agile approaches are based around incrementally delivering small bits
      of business value all of the time.

      Two approaches I've seen to this dichotomy are (in increasing
      likelihood of failure).

      1) Dumping the waterfall. Educate the folk involved with the
      advantages of a more incremental approach and dump the "big bang"
      implementation/release strategy.

      2) Weak waterfall facade: When you have a Customer and Developers who
      can work together as an agile team - just run an agile project. When
      the Customer is happy they deliver the final result out into the
      Alpha/Beta/RC/Gold cycle. Rest of the company looks slightly confused
      when this latter process takes pretty much zero time as there are no/
      few bugs. Can involve considerable overhead if you have to fake
      things like change-control docs.

      3) When you don't have a Customer and Developers together as an agile
      team you can't really run an agile project. You can make things
      slightly better by following the agile development practices that can
      work without Customer engagement, but you're only slightly less
      doomed than straight waterfall, in my experience.

      Really this all depends on what you and your organisation is
      expecting to get out of agile - and what the attitude of the
      development team is. Without a Customer and a development team that
      _want_ to go the agile route things are likely to go badly...

      Adrian
    • 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 2 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 3 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 4 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 5 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.