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

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

Expand Messages
  • Ron Jeffries
    Hello, Thierry. Given what you ve told us so far, I can t be very helpful but I ll try. On Monday, October 1, 2007, at 4:04:32 AM, you ... Iterations are time
    Message 1 of 7 , Oct 1, 2007
    • 0 Attachment
      Hello, Thierry. Given what you've told us so far, I can't be very
      helpful but I'll try. On Monday, October 1, 2007, at 4:04:32 AM, you
      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)

      Iterations are time intervals, as I understand the word. Therefore
      all time intervals prior to the Alpha will in fact be delivered.

      I'm guessing that you mean whether all features will be delivered. I
      would have to know the features and the milestone to guess at that.
      If one were actually taking an Agile approach, the answer would be
      "probably not, because you will probably change your mind based on
      what happens as we go along."

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

      The best practice I know is to find and fix the bugs created in
      iteration I inside iteration I, not in iteration I+1 or later. It is
      challenging. It is just better.

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

      It's very difficult to convince people to do something that they
      don't understand.

      I'm interested in what you are really trying to accomplish, inside
      this kind of organization. Why do you want to move in this "agile"
      direction? What problems are you hoping you'll be able to resolve?
      Understanding this may help us give you more useful advice.

      Regards,

      Ron Jeffries
      www.XProgramming.com
      War remains the decisive human failure.
      -- John Kenneth Galbraith
    • 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 2 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 3 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 4 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 5 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 6 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.