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

How to accomodate Agile Process and an Alpha-Beta based Process ?

Expand Messages
  • thierry_cattel
    Hello, I work in a company where SW is developped along a waterfall classical process : - Gogate - Specification writting and signing - Development - QA manual
    Message 1 of 7 , Oct 1, 2007
      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
    • 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 2 of 7 , Oct 1, 2007
        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 3 of 7 , Oct 1, 2007
          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 4 of 7 , Oct 1, 2007
            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 5 of 7 , Oct 1, 2007
              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 6 of 7 , Oct 1, 2007
                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 7 of 7 , Oct 1, 2007
                  > - 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.