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

Re: [scrumdevelopment] Scrum releases and SCM

Expand Messages
  • Brad Appleton
    ... So, if I m understanding you correctly, you have a version of the code that is a candidate for production release. Ideally that version is perfect and
    Message 1 of 12 , Jan 7 1:27 AM
      beckfordp wrote:
      > 1. We need to regression test all the software we've 'delivered' in
      > the past to ensure it is still working. We've recently started
      > producing automated acceptance tests and most of the existing
      > code/features are only covered by unit tests. We are quickly adding
      > automated acceptance test, but prior to release much of our
      > regression testing will probably be manual.
      >
      > 2. We need to add to our existing code base as we have a release
      > scheduled for March. We are slightly concerned that ongoing work
      > could break existing code which will be in production shortly.

      So, if I'm understanding you correctly, you have a version of the code
      that is a "candidate" for production release. Ideally that version is
      "perfect" and will not need any fixes/changes prior to release.
      Practically speaking, you expect it will probably need at least some
      changes? I assume you have created a label/tag for this candidate
      release version (yes?). Let suppose it is labeled as PROD-REL_CANDIDATE.

      The "ongoing work" is (I assume) functionality for some subsequent
      release? I'll call this "FUTURE".

      Is the development of automated acceptance tests something you are doing
      for the PROD-REL_CANDIDATE or for "FUTURE"?

      > What should we do? The traditional approach is to branch the code
      > base, but I do not think this is the Agile/Scrum way.

      Right now it sounds to me like you do not yet have two simultaneously
      /active/ development changes going on. There is the effort for "FUTURE"
      and there is the effort to "production-ize" the PROD-REL_CANDIDATE. You
      don't yet know for sure that you will need to make any changes to
      PROD-REL_CANDIDATE, but you suspect it will be likely.

      Is that correct? If so, I would advice that you first ensure your
      PROD-REL_CANDIDATE has been labeled. If it has - then you may safely
      checkin ongoing work on the same codeline without "disturbing" your label.

      > Ideally we would like to continue without branching and increase our
      > automated acceptance test coverage. Is this advisable?

      As long as you have labeled your release-candidate version, I would
      definitely advise continuing without branching and increasing your
      automated test coverage. However, while doing that, you might

      Next I would see if the "ongoing work" is fairly EASY to segregate at
      the code-architecture level -- i.e. it can be localized to a limited set
      of components and a limited set of classes/methods/services, then it may
      be adviseable to spend some additional effort to be able to simply
      switch-off the code for the ongoing work using a build-time or run-time
      "switch".

      [If you're fairly disciplined about doing TDD, particularly if youre
      already using of "mock" objects/services/components, this can be pretty
      easy to do by simply "swapping in" the mocked-up no-op stuff in place of
      the enabled "ongoing work"]

      IF and WHEN you end up having to make modifications to
      PROD-REL_CANDIDATE (either because you found something in it that needs
      fixing, or because you did something in FUTURE that you want to be in
      PROD-REL_CANDIDATE) *THEN* I think you have three viable alternatives to
      choose from as follows:

      1) If you are keeping the codeline (and FUTURE work) "clean", such that
      no one commits changes to the codeline without ensuring that the result
      correctly builds and pass all the tests, THEN I would first ask the
      question:

      ==> Is it okay if the current state of "FUTURE" *plus* whatever
      fix/change you need to make, is what you ship as the new
      PROD-REL_CANDIDATE??

      If the answer is "Yes" - then you don't need to branch at all. If the
      answer is "no" then we should ask ourselves why and investigate further:

      a) there might be a technical reason. Maybe youre test-automation or
      continuous integration process is not yet at the point where you can
      maintain the codeline to be (nearly) always release-ready. If not, that
      is unfortunate and something to attempt to address ASAP.

      b) there might be a business reason for not wanting the functionality
      currently in "future" to be shippped as part of the current
      PROD-REL_CANDIDATE. It might have to do with $$$, or with the customer's
      willingness to take it. If you can persuade those folks to change their
      minds, then you don't need to branch.

      If you cant address either of those two scenarios in time (either
      maintaining constant release-readiness and/or changing peoples minds
      about scenario-b , then you need to decide if you should "halt" ongoing
      work to finish up PROD-REL_CANDIDATE before continuing with FUTURE.

      If that's a viable alternative for you, then it might be preferable to
      branching.

      If that is "not an option", then it may be necessary to *briefly* create
      a branch for the remaining release engineering/testing effort for your
      PROD-REL_CANDIDATE.

      HOWEVER, if the "ongoing work" is fairly EASY to segregate at the
      code-architecture level, then I *ALWAYS* prefer an architectural
      solution over a branching solution for managing multiple
      functional/platform variants.

      If the ongoing work is not easily segregated/localized and encapsulated
      behind interfaces, and if you would otherwise have to intersperse more
      than a handful if-elseif-else statements throughout the codebase
      (whether they are conditional compilation statements or run-time
      statements), then youre probably better off branching.

      In which case, you can *briefly* create a branch for the
      remaining release engineering/testing effort for your PROD-REL_CANDIDATE.

      The "SCM Patterns" book calls this a "Release-Prep Codeline". It is may
      be necessary when there is not (yet?) rapid-enough feedback between
      having a "release candidate version" and verifying that it is
      production-release "ready". It is a short-lived codeline that lives only
      long enough to complete this time-window.

      Anytime you make a change to the release-prep codeline, you need to
      decide if you want to also /immediately/ propagate that change back to
      the mainline, or if you want to wait until the release-prep-codeline is
      RELEASED before merging it back (for good) to the mainline. The
      shorter-lived it is, the easier it is to manage and the less worrisome
      it is.

      Making a new branch isnt necessarily so bad as long as it is done the
      right way and for the right reasons. Branches should ideally only be
      created when there is genuinely necessary concurrent/parallel
      development taking place. Branching for the primary purpose of
      maintaining multiple functional/platform variants is almost always a bad
      idea.

      If you do branch, you can apply some of the principles from Lean
      Development (and a few SCM Patterns :-) to do it right:

      * Deliver as fast as possible -- complete+commit change-tasks and
      short-lived branches (such as release-prep branches) as early as possible)

      * Decide as late as possible -- branch as late as possible! Create a
      label to take a "snapshot" of where you MIGHT have to branch off from,
      but don't actually create the branch until parallelism is needed.

      * Decide as low as possible -- developers reconcile merges and commit
      their own changes (as opposed to some "dedicated integrator/builder")

      * Optimize across the "Whole" -- when/if branches are created, use the
      Mainline pattern to maintain a "leaner" and more manageable branching
      structure

      Hope that helps!
      --
      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep" --Robert Frost
    • Paul Beckford
      Hi Brad, thanks for the response. You ve more than covered our scenario . Please see comments ... We are doing this for both. All new work will have automated
      Message 2 of 12 , Jan 7 7:49 AM
        Hi Brad,

        thanks for the response. You've more than covered our scenario . Please
        see comments
        Brad Appleton wrote:

        > beckfordp wrote:
        > > 1. We need to regression test all the software we've 'delivered' in
        > > the past to ensure it is still working. We've recently started
        > > producing automated acceptance tests and most of the existing
        > > code/features are only covered by unit tests. We are quickly adding
        > > automated acceptance test, but prior to release much of our
        > > regression testing will probably be manual.
        > >
        > > 2. We need to add to our existing code base as we have a release
        > > scheduled for March. We are slightly concerned that ongoing work
        > > could break existing code which will be in production shortly.
        >
        > So, if I'm understanding you correctly, you have a version of the code
        > that is a "candidate" for production release. Ideally that version is
        > "perfect" and will not need any fixes/changes prior to release.
        > Practically speaking, you expect it will probably need at least some
        > changes? I assume you have created a label/tag for this candidate
        > release version (yes?). Let suppose it is labeled as PROD-REL_CANDIDATE.
        >
        > The "ongoing work" is (I assume) functionality for some subsequent
        > release? I'll call this "FUTURE".
        >
        > Is the development of automated acceptance tests something you are doing
        > for the PROD-REL_CANDIDATE or for "FUTURE"?

        We are doing this for both. All new work will have automated acceptance
        tests, and we hope to write acceptance tests for all the existing code
        too. We are making good progress, but will not have full automated
        acceptance test coverage prior to going to production.

        >
        > > What should we do? The traditional approach is to branch the code
        > > base, but I do not think this is the Agile/Scrum way.
        >
        > Right now it sounds to me like you do not yet have two simultaneously
        > /active/ development changes going on. There is the effort for "FUTURE"
        > and there is the effort to "production-ize" the PROD-REL_CANDIDATE. You
        > don't yet know for sure that you will need to make any changes to
        > PROD-REL_CANDIDATE, but you suspect it will be likely.
        >
        Spot on.

        > Is that correct? If so, I would advice that you first ensure your
        > PROD-REL_CANDIDATE has been labeled. If it has - then you may safely
        > checkin ongoing work on the same codeline without "disturbing" your label.
        >
        Yes. We allways label.

        > > Ideally we would like to continue without branching and increase our
        > > automated acceptance test coverage. Is this advisable?
        >
        > As long as you have labeled your release-candidate version, I would
        > definitely advise continuing without branching and increasing your
        > automated test coverage. However, while doing that, you might
        >
        > Next I would see if the "ongoing work" is fairly EASY to segregate at
        > the code-architecture level -- i.e. it can be localized to a limited set
        > of components and a limited set of classes/methods/services, then it may
        > be adviseable to spend some additional effort to be able to simply
        > switch-off the code for the ongoing work using a build-time or run-time
        > "switch".
        >
        > [If you're fairly disciplined about doing TDD, particularly if youre
        > already using of "mock" objects/services/components, this can be pretty
        > easy to do by simply "swapping in" the mocked-up no-op stuff in place of
        > the enabled "ongoing work"]

        Yes. We mock and we use Spring IoC, so seperation as you describe is
        possible. We work very closely with our users who understand that the
        product will evolve over time. So new functionality appearing ahead of
        time isn't a problem.

        >
        > IF and WHEN you end up having to make modifications to
        > PROD-REL_CANDIDATE (either because you found something in it that needs
        > fixing, or because you did something in FUTURE that you want to be in
        > PROD-REL_CANDIDATE) *THEN* I think you have three viable alternatives to
        > choose from as follows:
        >
        > 1) If you are keeping the codeline (and FUTURE work) "clean", such that
        > no one commits changes to the codeline without ensuring that the result
        > correctly builds and pass all the tests, THEN I would first ask the
        > question:
        >
        > ==> Is it okay if the current state of "FUTURE" *plus* whatever
        > fix/change you need to make, is what you ship as the new
        > PROD-REL_CANDIDATE??
        >
        Yes

        > If the answer is "Yes" - then you don't need to branch at all. If the
        > answer is "no" then we should ask ourselves why and investigate further:
        >
        > a) there might be a technical reason. Maybe youre test-automation or
        > continuous integration process is not yet at the point where you can
        > maintain the codeline to be (nearly) always release-ready. If not, that
        > is unfortunate and something to attempt to address ASAP.
        >
        Yes, this is our concern, but we are addressing it. We can see two
        things that we can do:

        1. Manually regression test exisitng functionality. Our users are
        helping us with this as we have set up a demo server, where they can log
        on and trial the software. We also meet with our user group once a week,
        where we provide training and recieve feedback.

        2. We are writing automated acceptance tests using WATIR and Ruby. We
        intend to do lightly cover exisiting stories in our tests, and extend
        our tests as bugs are discovered. This should allow us to have the
        broadest automated test coverage in the shortest period of time.

        Any suggestions welcomed.

        > b) there might be a business reason for not wanting the functionality
        > currently in "future" to be shippped as part of the current
        > PROD-REL_CANDIDATE. It might have to do with $$$, or with the customer's
        > willingness to take it. If you can persuade those folks to change their
        > minds, then you don't need to branch.
        >
        > If you cant address either of those two scenarios in time (either
        > maintaining constant release-readiness and/or changing peoples minds
        > about scenario-b , then you need to decide if you should "halt" ongoing
        > work to finish up PROD-REL_CANDIDATE before continuing with FUTURE.
        >
        > If that's a viable alternative for you, then it might be preferable to
        > branching.
        >
        > If that is "not an option", then it may be necessary to *briefly* create
        > a branch for the remaining release engineering/testing effort for your
        > PROD-REL_CANDIDATE.
        >
        > HOWEVER, if the "ongoing work" is fairly EASY to segregate at the
        > code-architecture level, then I *ALWAYS* prefer an architectural
        > solution over a branching solution for managing multiple
        > functional/platform variants.
        >
        > If the ongoing work is not easily segregated/localized and encapsulated
        > behind interfaces, and if you would otherwise have to intersperse more
        > than a handful if-elseif-else statements throughout the codebase
        > (whether they are conditional compilation statements or run-time
        > statements), then youre probably better off branching.
        >
        > In which case, you can *briefly* create a branch for the
        > remaining release engineering/testing effort for your PROD-REL_CANDIDATE.
        >
        > The "SCM Patterns" book calls this a "Release-Prep Codeline". It is may
        > be necessary when there is not (yet?) rapid-enough feedback between
        > having a "release candidate version" and verifying that it is
        > production-release "ready". It is a short-lived codeline that lives only
        > long enough to complete this time-window.
        >
        > Anytime you make a change to the release-prep codeline, you need to
        > decide if you want to also /immediately/ propagate that change back to
        > the mainline, or if you want to wait until the release-prep-codeline is
        > RELEASED before merging it back (for good) to the mainline. The
        > shorter-lived it is, the easier it is to manage and the less worrisome
        > it is.
        >
        > Making a new branch isnt necessarily so bad as long as it is done the
        > right way and for the right reasons. Branches should ideally only be
        > created when there is genuinely necessary concurrent/parallel
        > development taking place. Branching for the primary purpose of
        > maintaining multiple functional/platform variants is almost always a bad
        > idea.
        >
        > If you do branch, you can apply some of the principles from Lean
        > Development (and a few SCM Patterns :-) to do it right:
        >
        > * Deliver as fast as possible -- complete+commit change-tasks and
        > short-lived branches (such as release-prep branches) as early as possible)
        >
        > * Decide as late as possible -- branch as late as possible! Create a
        > label to take a "snapshot" of where you MIGHT have to branch off from,
        > but don't actually create the branch until parallelism is needed.
        >
        > * Decide as low as possible -- developers reconcile merges and commit
        > their own changes (as opposed to some "dedicated integrator/builder")
        >
        > * Optimize across the "Whole" -- when/if branches are created, use the
        > Mainline pattern to maintain a "leaner" and more manageable branching
        > structure
        >
        > Hope that helps!


        This really does help. Like Ron, I'd rather not branch if we can avoid
        it. If we need to go the branch route then your notes here will be
        invaluable I'm sure.

        Thanks again,

        Paul.

        > --
        > Brad Appleton <brad@...> www.bradapp.net
        > Software CM Patterns (www.scmpatterns.com)
        > Effective Teamwork, Practical Integration
        > "And miles to go before I sleep" --Robert Frost
        >
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        >
        >
        >
        > SPONSORED LINKS
        > Scrum
        > <http://groups.yahoo.com/gads?t=ms&k=Scrum&w1=Scrum&c=1&s=11&.sig=KvDTKhw7ncC9XbB25jdApQ>
        >
        >
        >
        > ------------------------------------------------------------------------
        > YAHOO! GROUPS LINKS
        >
        > * Visit your group "scrumdevelopment
        > <http://groups.yahoo.com/group/scrumdevelopment>" on the web.
        >
        > * To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        > <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
        >
        > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        > Service <http://docs.yahoo.com/info/terms/>.
        >
        >
        > ------------------------------------------------------------------------
        >
      • George Schlitz
        Just a quick comment/plug related to this thread. Anyone involved on Scrum or Agile projects would be well-rewarded by reading Brad s book on SCM Patterns,
        Message 3 of 12 , Jan 7 12:54 PM
          Just a quick comment/plug related to this thread. Anyone involved
          on Scrum or Agile projects would be well-rewarded by reading Brad's
          book on SCM Patterns, and taking a look at the site below (which also
          appears in Brad's sig). The book
          is concise and clear, and breaks some scary SCM concepts (like the
          overly-feared merging and branching) into simple patterns...it has
          helped me as a Scrum Master make mastering basic SCM one of the first
          "enablers" for my new teams as they become more productive. Just
          another great tool.

          http://www.scmpatterns.com
        • Brad Appleton
          Many thanks George for the words of praise. I should mention that the work is a joint effort with Steve Berczuk. We also have a monthly Agile SCM column in
          Message 4 of 12 , Jan 7 6:58 PM
            Many thanks George for the words of praise. I should mention that the
            work is a joint effort with Steve Berczuk.

            We also have a monthly "Agile SCM" column in CMCrossroads' "CM Journal",
            which is freely available (unlike the book :-). I try to maintain an
            up-to-date page of links to Agile SCM articles on the CMWiki at
            <<http://www.cmcrossroads.com/cgi-bin/cmwiki/bin/view/CM/AgileSCMArticles>>
            --
            Brad Appleton <brad@...> www.bradapp.net
            Software CM Patterns (www.scmpatterns.com)
            Effective Teamwork, Practical Integration
            "And miles to go before I sleep" --Robert Frost


            George Schlitz wrote:
            > Just a quick comment/plug related to this thread. Anyone involved
            > on Scrum or Agile projects would be well-rewarded by reading Brad's
            > book on SCM Patterns, and taking a look at the site below (which also
            > appears in Brad's sig). The book
            > is concise and clear, and breaks some scary SCM concepts (like the
            > overly-feared merging and branching) into simple patterns...it has
            > helped me as a Scrum Master make mastering basic SCM one of the first
            > "enablers" for my new teams as they become more productive. Just
            > another great tool.
            >
            > http://www.scmpatterns.com
          • Brad Appleton
            Hi Paul So it sounds like there is no issue with releasing ongoing work/functionality as part of the current candidate release , but you have technical
            Message 5 of 12 , Jan 8 9:15 AM
              Hi Paul

              So it sounds like there is no issue with releasing ongoing
              work/functionality as part of the "current candidate release", but you
              have technical concerns about the reliability/stability of the ongoing
              work because you do not yet have sufficiently automated acceptance
              tests, and hence do not yet have codeline that is "releasable quality"
              at the end of any given "commit".

              You are currently working on automating acceptance tests, both for the
              ongoing work *and* for the "current release candidate" work, and you use
              TDD and mock objects and Spring IoC - which makes it feasible to
              segregate the "ongoing" work via build-time or run-time "switches" at
              the granularity of a component/class/service. Also, you work closely
              enough with your customers that receiving certain "ongoing work"
              functionality ahead of plan is not a problem for them.

              In this case, I think you can still solve this problem without having to
              create a new "Release-Prep Codeline" just yet.

              It seems the crux of your issue is the lag-time between your "latest
              trustworthy build" and the "tip" of your codeline. In agile development,
              we ideally want them to be the same, but in your case (and many others)
              the latest trustworthy build is not the latest "configuration" of the
              codeline.

              This is often handled by keeping track of what is commonly called a
              "floating label" or a "floating tag" for the "current" release-candidate
              (some use the label LAST_GOOD_BUILD or CURRENT_REL_CANDIDATE, the name
              doesnt matter as long as its understood by all). Normally, the "tip" of
              the codeline acts as a "floating" marker or reference to the latest
              state of the code. In this case, you still want that floating
              marker.reference, it just cant point to the latest state of the code.

              So a lot of folks actually track an additional label/tag. Whenever they
              have a version of the code that is "trustworthy" (or release-worthy),
              they not only label that version of the code, they also bump-up or
              "promote" the floating-label to refer to this newer version.

              Slides 34-35 of the PPT presentation at the following URL give a picture
              of this <<http://www.cmcrossroads.com/bradapp/acme/clearcase/ccm02.zip>>
              (NOTE, the presentation is specific to ClearCase, but most of the
              concepts and diagrams are relatively tool independent).

              I think that in your case, if you simply keep track of this
              floating-label, but still do work on the same codeline (without
              branching) you should be fine. If you like, you can maintain TWO
              integration workspaces instead of just one: one integration workspace is
              where the LATEST (tip) code is integrated; the other is where the
              current "latest trustworthy build" is tested (and possibly corrected).

              When you need to "fix" the release-worthy build, you do it in that
              workspace, and then you commit+test those changes to the workspace for
              the "tip" *WITHOUT* doing an update first (because the last trustworthy
              build needs to stay less recent than the tip).

              Depending on your version control (VC) tool, it might be inefficient to
              use an actual label/tag to implement this. Note that the "floating
              label" is really a reference to the most-recent label, and doesnt
              actually need to be a label itself.

              Most VC tools dont have the notion of a "reference to a label." Some of
              them automatically track repository-wide versions after each commit, and
              a "label" is simply a reference to that internal version-id. Subversion
              can do this, so can Accu-Rev and a few others. So creating a label is a
              fixed/constant-time operation that is extremely fast. With CVS and lost
              of other tools a label is a "tag" on each file-version that participates
              in the label, and the time it takes to label varies depending on the
              number of elements to label.

              In such cases, you can use a label anyway (even tho its inefficient - it
              may by simple and straightforward and the performance may not be a
              bottleneck for you) OR might choose to "roll your own" implementation,
              possibly by just maintaining a common "attribute" or "environment
              variable", or one-line-file for that codeline which contains the name of
              the latest-stable-version and which your build-scripts (ANT/make) know
              how to use, and which others can easily use to extract|view the latest
              stable version.

              If you use the additional integration workspace to maintain the
              latest-stable-build, perhaps just the workspace name.location is
              sufficient, and that workspace always has a one-lie-file in a known
              location corresponding to its current version (this file can even be
              autogenerated by the build scripts when they create the label).

              Hope that helps! Let me know if you have more questions!


              Paul Beckford wrote:
              > Brad Appleton wrote:
              > > So, if I'm understanding you correctly, you have a version of the code
              > > that is a "candidate" for production release. Ideally that version is
              > > "perfect" and will not need any fixes/changes prior to release.
              > > Practically speaking, you expect it will probably need at least some
              > > changes? I assume you have created a label/tag for this candidate
              > > release version (yes?). Let suppose it is labeled as PROD-REL_CANDIDATE.
              > >
              > > The "ongoing work" is (I assume) functionality for some subsequent
              > > release? I'll call this "FUTURE".
              > >
              > > Is the development of automated acceptance tests something you are doing
              > > for the PROD-REL_CANDIDATE or for "FUTURE"?
              >
              > We are doing this for both. All new work will have automated acceptance
              > tests, and we hope to write acceptance tests for all the existing code
              > too. We are making good progress, but will not have full automated
              > acceptance test coverage prior to going to production.

              [snip]

              > > Right now it sounds to me like you do not yet have two simultaneously
              > > /active/ development changes going on. There is the effort for "FUTURE"
              > > and there is the effort to "production-ize" the PROD-REL_CANDIDATE. You
              > > don't yet know for sure that you will need to make any changes to
              > > PROD-REL_CANDIDATE, but you suspect it will be likely.
              > >
              > Spot on.
              >
              > > Is that correct? If so, I would advice that you first ensure your
              > > PROD-REL_CANDIDATE has been labeled. If it has - then you may safely
              > > checkin ongoing work on the same codeline without "disturbing" your
              > label.
              > >
              > Yes. We allways label.
              >
              > > > Ideally we would like to continue without branching and increase our
              > > > automated acceptance test coverage. Is this advisable?
              > >
              > > As long as you have labeled your release-candidate version, I would
              > > definitely advise continuing without branching and increasing your
              > > automated test coverage. However, while doing that, you might
              > >
              > > Next I would see if the "ongoing work" is fairly EASY to segregate at
              > > the code-architecture level -- i.e. it can be localized to a limited set
              > > of components and a limited set of classes/methods/services, then it may
              > > be adviseable to spend some additional effort to be able to simply
              > > switch-off the code for the ongoing work using a build-time or run-time
              > > "switch".
              > >
              > > [If you're fairly disciplined about doing TDD, particularly if youre
              > > already using of "mock" objects/services/components, this can be pretty
              > > easy to do by simply "swapping in" the mocked-up no-op stuff in place of
              > > the enabled "ongoing work"]
              >
              > Yes. We mock and we use Spring IoC, so seperation as you describe is
              > possible. We work very closely with our users who understand that the
              > product will evolve over time. So new functionality appearing ahead of
              > time isn't a problem.
              >
              > >
              > > IF and WHEN you end up having to make modifications to
              > > PROD-REL_CANDIDATE (either because you found something in it that needs
              > > fixing, or because you did something in FUTURE that you want to be in
              > > PROD-REL_CANDIDATE) *THEN* I think you have three viable alternatives to
              > > choose from as follows:
              > >
              > > 1) If you are keeping the codeline (and FUTURE work) "clean", such that
              > > no one commits changes to the codeline without ensuring that the result
              > > correctly builds and pass all the tests, THEN I would first ask the
              > > question:
              > >
              > > ==> Is it okay if the current state of "FUTURE" *plus* whatever
              > > fix/change you need to make, is what you ship as the new
              > > PROD-REL_CANDIDATE??
              > >
              > Yes
              >
              > > If the answer is "Yes" - then you don't need to branch at all. If the
              > > answer is "no" then we should ask ourselves why and investigate further:
              > >
              > > a) there might be a technical reason. Maybe youre test-automation or
              > > continuous integration process is not yet at the point where you can
              > > maintain the codeline to be (nearly) always release-ready. If not, that
              > > is unfortunate and something to attempt to address ASAP.
              > >
              > Yes, this is our concern, but we are addressing it. We can see two
              > things that we can do:
              >
              > 1. Manually regression test exisitng functionality. Our users are
              > helping us with this as we have set up a demo server, where they can log
              > on and trial the software. We also meet with our user group once a week,
              > where we provide training and recieve feedback.
              >
              > 2. We are writing automated acceptance tests using WATIR and Ruby. We
              > intend to do lightly cover exisiting stories in our tests, and extend
              > our tests as bugs are discovered. This should allow us to have the
              > broadest automated test coverage in the shortest period of time.
              >
              > Any suggestions welcomed.
              >
              > > b) there might be a business reason for not wanting the functionality
              > > currently in "future" to be shippped as part of the current
              > > PROD-REL_CANDIDATE. It might have to do with $$$, or with the customer's
              > > willingness to take it. If you can persuade those folks to change their
              > > minds, then you don't need to branch.
              > >
              > > If you cant address either of those two scenarios in time (either
              > > maintaining constant release-readiness and/or changing peoples minds
              > > about scenario-b , then you need to decide if you should "halt" ongoing
              > > work to finish up PROD-REL_CANDIDATE before continuing with FUTURE.
              > >
              > > If that's a viable alternative for you, then it might be preferable to
              > > branching.
              > >
              > > If that is "not an option", then it may be necessary to *briefly* create
              > > a branch for the remaining release engineering/testing effort for your
              > > PROD-REL_CANDIDATE.
              > >
              > > HOWEVER, if the "ongoing work" is fairly EASY to segregate at the
              > > code-architecture level, then I *ALWAYS* prefer an architectural
              > > solution over a branching solution for managing multiple
              > > functional/platform variants.
              > >
              > > If the ongoing work is not easily segregated/localized and encapsulated
              > > behind interfaces, and if you would otherwise have to intersperse more
              > > than a handful if-elseif-else statements throughout the codebase
              > > (whether they are conditional compilation statements or run-time
              > > statements), then youre probably better off branching.
              > >
              > > In which case, you can *briefly* create a branch for the
              > > remaining release engineering/testing effort for your PROD-REL_CANDIDATE.
              > >
              > > The "SCM Patterns" book calls this a "Release-Prep Codeline". It is may
              > > be necessary when there is not (yet?) rapid-enough feedback between
              > > having a "release candidate version" and verifying that it is
              > > production-release "ready". It is a short-lived codeline that lives only
              > > long enough to complete this time-window.
              > >
              > > Anytime you make a change to the release-prep codeline, you need to
              > > decide if you want to also /immediately/ propagate that change back to
              > > the mainline, or if you want to wait until the release-prep-codeline is
              > > RELEASED before merging it back (for good) to the mainline. The
              > > shorter-lived it is, the easier it is to manage and the less worrisome
              > > it is.
              > >
              > > Making a new branch isnt necessarily so bad as long as it is done the
              > > right way and for the right reasons. Branches should ideally only be
              > > created when there is genuinely necessary concurrent/parallel
              > > development taking place. Branching for the primary purpose of
              > > maintaining multiple functional/platform variants is almost always a bad
              > > idea.
              > >
              > > If you do branch, you can apply some of the principles from Lean
              > > Development (and a few SCM Patterns :-) to do it right:
              > >
              > > * Deliver as fast as possible -- complete+commit change-tasks and
              > > short-lived branches (such as release-prep branches) as early as
              > possible)
              > >
              > > * Decide as late as possible -- branch as late as possible! Create a
              > > label to take a "snapshot" of where you MIGHT have to branch off from,
              > > but don't actually create the branch until parallelism is needed.
              > >
              > > * Decide as low as possible -- developers reconcile merges and commit
              > > their own changes (as opposed to some "dedicated integrator/builder")
              > >
              > > * Optimize across the "Whole" -- when/if branches are created, use the
              > > Mainline pattern to maintain a "leaner" and more manageable branching
              > > structure
              > >
              > > Hope that helps!
              >
              >
              > This really does help. Like Ron, I'd rather not branch if we can avoid
              > it. If we need to go the branch route then your notes here will be
              > invaluable I'm sure.
              >
              > Thanks again,


              --
              Brad Appleton <brad@...> www.bradapp.net
              Software CM Patterns (www.scmpatterns.com)
              Effective Teamwork, Practical Integration
              "And miles to go before I sleep" --Robert Frost
            • beckfordp
              ... use ... having to ... development, ... release-candidate ... picture ... I like the sound of a floating-label . Mentioned it at our standup today and
              Message 6 of 12 , Jan 10 5:55 AM
                --- In scrumdevelopment@yahoogroups.com, Brad Appleton <bradpro@b...>
                wrote:
                >
                > Hi Paul
                >
                > So it sounds like there is no issue with releasing ongoing
                > work/functionality as part of the "current candidate release", but you
                > have technical concerns about the reliability/stability of the ongoing
                > work because you do not yet have sufficiently automated acceptance
                > tests, and hence do not yet have codeline that is "releasable quality"
                > at the end of any given "commit".
                >
                > You are currently working on automating acceptance tests, both for the
                > ongoing work *and* for the "current release candidate" work, and you
                use
                > TDD and mock objects and Spring IoC - which makes it feasible to
                > segregate the "ongoing" work via build-time or run-time "switches" at
                > the granularity of a component/class/service. Also, you work closely
                > enough with your customers that receiving certain "ongoing work"
                > functionality ahead of plan is not a problem for them.
                >
                > In this case, I think you can still solve this problem without
                having to
                > create a new "Release-Prep Codeline" just yet.
                >
                > It seems the crux of your issue is the lag-time between your "latest
                > trustworthy build" and the "tip" of your codeline. In agile
                development,
                > we ideally want them to be the same, but in your case (and many others)
                > the latest trustworthy build is not the latest "configuration" of the
                > codeline.
                >
                > This is often handled by keeping track of what is commonly called a
                > "floating label" or a "floating tag" for the "current"
                release-candidate
                > (some use the label LAST_GOOD_BUILD or CURRENT_REL_CANDIDATE, the name
                > doesnt matter as long as its understood by all). Normally, the "tip" of
                > the codeline acts as a "floating" marker or reference to the latest
                > state of the code. In this case, you still want that floating
                > marker.reference, it just cant point to the latest state of the code.
                >
                > So a lot of folks actually track an additional label/tag. Whenever they
                > have a version of the code that is "trustworthy" (or release-worthy),
                > they not only label that version of the code, they also bump-up or
                > "promote" the floating-label to refer to this newer version.
                >
                > Slides 34-35 of the PPT presentation at the following URL give a
                picture
                > of this <<http://www.cmcrossroads.com/bradapp/acme/clearcase/ccm02.zip>>
                > (NOTE, the presentation is specific to ClearCase, but most of the
                > concepts and diagrams are relatively tool independent).
                >
                I like the sound of a "floating-label". Mentioned it at our standup
                today and everyone liked it too.
                > I think that in your case, if you simply keep track of this
                > floating-label, but still do work on the same codeline (without
                > branching) you should be fine. If you like, you can maintain TWO
                > integration workspaces instead of just one: one integration
                workspace is
                > where the LATEST (tip) code is integrated; the other is where the
                > current "latest trustworthy build" is tested (and possibly corrected).
                >
                Not sure what this will give us. I guess it will allow us to make
                small bug fixes to the release. Sort of like a branch?
                > When you need to "fix" the release-worthy build, you do it in that
                > workspace, and then you commit+test those changes to the workspace for
                > the "tip" *WITHOUT* doing an update first (because the last trustworthy
                > build needs to stay less recent than the tip).
                >
                > Depending on your version control (VC) tool, it might be inefficient to
                > use an actual label/tag to implement this. Note that the "floating
                > label" is really a reference to the most-recent label, and doesnt
                > actually need to be a label itself.
                >
                > Most VC tools dont have the notion of a "reference to a label."
                Some of
                > them automatically track repository-wide versions after each commit,
                and
                > a "label" is simply a reference to that internal version-id. Subversion
                > can do this, so can Accu-Rev and a few others. So creating a label is a
                We are using CVS. So yes brute force tags. Like the sound of
                Subversion though - will try and use it next time :^)
                > fixed/constant-time operation that is extremely fast. With CVS and lost
                > of other tools a label is a "tag" on each file-version that
                participates
                > in the label, and the time it takes to label varies depending on the
                > number of elements to label.
                >
                > In such cases, you can use a label anyway (even tho its inefficient
                - it
                > may by simple and straightforward and the performance may not be a
                > bottleneck for you) OR might choose to "roll your own" implementation,
                > possibly by just maintaining a common "attribute" or "environment
                > variable", or one-line-file for that codeline which contains the
                name of
                > the latest-stable-version and which your build-scripts (ANT/make) know
                > how to use, and which others can easily use to extract|view the latest
                > stable version.
                >
                > If you use the additional integration workspace to maintain the
                > latest-stable-build, perhaps just the workspace name.location is
                > sufficient, and that workspace always has a one-lie-file in a known
                > location corresponding to its current version (this file can even be
                > autogenerated by the build scripts when they create the label).
                >
                We are trying to stick with "the simplest thing that will work". So no
                branches, no addtional integration workspace. Having said this it is
                nice to have options should we need to move to the next most simplest
                thing!
                > Hope that helps! Let me know if you have more questions!
                >
                Yes this does help. It is nice to have a set of "tried and tested"
                approaches to this stuff instead of having to roll our own each time.
                Thanks for the input. We are having a planning meeting today and the
                users are back in tomorrow.

                I will keep you updated on what we decide, and how we get on over the
                next few weeks.

                All the best and thanks for all the advice.

                Paul.
                >
                > Paul Beckford wrote:
                > > Brad Appleton wrote:
                > > > So, if I'm understanding you correctly, you have a version of
                the code
                > > > that is a "candidate" for production release. Ideally that
                version is
                > > > "perfect" and will not need any fixes/changes prior to release.
                > > > Practically speaking, you expect it will probably need at least
                some
                > > > changes? I assume you have created a label/tag for this candidate
                > > > release version (yes?). Let suppose it is labeled as
                PROD-REL_CANDIDATE.
                > > >
                > > > The "ongoing work" is (I assume) functionality for some subsequent
                > > > release? I'll call this "FUTURE".
                > > >
                > > > Is the development of automated acceptance tests something you
                are doing
                > > > for the PROD-REL_CANDIDATE or for "FUTURE"?
                > >
                > > We are doing this for both. All new work will have automated
                acceptance
                > > tests, and we hope to write acceptance tests for all the existing code
                > > too. We are making good progress, but will not have full automated
                > > acceptance test coverage prior to going to production.
                >
                > [snip]
                >
                > > > Right now it sounds to me like you do not yet have two
                simultaneously
                > > > /active/ development changes going on. There is the effort for
                "FUTURE"
                > > > and there is the effort to "production-ize" the
                PROD-REL_CANDIDATE. You
                > > > don't yet know for sure that you will need to make any changes to
                > > > PROD-REL_CANDIDATE, but you suspect it will be likely.
                > > >
                > > Spot on.
                > >
                > > > Is that correct? If so, I would advice that you first ensure your
                > > > PROD-REL_CANDIDATE has been labeled. If it has - then you may
                safely
                > > > checkin ongoing work on the same codeline without "disturbing"
                your
                > > label.
                > > >
                > > Yes. We allways label.
                > >
                > > > > Ideally we would like to continue without branching and
                increase our
                > > > > automated acceptance test coverage. Is this advisable?
                > > >
                > > > As long as you have labeled your release-candidate version, I would
                > > > definitely advise continuing without branching and increasing your
                > > > automated test coverage. However, while doing that, you might
                > > >
                > > > Next I would see if the "ongoing work" is fairly EASY to
                segregate at
                > > > the code-architecture level -- i.e. it can be localized to a
                limited set
                > > > of components and a limited set of classes/methods/services,
                then it may
                > > > be adviseable to spend some additional effort to be able to simply
                > > > switch-off the code for the ongoing work using a build-time or
                run-time
                > > > "switch".
                > > >
                > > > [If you're fairly disciplined about doing TDD, particularly if
                youre
                > > > already using of "mock" objects/services/components, this can
                be pretty
                > > > easy to do by simply "swapping in" the mocked-up no-op stuff in
                place of
                > > > the enabled "ongoing work"]
                > >
                > > Yes. We mock and we use Spring IoC, so seperation as you describe is
                > > possible. We work very closely with our users who understand that the
                > > product will evolve over time. So new functionality appearing ahead of
                > > time isn't a problem.
                > >
                > > >
                > > > IF and WHEN you end up having to make modifications to
                > > > PROD-REL_CANDIDATE (either because you found something in it
                that needs
                > > > fixing, or because you did something in FUTURE that you want to
                be in
                > > > PROD-REL_CANDIDATE) *THEN* I think you have three viable
                alternatives to
                > > > choose from as follows:
                > > >
                > > > 1) If you are keeping the codeline (and FUTURE work) "clean",
                such that
                > > > no one commits changes to the codeline without ensuring that
                the result
                > > > correctly builds and pass all the tests, THEN I would first ask the
                > > > question:
                > > >
                > > > ==> Is it okay if the current state of "FUTURE" *plus* whatever
                > > > fix/change you need to make, is what you ship as the new
                > > > PROD-REL_CANDIDATE??
                > > >
                > > Yes
                > >
                > > > If the answer is "Yes" - then you don't need to branch at all.
                If the
                > > > answer is "no" then we should ask ourselves why and investigate
                further:
                > > >
                > > > a) there might be a technical reason. Maybe youre
                test-automation or
                > > > continuous integration process is not yet at the point where
                you can
                > > > maintain the codeline to be (nearly) always release-ready. If
                not, that
                > > > is unfortunate and something to attempt to address ASAP.
                > > >
                > > Yes, this is our concern, but we are addressing it. We can see two
                > > things that we can do:
                > >
                > > 1. Manually regression test exisitng functionality. Our users are
                > > helping us with this as we have set up a demo server, where they
                can log
                > > on and trial the software. We also meet with our user group once a
                week,
                > > where we provide training and recieve feedback.
                > >
                > > 2. We are writing automated acceptance tests using WATIR and Ruby. We
                > > intend to do lightly cover exisiting stories in our tests, and extend
                > > our tests as bugs are discovered. This should allow us to have the
                > > broadest automated test coverage in the shortest period of time.
                > >
                > > Any suggestions welcomed.
                > >
                > > > b) there might be a business reason for not wanting the
                functionality
                > > > currently in "future" to be shippped as part of the current
                > > > PROD-REL_CANDIDATE. It might have to do with $$$, or with the
                customer's
                > > > willingness to take it. If you can persuade those folks to
                change their
                > > > minds, then you don't need to branch.
                > > >
                > > > If you cant address either of those two scenarios in time (either
                > > > maintaining constant release-readiness and/or changing peoples
                minds
                > > > about scenario-b , then you need to decide if you should "halt"
                ongoing
                > > > work to finish up PROD-REL_CANDIDATE before continuing with FUTURE.
                > > >
                > > > If that's a viable alternative for you, then it might be
                preferable to
                > > > branching.
                > > >
                > > > If that is "not an option", then it may be necessary to
                *briefly* create
                > > > a branch for the remaining release engineering/testing effort
                for your
                > > > PROD-REL_CANDIDATE.
                > > >
                > > > HOWEVER, if the "ongoing work" is fairly EASY to segregate at the
                > > > code-architecture level, then I *ALWAYS* prefer an architectural
                > > > solution over a branching solution for managing multiple
                > > > functional/platform variants.
                > > >
                > > > If the ongoing work is not easily segregated/localized and
                encapsulated
                > > > behind interfaces, and if you would otherwise have to
                intersperse more
                > > > than a handful if-elseif-else statements throughout the codebase
                > > > (whether they are conditional compilation statements or run-time
                > > > statements), then youre probably better off branching.
                > > >
                > > > In which case, you can *briefly* create a branch for the
                > > > remaining release engineering/testing effort for your
                PROD-REL_CANDIDATE.
                > > >
                > > > The "SCM Patterns" book calls this a "Release-Prep Codeline".
                It is may
                > > > be necessary when there is not (yet?) rapid-enough feedback between
                > > > having a "release candidate version" and verifying that it is
                > > > production-release "ready". It is a short-lived codeline that
                lives only
                > > > long enough to complete this time-window.
                > > >
                > > > Anytime you make a change to the release-prep codeline, you need to
                > > > decide if you want to also /immediately/ propagate that change
                back to
                > > > the mainline, or if you want to wait until the
                release-prep-codeline is
                > > > RELEASED before merging it back (for good) to the mainline. The
                > > > shorter-lived it is, the easier it is to manage and the less
                worrisome
                > > > it is.
                > > >
                > > > Making a new branch isnt necessarily so bad as long as it is
                done the
                > > > right way and for the right reasons. Branches should ideally
                only be
                > > > created when there is genuinely necessary concurrent/parallel
                > > > development taking place. Branching for the primary purpose of
                > > > maintaining multiple functional/platform variants is almost
                always a bad
                > > > idea.
                > > >
                > > > If you do branch, you can apply some of the principles from Lean
                > > > Development (and a few SCM Patterns :-) to do it right:
                > > >
                > > > * Deliver as fast as possible -- complete+commit change-tasks and
                > > > short-lived branches (such as release-prep branches) as early as
                > > possible)
                > > >
                > > > * Decide as late as possible -- branch as late as possible!
                Create a
                > > > label to take a "snapshot" of where you MIGHT have to branch
                off from,
                > > > but don't actually create the branch until parallelism is needed.
                > > >
                > > > * Decide as low as possible -- developers reconcile merges and
                commit
                > > > their own changes (as opposed to some "dedicated
                integrator/builder")
                > > >
                > > > * Optimize across the "Whole" -- when/if branches are created,
                use the
                > > > Mainline pattern to maintain a "leaner" and more manageable
                branching
                > > > structure
                > > >
                > > > Hope that helps!
                > >
                > >
                > > This really does help. Like Ron, I'd rather not branch if we can
                avoid
                > > it. If we need to go the branch route then your notes here will be
                > > invaluable I'm sure.
                > >
                > > Thanks again,
                >
                >
                > --
                > Brad Appleton <brad@b...> www.bradapp.net
                > Software CM Patterns (www.scmpatterns.com)
                > Effective Teamwork, Practical Integration
                > "And miles to go before I sleep" --Robert Frost
                >
              • Brad Appleton
                ... [snip] ... That is good to hear! ... Exactly! You are essentially treating the floating label workspace as an isolated task/story by itself. It get s its
                Message 7 of 12 , Jan 10 9:15 AM
                  beckfordp wrote:
                  > --- Brad Appleton <bradpro@b...> wrote:
                  > > This is often handled by keeping track of what is commonly called a
                  > > "floating label" or a "floating tag" for the "current" release-candidate
                  [snip]
                  > > Slides 34-35 of the PPT presentation at the following URL give a picture
                  > > of this <<http://www.cmcrossroads.com/bradapp/acme/clearcase/ccm02.zip>>
                  > > (NOTE, the presentation is specific to ClearCase, but most of the
                  > > concepts and diagrams are relatively tool independent).
                  > >
                  >
                  > I like the sound of a "floating-label". Mentioned it at our standup
                  > today and everyone liked it too.

                  That is good to hear!

                  > > I think that in your case, if you simply keep track of this
                  > > floating-label, but still do work on the same codeline (without
                  > > branching) you should be fine. If you like, you can maintain TWO
                  > > integration workspaces instead of just one: one integration workspace
                  > > is where the LATEST (tip) code is integrated; the other is where the
                  > > current "latest trustworthy build" is tested (and possibly corrected).
                  > >
                  > Not sure what this will give us. I guess it will allow us to make
                  > small bug fixes to the release. Sort of like a branch?

                  Exactly! You are essentially treating the "floating label" workspace as
                  an isolated task/story by itself. It get's its own "Private Workspace"
                  and, if it's relatively short-lived or has very few changes, then
                  perhaps a corresponding "Task Branch" is unnecessary. If it has to be
                  longer-lived, the "task branch" for it becomes your "release-prep
                  codeline". (Note that if you are using Subversion, then since workspaces
                  and branches are both "Copies" there is no difference :-)


                  > We are trying to stick with "the simplest thing that will work". So no
                  > branches, no addtional integration workspace. Having said this it is
                  > nice to have options should we need to move to the next most simplest
                  > thing!
                  [snip]
                  > I will keep you updated on what we decide, and how we get on over the
                  > next few weeks.

                  Thanks! Im looking forward to seeing how it works out!
                  --
                  Brad Appleton <brad@...> www.bradapp.net
                  Software CM Patterns (www.scmpatterns.com)
                  Effective Teamwork, Practical Integration
                  "And miles to go before I sleep" --Robert Frost
                • Brad Appleton
                  Oops - I almost forgot ... ... Keep in mind that in order to do your testing against your current candidate you will have to have some integration
                  Message 8 of 12 , Jan 10 9:44 AM
                    Oops - I almost forgot ...

                    beckfordp wrote:
                    > We are trying to stick with "the simplest thing that will work". So no
                    > branches, no additional integration workspace.

                    Keep in mind that in order to do your testing against your "current
                    candidate" you will have to have some integration staging/testing
                    environment somewhere to hold the executables and libraries, and
                    possibly source-code. If it holds any source-code (even if just to
                    properly build+stage the rest of the environment), it's really just
                    another kind of workspace.

                    So it's quite probably youre already creating this workspace anyway, but
                    referring to it by another name (like a "staging area" or "test
                    environment").

                    The big question is, if you find something wrong that needs fixing for
                    the release-candidate, what do you intend to do?
                    * do you intend to fix it on the codeline, and then include *both* the
                    fix *and* the ongoing-work in your updated release candidate?

                    * or do you intend to include *only* the fix in your updated release
                    candidate?

                    If the answer is the former, then you probably do not need the separate
                    "candidate fixing" workspace (or branch). If the answer is the latter,
                    then you probably do need it.

                    Cheers!
                  • Paul Beckford
                    ... Good point. We do need a testing/staging area of some sort. At the moment this is the workspace of the person who builds the release. We should really move
                    Message 9 of 12 , Jan 10 10:24 AM
                      Brad Appleton wrote:

                      > Oops - I almost forgot ...
                      >
                      > beckfordp wrote:
                      > > We are trying to stick with "the simplest thing that will work". So no
                      > > branches, no additional integration workspace.
                      >
                      > Keep in mind that in order to do your testing against your "current
                      > candidate" you will have to have some integration staging/testing
                      > environment somewhere to hold the executables and libraries, and
                      > possibly source-code. If it holds any source-code (even if just to
                      > properly build+stage the rest of the environment), it's really just
                      > another kind of workspace.
                      >
                      > So it's quite probably youre already creating this workspace anyway, but
                      > referring to it by another name (like a "staging area" or "test
                      > environment").

                      Good point. We do need a testing/staging area of some sort. At the
                      moment this is the workspace of the person who builds the release. We
                      should really move it somewhere else. We've got a PC where we will run
                      all our automated acceptance tests. This sounds like a good place. I'll
                      mention it to the others.

                      Paul.

                      >
                      > The big question is, if you find something wrong that needs fixing for
                      > the release-candidate, what do you intend to do?
                      > * do you intend to fix it on the codeline, and then include *both* the
                      > fix *and* the ongoing-work in your updated release candidate?
                      >
                      > * or do you intend to include *only* the fix in your updated release
                      > candidate?
                      >
                      > If the answer is the former, then you probably do not need the separate
                      > "candidate fixing" workspace (or branch). If the answer is the latter,
                      > then you probably do need it.
                      >
                      > Cheers!
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to:
                      > scrumdevelopment-unsubscribe@...
                      >
                      >
                      > ------------------------------------------------------------------------
                      > YAHOO! GROUPS LINKS
                      >
                      > * Visit your group "scrumdevelopment
                      > <http://groups.yahoo.com/group/scrumdevelopment>" on the web.
                      >
                      > * To unsubscribe from this group, send an email to:
                      > scrumdevelopment-unsubscribe@yahoogroups.com
                      > <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                      >
                      > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                      > Service <http://docs.yahoo.com/info/terms/>.
                      >
                      >
                      > ------------------------------------------------------------------------
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.