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

Experiment on size of unit of work - how low can you go?

Expand Messages
  • John Carter
    First, a thought experiment. Traditionally a feature was the unit of work to be planned, created, integrated and tested. As we became more agile we broke
    Message 1 of 10 , Jan 9, 2013
    • 0 Attachment
      First, a thought experiment.

      Traditionally a "feature" was the unit of work to be planned, created,
      integrated and tested.

      As we became more agile we broke these units of planning, creation and
      test, and integration into smaller and smaller chunks...

      Question: How small can I go?

      What if I designed my efforts, from planning, to test, to creation, to
      integration, to documentation, to pushed, done and dusted to _all_ be The
      Smallest Change that will provably not break anything?

      How small can that go?

      So my experiment for the next month or so...

      Can I break _everything_ I do down to "smaller than a work day" from plan,
      to test, to work done and documented, to pushed done and dusted to
      repository?

      By "done and dusted" I mean if I forgot, died, or went on to something
      else... whatever I did could remain unchanged within the code base without
      detriment, and preferable with benefit, to the customer.


      --
      John Carter Phone : (64)(3) 358 6639
      Tait Electronics Fax : (64)(3) 359 4632
      PO Box 1645 Christchurch Email : john.carter@...
      New Zealand

      --

      ------------------------------
      This email, including any attachments, is only for the intended recipient.
      It is subject to copyright, is confidential and may be the subject of legal
      or other privilege, none of which is waived or lost by reason of this
      transmission.
      If you are not an intended recipient, you may not use, disseminate,
      distribute or reproduce such email, any attachments, or any part thereof.
      If you have received a message in error, please notify the sender
      immediately and erase all copies of the message and any attachments.
      Unfortunately, we cannot warrant that the email has not been altered or
      corrupted during transmission nor can we guarantee that any email or any
      attachments are free from computer viruses or other conditions which may
      damage or interfere with recipient data, hardware or software. The
      recipient relies upon its own procedures and assumes all risk of use and of
      opening any attachments.
      ------------------------------


      [Non-text portions of this message have been removed]
    • Ron Jeffries
      Hi John ... Interesting experiment. My guess is, you almost always can, and you ll come to believe that when you cannot, it s about you, not about the problem.
      Message 2 of 10 , Jan 10, 2013
      • 0 Attachment
        Hi John

        On Jan 9, 2013, at 10:27 PM, John Carter <john.carter@...> wrote:

        > Can I break _everything_ I do down to "smaller than a work day" from plan,
        > to test, to work done and documented, to pushed done and dusted to
        > repository?
        >
        > By "done and dusted" I mean if I forgot, died, or went on to something
        > else... whatever I did could remain unchanged within the code base without
        > detriment, and preferable with benefit, to the customer.


        Interesting experiment. My guess is, you almost always can, and you'll come to believe that when you cannot, it's about you, not about the problem. Keep us posted please.

        Ron Jeffries
        www.XProgramming.com
        I know we always like to say it'll be easier to do it now than it
        will be to do it later. Not likely. I plan to be smarter later than
        I am now, so I think it'll be just as easy later, maybe even easier.
        Why pay now when we can pay later?



        [Non-text portions of this message have been removed]
      • Steven Gordon
        Hi John, I believe your idea would work well once there is some accepted, working software. However, I do not see how to get started from scratch. Would you
        Message 3 of 10 , Jan 10, 2013
        • 0 Attachment
          Hi John,

          I believe your idea would work well once there is some accepted, working
          software.

          However, I do not see how to get started from scratch. Would you start by
          making a series of changes that went from nothing working to nothing
          working until you magically got to something to deliver?

          On Wed, Jan 9, 2013 at 8:27 PM, John Carter <john.carter@...> wrote:

          > **
          >
          >
          > First, a thought experiment.
          >
          > Traditionally a "feature" was the unit of work to be planned, created,
          > integrated and tested.
          >
          > As we became more agile we broke these units of planning, creation and
          > test, and integration into smaller and smaller chunks...
          >
          > Question: How small can I go?
          >
          > What if I designed my efforts, from planning, to test, to creation, to
          > integration, to documentation, to pushed, done and dusted to _all_ be The
          > Smallest Change that will provably not break anything?
          >
          > How small can that go?
          >
          > So my experiment for the next month or so...
          >
          > Can I break _everything_ I do down to "smaller than a work day" from plan,
          > to test, to work done and documented, to pushed done and dusted to
          > repository?
          >
          > By "done and dusted" I mean if I forgot, died, or went on to something
          > else... whatever I did could remain unchanged within the code base without
          > detriment, and preferable with benefit, to the customer.
          >
          > --
          > John Carter Phone : (64)(3) 358 6639
          > Tait Electronics Fax : (64)(3) 359 4632
          > PO Box 1645 Christchurch Email : john.carter@...
          > New Zealand
          >
          >


          [Non-text portions of this message have been removed]
        • George Dinwiddie
          Steven, ... I ve done this, myself. It still takes awhile for the stories to add up to something releasable, but I ve been able to start from nothing and work
          Message 4 of 10 , Jan 10, 2013
          • 0 Attachment
            Steven,

            On 1/10/13 10:55 AM, Steven Gordon wrote:
            > Hi John,
            >
            > I believe your idea would work well once there is some accepted, working
            > software.
            >
            > However, I do not see how to get started from scratch. Would you start by
            > making a series of changes that went from nothing working to nothing
            > working until you magically got to something to deliver?

            I've done this, myself. It still takes awhile for the stories to add up
            to something releasable, but I've been able to start from nothing and
            work in tiny steps. It does take practice.

            - George

            >
            > On Wed, Jan 9, 2013 at 8:27 PM, John Carter <john.carter@...> wrote:
            >
            >> **
            >>
            >>
            >> First, a thought experiment.
            >>
            >> Traditionally a "feature" was the unit of work to be planned, created,
            >> integrated and tested.
            >>
            >> As we became more agile we broke these units of planning, creation and
            >> test, and integration into smaller and smaller chunks...
            >>
            >> Question: How small can I go?
            >>
            >> What if I designed my efforts, from planning, to test, to creation, to
            >> integration, to documentation, to pushed, done and dusted to _all_ be The
            >> Smallest Change that will provably not break anything?
            >>
            >> How small can that go?
            >>
            >> So my experiment for the next month or so...
            >>
            >> Can I break _everything_ I do down to "smaller than a work day" from plan,
            >> to test, to work done and documented, to pushed done and dusted to
            >> repository?
            >>
            >> By "done and dusted" I mean if I forgot, died, or went on to something
            >> else... whatever I did could remain unchanged within the code base without
            >> detriment, and preferable with benefit, to the customer.

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Charlie Poole
            As you go smaller and smaller, don t you reach the point where it s no longer a story? That is, no longer viewed as having value by the customer? I think we
            Message 5 of 10 , Jan 10, 2013
            • 0 Attachment
              As you go smaller and smaller, don't you reach the point where it's no
              longer a story? That is, no longer viewed as having value by the customer?

              I think we have to keep the distinction between units of work (tasks?) and
              stories clear in our minds. Clearly, we often have to do a lot of things
              that are not viewed as valuable by the customer in order to make some thing
              that is of value. The trick is to minimize how much effort we put into such
              things and move toward value as quickly as we can.

              One way I've found of going smaller is to work with the Customer to expand
              what is seen as having value. So, for example, the Customer may grow to see
              value in seeing that certain high-risk tasks are done successfully, because
              it increases the probability of project success, even if the results are
              not releasable. But we can't just go ahead and make that judgement
              ourselves - it's a key insight of XP that the Customer is the definer of
              value and I wouldn't want to forget that.

              Charlie


              On Thu, Jan 10, 2013 at 8:41 AM, George Dinwiddie
              <lists@...>wrote:

              > **
              >
              >
              > Steven,
              >
              > On 1/10/13 10:55 AM, Steven Gordon wrote:
              > > Hi John,
              > >
              > > I believe your idea would work well once there is some accepted, working
              > > software.
              > >
              > > However, I do not see how to get started from scratch. Would you start by
              > > making a series of changes that went from nothing working to nothing
              > > working until you magically got to something to deliver?
              >
              > I've done this, myself. It still takes awhile for the stories to add up
              > to something releasable, but I've been able to start from nothing and
              > work in tiny steps. It does take practice.
              >
              > - George
              >
              > >
              > > On Wed, Jan 9, 2013 at 8:27 PM, John Carter john.carter@...>
              > wrote:
              > >
              > >> **
              > >>
              > >>
              > >> First, a thought experiment.
              > >>
              > >> Traditionally a "feature" was the unit of work to be planned, created,
              > >> integrated and tested.
              > >>
              > >> As we became more agile we broke these units of planning, creation and
              > >> test, and integration into smaller and smaller chunks...
              > >>
              > >> Question: How small can I go?
              > >>
              > >> What if I designed my efforts, from planning, to test, to creation, to
              > >> integration, to documentation, to pushed, done and dusted to _all_ be
              > The
              > >> Smallest Change that will provably not break anything?
              > >>
              > >> How small can that go?
              > >>
              > >> So my experiment for the next month or so...
              > >>
              > >> Can I break _everything_ I do down to "smaller than a work day" from
              > plan,
              > >> to test, to work done and documented, to pushed done and dusted to
              > >> repository?
              > >>
              > >> By "done and dusted" I mean if I forgot, died, or went on to something
              > >> else... whatever I did could remain unchanged within the code base
              > without
              > >> detriment, and preferable with benefit, to the customer.
              >
              > --
              > ----------------------------------------------------------
              > * George Dinwiddie * http://blog.gdinwiddie.com
              > Software Development http://www.idiacomputing.com
              > Consultant and Coach http://www.agilemaryland.org
              > ----------------------------------------------------------
              >
              >
              >


              [Non-text portions of this message have been removed]
            • George Dinwiddie
              Charlie, ... Clearly, it depends. It depends on the people involved, and how they perceive value. It also depends on the amount of overhead you have in a
              Message 6 of 10 , Jan 10, 2013
              • 0 Attachment
                Charlie,

                On 1/10/13 11:49 AM, Charlie Poole wrote:
                > As you go smaller and smaller, don't you reach the point where it's no
                > longer a story? That is, no longer viewed as having value by the customer?

                Clearly, it depends. It depends on the people involved, and how they
                perceive value. It also depends on the amount of overhead you have in a
                story. If you're collocated, and just scribbling titles on index cards,
                the overhead can be very low. If you've got a lot of people, and you're
                estimating effort on stories, then the overhead is a lot higher.

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • John Carter
                ... break, no dependencies, no legacy code... Fortunately or unfortunately, this late in the history of the industry, there is almost no green field coding
                Message 7 of 10 , Jan 10, 2013
                • 0 Attachment
                  On Fri, Jan 11, 2013 at 4:55 AM, Steven Gordon <sgordonphd@...> wrote:

                  > I believe your idea would work well once there is some accepted, working
                  > software.
                  >
                  > However, I do not see how to get started from scratch.
                  >
                  > In a sense it is easiest to do in Green Fields programming. So little to
                  break, no dependencies, no "legacy" code...

                  Fortunately or unfortunately, this late in the history of the industry,
                  there is almost no green field coding left...

                  (So why is it that Green Field coding is almost the only sort that
                  academics teach?
                  Surely they must know there is not an entry level job on the planet doing
                  that stuff?)


                  --
                  John Carter Phone : (64)(3) 358 6639
                  Tait Electronics Fax : (64)(3) 359 4632
                  PO Box 1645 Christchurch Email : john.carter@...
                  New Zealand

                  --

                  ------------------------------
                  This email, including any attachments, is only for the intended recipient.
                  It is subject to copyright, is confidential and may be the subject of legal
                  or other privilege, none of which is waived or lost by reason of this
                  transmission.
                  If you are not an intended recipient, you may not use, disseminate,
                  distribute or reproduce such email, any attachments, or any part thereof.
                  If you have received a message in error, please notify the sender
                  immediately and erase all copies of the message and any attachments.
                  Unfortunately, we cannot warrant that the email has not been altered or
                  corrupted during transmission nor can we guarantee that any email or any
                  attachments are free from computer viruses or other conditions which may
                  damage or interfere with recipient data, hardware or software. The
                  recipient relies upon its own procedures and assumes all risk of use and of
                  opening any attachments.
                  ------------------------------


                  [Non-text portions of this message have been removed]
                • John Carter
                  On Fri, Jan 11, 2013 at 5:49 AM, Charlie Poole ... It s one of the many blessings of distributed version control systems... you
                  Message 8 of 10 , Jan 10, 2013
                  • 0 Attachment
                    On Fri, Jan 11, 2013 at 5:49 AM, Charlie Poole <charliepoole@...>
                    wrote:

                    > As you go smaller and smaller, don't you reach the point where it's no
                    > longer a story? That is, no longer viewed as having value by the
                    > customer?
                    >snip<
                    >
                    > But we can't just go ahead and make that judgement
                    > ourselves - it's a key insight of XP that the Customer is the definer of
                    > value and I wouldn't want to forget that.


                    It's one of the many blessings of distributed version control systems...
                    you suddenly realize there is no real coupling between committing a
                    changeset and publishing your work to the rest of the team as "fit for
                    consumption".

                    So as soon as you realize that... you start committing all the time.

                    Every single time the write test / test fail / write code / test pass cycle
                    goes green.

                    Commit.

                    The point about version control systems is they make you brave about
                    changing things. (Because you always know _exactly_ what you changed, and
                    you can always revert it if it was A Bad Idea.)

                    Having got that insight... you suddenly start wondering what else you can
                    decouple.

                    Yup, as soon as I "push", I have declared my changes as "fit for
                    consumption by the rest of the team".

                    But I haven't declared it fit for consumption by my customer.

                    So what if I shift my "done done" point forward and decoupled that from
                    "showing it to the customer".

                    ie. The point where it is all Tested, documented, review(ed or
                    reviewable...preferably pair programmed, or if I can't do that... the diff
                    in a web base
                    collaboration tool http://www.reviewboard.org/), integrated, smoke tested,
                    pushed to central repository.

                    Sort of makes sense really... 90% of what I do to get anything to the "done
                    done" point is not really understandable by a customer. It's only when I
                    tie a whole bunch of stuff together with a vast bunch of existing stuff
                    that the customer goes "Oh cool, I needed that!".

                    I want the customer feedback ASAP... but I need (and can get) the feedback
                    from the build system, smoke test suite, other developers even faster.

                    If every changeset I push is so small "there is obviously nothing wrong
                    with it" I will be in a better state than if the answer is "there is
                    nothing obviously wrong with it".

                    The aim of the experiment is to find out whether it is feasible to decouple
                    "done done" from "get customer feedback", and what are the costs and
                    benefits.

                    I agree with you... anything that would decreasing the feedback from a
                    customer would be A Bad Thing.

                    How ever, sprint overruns happen sometimes... Priorities change. Shit
                    happens both internally and externally. Wouldn't I be in a better state if
                    I could point to a pile of "this stuff is done and dusted and I can go on
                    to other things if you really want and come back to it later, and this
                    other stuff isn't done at all." than sitting with a mouthful of teeth
                    mumbling... "Well, it's not done done yet".

                    The view of Scrum I'm starting to take is this.... "A Story is a Unit of
                    Bidding (amongst competing customer interests and values) for the Team's
                    attention."



                    --
                    John Carter Phone : (64)(3) 358 6639
                    Tait Electronics Fax : (64)(3) 359 4632
                    PO Box 1645 Christchurch Email : john.carter@...
                    New Zealand

                    --

                    ------------------------------
                    This email, including any attachments, is only for the intended recipient.
                    It is subject to copyright, is confidential and may be the subject of legal
                    or other privilege, none of which is waived or lost by reason of this
                    transmission.
                    If you are not an intended recipient, you may not use, disseminate,
                    distribute or reproduce such email, any attachments, or any part thereof.
                    If you have received a message in error, please notify the sender
                    immediately and erase all copies of the message and any attachments.
                    Unfortunately, we cannot warrant that the email has not been altered or
                    corrupted during transmission nor can we guarantee that any email or any
                    attachments are free from computer viruses or other conditions which may
                    damage or interfere with recipient data, hardware or software. The
                    recipient relies upon its own procedures and assumes all risk of use and of
                    opening any attachments.
                    ------------------------------


                    [Non-text portions of this message have been removed]
                  • Steven Gordon
                    ... Easier to do, but less clear how your proposal applies. ... There are many new Android and IPhone apps put out every day. There might be more greenfield
                    Message 9 of 10 , Jan 10, 2013
                    • 0 Attachment
                      On Thu, Jan 10, 2013 at 2:02 PM, John Carter <john.carter@...> wrote:

                      > **
                      >
                      >
                      > On Fri, Jan 11, 2013 at 4:55 AM, Steven Gordon sgordonphd@...>
                      > wrote:
                      >
                      > > I believe your idea would work well once there is some accepted, working
                      > > software.
                      > >
                      > > However, I do not see how to get started from scratch.
                      > >
                      > > In a sense it is easiest to do in Green Fields programming. So little to
                      > break, no dependencies, no "legacy" code...
                      >

                      Easier to do, but less clear how your proposal applies.


                      >
                      > Fortunately or unfortunately, this late in the history of the industry,
                      > there is almost no green field coding left...
                      >

                      There are many new Android and IPhone apps put out every day. There might
                      be more greenfield projects today than ever before, but most of them are
                      tiny.


                      >
                      > (So why is it that Green Field coding is almost the only sort that
                      > academics teach?
                      > Surely they must know there is not an entry level job on the planet doing
                      > that stuff?)
                      >

                      You won't get me to defend what academia teaches. I left academia for what
                      it teaches, as well as how research and the university mission has
                      evolved.


                      >
                      > --
                      > John Carter Phone : (64)(3) 358 6639
                      > Tait Electronics Fax : (64)(3) 359 4632
                      > PO Box 1645 Christchurch Email : john.carter@...
                      > New Zealand
                      >
                      > --
                      >
                      > ------------------------------
                      > This email, including any attachments, is only for the intended recipient.
                      > It is subject to copyright, is confidential and may be the subject of
                      > legal
                      > or other privilege, none of which is waived or lost by reason of this
                      > transmission.
                      > If you are not an intended recipient, you may not use, disseminate,
                      > distribute or reproduce such email, any attachments, or any part thereof.
                      > If you have received a message in error, please notify the sender
                      > immediately and erase all copies of the message and any attachments.
                      > Unfortunately, we cannot warrant that the email has not been altered or
                      > corrupted during transmission nor can we guarantee that any email or any
                      > attachments are free from computer viruses or other conditions which may
                      > damage or interfere with recipient data, hardware or software. The
                      > recipient relies upon its own procedures and assumes all risk of use and
                      > of
                      > opening any attachments.
                      > ------------------------------
                      >
                      > [Non-text portions of this message have been removed]
                      >
                      >
                      >


                      [Non-text portions of this message have been removed]
                    • Charlie Poole
                      ... might imagine. Even centralized VCSs used to let you do that - although with much more work - by use of what some call promotion. ... Yes, I definitely
                      Message 10 of 10 , Jan 10, 2013
                      • 0 Attachment
                        On Thu, Jan 10, 2013 at 1:29 PM, John Carter <john.carter@...> wrote:

                        > **
                        >
                        >
                        > On Fri, Jan 11, 2013 at 5:49 AM, Charlie Poole charliepoole@...>
                        > wrote:
                        >
                        > > As you go smaller and smaller, don't you reach the point where it's no
                        > > longer a story? That is, no longer viewed as having value by the
                        > > customer?
                        > >snip<
                        > >
                        > > But we can't just go ahead and make that judgement
                        > > ourselves - it's a key insight of XP that the Customer is the definer of
                        > > value and I wouldn't want to forget that.
                        >
                        > It's one of the many blessings of distributed version control systems...
                        > you suddenly realize there is no real coupling between committing a
                        > changeset and publishing your work to the rest of the team as "fit for
                        > consumption".
                        >
                        > Indeed, although that notion isn't as strongly coupled to DVCSs as one
                        might imagine. Even centralized VCSs used to let you do that - although
                        with much more work - by use of what some call "promotion."

                        > So as soon as you realize that... you start committing all the time.
                        >
                        > Every single time the write test / test fail / write code / test pass cycle
                        > goes green.
                        >
                        > Commit.
                        >
                        Yes, I definitely do that locally. Makes it much easier to go back than
                        pushing ctrl-Z 500 times.

                        >
                        > The point about version control systems is they make you brave about
                        > changing things. (Because you always know _exactly_ what you changed, and
                        > you can always revert it if it was A Bad Idea.)
                        >
                        > Before distributed version control, I used to advocate just deleting your
                        changes.
                        Braveness in deleting code is an important value for agile programmers.
                        Version control gives you a better way to keep track of how far back you
                        need to erase.

                        > Having got that insight... you suddenly start wondering what else you can
                        > decouple.
                        >
                        > Yup, as soon as I "push", I have declared my changes as "fit for
                        > consumption by the rest of the team".
                        >
                        > Pre-XP, I worked on a project where the first level of commit meant the
                        code was good for me, the next level meant it was good for the team and
                        the third that it could be used by testing. When we introduced XP, the
                        third level became "for the customer." I've never heard anyone else
                        enunciate this distinction before! (BTW, we did this using Visual
                        SourceSafe,
                        probably the worst VCS ever written!)

                        > But I haven't declared it fit for consumption by my customer.
                        >
                        > So what if I shift my "done done" point forward and decoupled that from
                        > "showing it to the customer".
                        >
                        > ie. The point where it is all Tested, documented, review(ed or
                        > reviewable...preferably pair programmed, or if I can't do that... the diff
                        > in a web base
                        > collaboration tool http://www.reviewboard.org/), integrated, smoke tested,
                        > pushed to central repository.
                        >
                        > Sort of makes sense really... 90% of what I do to get anything to the "done
                        > done" point is not really understandable by a customer. It's only when I
                        > tie a whole bunch of stuff together with a vast bunch of existing stuff
                        > that the customer goes "Oh cool, I needed that!".
                        >
                        > I want the customer feedback ASAP... but I need (and can get) the feedback
                        > from the build system, smoke test suite, other developers even faster.
                        >
                        > If every changeset I push is so small "there is obviously nothing wrong
                        > with it" I will be in a better state than if the answer is "there is
                        > nothing obviously wrong with it".
                        >
                        > The aim of the experiment is to find out whether it is feasible to decouple
                        > "done done" from "get customer feedback", and what are the costs and
                        > benefits.
                        >
                        > I agree with you... anything that would decreasing the feedback from a
                        > customer would be A Bad Thing.
                        >
                        > Yes, that could be a potential cost of this approach. But not necessarily,
                        I think.

                        > How ever, sprint overruns happen sometimes... Priorities change. Shit
                        > happens both internally and externally. Wouldn't I be in a better state if
                        > I could point to a pile of "this stuff is done and dusted and I can go on
                        > to other things if you really want and come back to it later, and this
                        > other stuff isn't done at all." than sitting with a mouthful of teeth
                        > mumbling... "Well, it's not done done yet".
                        >
                        > The view of Scrum I'm starting to take is this.... "A Story is a Unit of
                        > Bidding (amongst competing customer interests and values) for the Team's
                        > attention."
                        >
                        > I don't want to over-generalize, but in my own experience, Scrum teams
                        (that I've worked on) were a bit more removed from the customer than
                        XP teams. It wasn't as easy to push the notion of customer value lower,
                        by spltting stories, so more attention was paid to (what we used to call)
                        tasks. Others may have had different experience, of course.

                        There is a further level beyond "ready for the customer" and that's
                        "ready for release." Just because the customer has learned to see value
                        in some piece of work that's accomplished does not necessarily mean
                        that the work can be released yet - some minimum level of incremental
                        value may be needed first or some other stories may need to be completed
                        before we reach a "minimal releasable feature."

                        Charlie

                        Charlie

                        > --
                        > John Carter Phone : (64)(3) 358 6639
                        > Tait Electronics Fax : (64)(3) 359 4632
                        > PO Box 1645 Christchurch Email : john.carter@...
                        > New Zealand
                        >
                        > --
                        >
                        > ------------------------------
                        > This email, including any attachments, is only for the intended recipient.
                        > It is subject to copyright, is confidential and may be the subject of
                        > legal
                        > or other privilege, none of which is waived or lost by reason of this
                        > transmission.
                        > If you are not an intended recipient, you may not use, disseminate,
                        > distribute or reproduce such email, any attachments, or any part thereof.
                        > If you have received a message in error, please notify the sender
                        > immediately and erase all copies of the message and any attachments.
                        > Unfortunately, we cannot warrant that the email has not been altered or
                        > corrupted during transmission nor can we guarantee that any email or any
                        > attachments are free from computer viruses or other conditions which may
                        > damage or interfere with recipient data, hardware or software. The
                        > recipient relies upon its own procedures and assumes all risk of use and
                        > of
                        > opening any attachments.
                        > ------------------------------
                        >
                        > [Non-text portions of this message have been removed]
                        >
                        >
                        >


                        [Non-text portions of this message have been removed]
                      Your message has been successfully submitted and would be delivered to recipients shortly.