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

RE: [scrumdevelopment] Buyin

Expand Messages
  • Steven Gordon
    Geoff, It sounds like it is you who are determining the requirements for each sprint. You might consider letting your customers vote on which requirements each
    Message 1 of 12 , Nov 1, 2004
    • 0 Attachment
      Geoff,

      It sounds like it is you who are determining the requirements for each
      sprint.

      You might consider letting your customers vote on which requirements
      each sprint will try to fulfill (the requirements in a sprint do not have to
      add up to a single coherent requirement). Every customer could have
      the same number of votes, or the votes could be proportional to how
      much each customer is paying for development or how long since their
      last requirement was fulfilled or poltical clout or whatever.

      By having the customer's officially determine when each requirement is
      implemented, then they provide their own answer as to when. It also
      facilitates steering the project to respond to changing urgencies, which
      should please any customer.

      Steven Gordon
      http://sf.asu.edu/

      -----Original Message-----
      From: Freya Watts [mailto:freyawatts@...]
      Sent: Mon 11/1/2004 7:23 AM
      To: scrumdevelopment@yahoogroups.com
      Cc:
      Subject: [scrumdevelopment] Buyin


      Does anyone have any sure fire tips for getting “customers” (internal or external) on board with moving from traditional development methods to Scrum? I am finding that it’s much more difficult if there are a number of people whose requirements are being moved to the product backlog and I am constantly met with the question “When are my requirements going to be delivered? I need a date”. As I am not putting together a long-term project plan with Scrum but really only planning one or two Sprints in advance, I don’t have a ready answer apart from the fact that the future sprint dates are known and the priorities will roughly (emphasis on the roughly) match up to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in the one after that. This feeling tends to be less prevalent in projects where Scrum is used from the start but as this is a fairly new concept I am trying out at the moment, most of our projects are “converts” from traditional methods. Are there any types of projects that are easier to convert than others?

      I would also appreciate any analogies that could be used to help gain customers buy-in and focus their minds on thinking at a higher level with regards requirements. Putting together a sprint objective seems to be particularly hard for them.

      Sorry for all the questions at once

      Cheers

      Geoff
    • David Moskowitz
      Maybe I ve missed something... Can we assume that they (the customers and the organization) have bough in to the idea of agile (any agile process)? From
      Message 2 of 12 , Nov 1, 2004
      • 0 Attachment
        Maybe I've missed something...

        Can we assume that they (the customers and the organization) have
        bough in to the idea of "agile" (any agile process)? From the
        questions you've asked I wasn't sure.

        You asked for "sure fire" -- Do they understand the benefits of what
        an agile approach using Scrum? If not, I'd start there.

        Then you have to make sure that everyone fully participates... but
        that might be a separate question/issue.

        David


        On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
        <freyawatts@...> wrote:
        >
        > Does anyone have any sure fire tips for getting "customers" (internal or
        > external) on board with moving from traditional development methods to
        > Scrum? I am finding that it's much more difficult if there are a number of
        > people whose requirements are being moved to the product backlog and I am
        > constantly met with the question "When are my requirements going to be
        > delivered? I need a date". As I am not putting together a long-term project
        > plan with Scrum but really only planning one or two Sprints in advance, I
        > don't have a ready answer apart from the fact that the future sprint dates
        > are known and the priorities will roughly (emphasis on the roughly) match up
        > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
        > the one after that. This feeling tends to be less prevalent in projects
        > where Scrum is used from the start but as this is a fairly new concept I am
        > trying out at the moment, most of our projects are "converts" from
        > traditional methods. Are there any types of projects that are easier to
        > convert than others?
        >
        > I would also appreciate any analogies that could be used to help gain
        > customers buy-in and focus their minds on thinking at a higher level with
        > regards requirements. Putting together a sprint objective seems to be
        > particularly hard for them.
        ...snip...
      • Freya Watts
        Thanks Steve Thanks for your comments and I like the idea of voting although somewhere along the line there is always an arbitrary decision - be it who gets
        Message 3 of 12 , Nov 1, 2004
        • 0 Attachment
          Thanks Steve

          Thanks for your comments and I like the idea of voting although somewhere
          along the line there is always an arbitrary decision - be it who gets what
          votes or who is the person responsible overall. At the moment we are
          attempting to get someone to fill the role of product owner who prioritises
          anything that comes on the product backlog. I don't want the scrum
          team/scrum master to be deciding prioritisations as that really doesn't
          offer a lot to the people sponsoring or receiving the system. However, once
          prioritised (preferably by someone on the customer side), the scrum team are
          then taking requirements in a prioritised manner on to the spring backlog.

          My issue is mainly because it's a new process that I am trying to get
          business-wide support for, I am attempting to gain buy-in from everyone.
          People whose requirements are top of the list love the increased focus and
          progress on their work. However, I'm finding it difficult to placate people
          who are used to project plans that, although being extremely vague and
          unlikely to be anywhere near accurate, give people a date they can cling to.
          If their requirements aren't in one of the next 2 sprints, they don't have a
          date to pin their hopes to. Seems silly I guess but I'm still a rookie here
          trying to learn from others successes/mistakes.

          Your help is appreciated

          Geoff

          _____

          From: Steven Gordon [mailto:sagordon@...]
          Sent: 01 November 2004 14:43
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Buyin

          Geoff,

          It sounds like it is you who are determining the requirements for each
          sprint.

          You might consider letting your customers vote on which requirements
          each sprint will try to fulfill (the requirements in a sprint do not have to

          add up to a single coherent requirement). Every customer could have
          the same number of votes, or the votes could be proportional to how
          much each customer is paying for development or how long since their
          last requirement was fulfilled or poltical clout or whatever.

          By having the customer's officially determine when each requirement is
          implemented, then they provide their own answer as to when. It also
          facilitates steering the project to respond to changing urgencies, which
          should please any customer.

          Steven Gordon
          http://sf.asu.edu/

          -----Original Message-----
          From: Freya Watts [mailto:freyawatts@...]
          Sent: Mon 11/1/2004 7:23 AM
          To: scrumdevelopment@yahoogroups.com
          Cc:
          Subject: [scrumdevelopment] Buyin
          Does anyone have any sure fire tips for getting "customers" (internal or
          external) on board with moving from traditional development methods to
          Scrum? I am finding that it's much more difficult if there are a number of
          people whose requirements are being moved to the product backlog and I am
          constantly met with the question "When are my requirements going to be
          delivered? I need a date". As I am not putting together a long-term project
          plan with Scrum but really only planning one or two Sprints in advance, I
          don't have a ready answer apart from the fact that the future sprint dates
          are known and the priorities will roughly (emphasis on the roughly) match up
          to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
          the one after that. This feeling tends to be less prevalent in projects
          where Scrum is used from the start but as this is a fairly new concept I am
          trying out at the moment, most of our projects are "converts" from
          traditional methods. Are there any types of projects that are easier to
          convert than others?

          I would also appreciate any analogies that could be used to help gain
          customers buy-in and focus their minds on thinking at a higher level with
          regards requirements. Putting together a sprint objective seems to be
          particularly hard for them.

          Sorry for all the questions at once

          Cheers

          Geoff
        • Ron Jeffries
          ... Freya, some thoughts: First of all, what you re doing now isn t meeting these people s needs or wants. They want a date, and you re not giving it to them.
          Message 4 of 12 , Nov 1, 2004
          • 0 Attachment
            On Monday, November 1, 2004, at 9:23:18 AM, Freya Watts wrote:

            > Does anyone have any sure fire tips for getting "customers" (internal or
            > external) on board with moving from traditional development methods to
            > Scrum? I am finding that it's much more difficult if there are a number of
            > people whose requirements are being moved to the product backlog and I am
            > constantly met with the question "When are my requirements going to be
            > delivered? I need a date".

            Freya, some thoughts:

            First of all, what you're doing now isn't meeting these people's needs or
            wants. They want a date, and you're not giving it to them. It's perhaps
            unlikely that you'll succeed in making them happy without fulfilling that
            desire.

            Second, it's at least possible to do a longer-range plan, and even to
            budget X amount of time, starting N sprints from now, for these people's
            stuff.

            Third, I'm wondering how these questions were answered before you went to
            Scrum, and what's stopping you from doing at least that good [bad?] a job
            now?

            Regards,

            Ron Jeffries
            www.XProgramming.com
            You don't need to see my identification.
            These aren't the ideas you're looking for. Move along.
          • Ron Jeffries
            ... Hi Geoff. I called you Freya earlier, because, as you probably know, that s what your email address suggests. Sorry for the confusion. Ron Jeffries
            Message 5 of 12 , Nov 1, 2004
            • 0 Attachment
              On Monday, November 1, 2004, at 11:09:08 AM, Freya Watts [or not] wrote:

              > Thanks Steve

              Hi Geoff. I called you Freya earlier, because, as you probably know, that's
              what your email address suggests. Sorry for the confusion.

              Ron Jeffries
              www.XProgramming.com
              To be on the wire is life. The rest is waiting. --Karl Wallenda
            • Brad Appleton
              ... You might take a look at some of the buy-in/consensus strategies in an article entitled Agile Change Management: from First Principles to Best-Practices
              Message 6 of 12 , Nov 1, 2004
              • 0 Attachment
                On Mon, Nov 01, 2004 at 10:09:08AM -0600, Freya Watts wrote:
                > Thanks Steve
                >
                > Thanks for your comments and I like the idea of voting although somewhere along the line there is always an arbitrary decision - be it who gets what votes or who is the person responsible overall. At the moment we are attempting to get someone to fill the role of product owner who prioritizes
                > anything that comes on the product backlog. I don't want the scrum team/scrum master to be deciding prioritisations as that really doesn't offer a lot to the people sponsoring or receiving the system. However, once prioritised (preferably by someone on the customer side), the scrum team are then
                > taking requirements in a prioritised manner on to the spring backlog.

                You might take a look at some of the buy-in/consensus
                strategies in an article entitled "Agile Change Management:
                from First Principles to Best-Practices" at
                <http://www.cmcrossroads.com/articles/agileaug03.html>

                It talks about the role of the "product champion" in
                getting "one voice" from the customer regarding priorities,
                and several participatory decision-making strategies for
                doing just that.

                You might also look at QFD (Quality-Function Deployment)
                as it has some strategies for that sort of thing as well,
                if you can intuit how to make them lean/agile from the
                way that QFD is often practiced.

                --
                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
              • Freya Watts
                I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn t being driven by the business, it s just
                Message 7 of 12 , Nov 1, 2004
                • 0 Attachment

                  I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn’t being driven by the business, it’s just something I believe in and have got some backing to trial, I am trying to win people over as I go and then provide some evidence to the decision-makers on policy/process that this is a winner.

                   

                  I’m guessing you have all come across these sorts of issues before and am trying to draw on your experience on how to get the buy-in of people who don’t have to change. It would be a lot easier if it was a business-wide initiative (or even a unit-wide initiative) but until I can prove the theory I was looking for some tips. Sorry if I haven’t explained myself very well

                   

                  Cheers

                   

                  Geoff/Freya

                   


                  From: David Moskowitz [mailto:david.moskowitz@...]
                  Sent: 01 November 2004 15:25
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Buyin

                   

                  Maybe I've missed something... 

                  Can we assume that they (the customers and the organization) have
                  bough in to the idea of "agile" (any agile process)?    From the
                  questions you've asked I wasn't sure.

                  You asked for "sure fire" -- Do they understand the benefits of what
                  an agile approach using Scrum?  If not, I'd start there.

                  Then you have to make sure that everyone fully participates...  but
                  that might be a separate question/issue.

                  David


                  On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
                  <freyawatts@...> wrote:

                  > Does anyone have any sure fire tips for getting "customers" (internal or
                  > external) on board with moving from traditional development methods to
                  > Scrum? I am finding that it's much more difficult if there are a number of
                  > people whose requirements are being moved to the product backlog and I am
                  > constantly met with the question "When are my requirements going to be
                  > delivered? I need a date". As I am not putting together a long-term project
                  > plan with Scrum but really only planning one or two Sprints in advance, I
                  > don't have a ready answer apart from the fact that the future sprint dates
                  > are known and the priorities will roughly (emphasis on the roughly) match up
                  > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
                  > the one after that. This feeling tends to be less prevalent in projects
                  > where Scrum is used from the start but as this is a fairly new concept I am
                  > trying out at the moment, most of our projects are "converts" from
                  > traditional methods. Are there any types of projects that are easier to
                  > convert than others?
                  >
                  > I would also appreciate any analogies that could be used to help gain
                  > customers buy-in and focus their minds on thinking at a higher level with
                  > regards requirements. Putting together a sprint objective seems to be
                  > particularly hard for them.
                  ...snip...


                  To Post a message, send it to:   scrumdevelopment@...
                  To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                • Ron Jeffries
                  ... What is it that you want the people you re convincing to do? What will be better about agile processes, for you, and for them? Ron Jeffries
                  Message 8 of 12 , Nov 1, 2004
                  • 0 Attachment
                    On Monday, November 1, 2004, at 3:34:53 PM, Freya Watts wrote:

                    > I seem to be making progress in convincing customers about the agile process
                    > and certainly developers. As this isn't being driven by the business, it's
                    > just something I believe in and have got some backing to trial, I am trying
                    > to win people over as I go and then provide some evidence to the
                    > decision-makers on policy/process that this is a winner.

                    > I'm guessing you have all come across these sorts of issues before and am
                    > trying to draw on your experience on how to get the buy-in of people who
                    > don't have to change. It would be a lot easier if it was a business-wide
                    > initiative (or even a unit-wide initiative) but until I can prove the theory
                    > I was looking for some tips. Sorry if I haven't explained myself very well

                    What is it that you want the people you're convincing to do? What will be
                    better about agile processes, for you, and for them?

                    Ron Jeffries
                    www.XProgramming.com
                    If not now, when? -- The Talmud
                  • Gary F
                    ... We did a sort of QFD-light when I was at DEC. (It was commonly called QFD internally, but consultants who had worked on QFD in Japan thought we had barely
                    Message 9 of 12 , Nov 1, 2004
                    • 0 Attachment
                      --- Brad Appleton <brad@...> wrote:

                      > You might also look at QFD (Quality-Function Deployment)
                      > as it has some strategies for that sort of thing as well,
                      > if you can intuit how to make them lean/agile from the
                      > way that QFD is often practiced.

                      We did a sort of QFD-light when I was at DEC. (It was commonly called
                      QFD internally, but consultants who had worked on QFD in Japan thought
                      we had barely scratched the surface.) In any event, it was essentially
                      a way to derive priorities by mapping customer values against features.
                      Typical sessions were one to three days depending upon the number of
                      participants; they tended to be very intense.

                      I'm not sure what you have in mind by "the way that QFD is often
                      practiced", but for us it was strong customer collaboration and an
                      opportunity for intense face-to-face communication, both very important
                      points.

                      The downside is the tendancy, after that much work, to treat the
                      results of the QFD as carved in stone. I don't believe there's
                      anything specific to the way we did QFD that required that; indeed, if
                      the data was online, and the customers' priorities changed among the
                      existing value sets, one could easily plug in the changes and reorder
                      the priorities.

                      Also, both customer and developers might fall into the trap of saying
                      "ok, we have the priorities, we don't need to talk to each other for
                      another year," but that, too, can be avoided if you're aware of the
                      problem. The QFD sessions had the side effect of being a great
                      team-building exercise between the customers and developers, so in that
                      sense, it can be considered an enabler of frequent customer
                      collaboration.

                      Gary



                      __________________________________
                      Do you Yahoo!?
                      Check out the new Yahoo! Front Page.
                      www.yahoo.com
                    • Schiel James - SHS Malvern
                      One thought -- Many of your customers seem like they re still thinking in the traditional project planning mode (i.e., plan the whole schedule up front).
                      Message 10 of 12 , Nov 1, 2004
                      • 0 Attachment
                        One thought --
                         
                        Many of your customers seem like they're still thinking in the traditional project planning mode (i.e., plan the whole schedule up front). Perhaps you should consider creating a project-construct that will be built from some number of sprints with a planned delivery date at the end. Then, you can tell the customers you are able to scope into those sprints that their planned delivery date is your planned delivery date. Sprint works fine in this scenario -- but you'll still need to get the requirements/features prioritized and tenatively planned for the sprints within your project construct.  Make sense?
                         
                        Jim
                        -----Original Message-----
                        From: Freya Watts [mailto:freyawatts@...]
                        Sent: Monday, November 01, 2004 3:35 PM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: RE: [scrumdevelopment] Buyin

                        I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn’t being driven by the business, it’s just something I believe in and have got some backing to trial, I am trying to win people over as I go and then provide some evidence to the decision-makers on policy/process that this is a winner.

                         

                        I’m guessing you have all come across these sorts of issues before and am trying to draw on your experience on how to get the buy-in of people who don’t have to change. It would be a lot easier if it was a business-wide initiative (or even a unit-wide initiative) but until I can prove the theory I was looking for some tips. Sorry if I haven’t explained myself very well

                         

                        Cheers

                         

                        Geoff/Freya

                         


                        From: David Moskowitz [mailto:david.moskowitz@...]
                        Sent: 01 November 2004 15:25
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] Buyin

                         

                        Maybe I've missed something... 

                        Can we assume that they (the customers and the organization) have
                        bough in to the idea of "agile" (any agile process)?    From the
                        questions you've asked I wasn't sure.

                        You asked for "sure fire" -- Do they understand the benefits of what
                        an agile approach using Scrum?  If not, I'd start there.

                        Then you have to make sure that everyone fully participates...  but
                        that might be a separate question/issue.

                        David


                        On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
                        <freyawatts@...> wrote:

                        > Does anyone have any sure fire tips for getting "customers" (internal or
                        > external) on board with moving from traditional development methods to
                        > Scrum? I am finding that it's much more difficult if there are a number of
                        > people whose requirements are being moved to the product backlog and I am
                        > constantly met with the question "When are my requirements going to be
                        > delivered? I need a date". As I am not putting together a long-term project
                        > plan with Scrum but really only planning one or two Sprints in advance, I
                        > don't have a ready answer apart from the fact that the future sprint dates
                        > are known and the priorities will roughly (emphasis on the roughly) match up
                        > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
                        > the one after that. This feeling tends to be less prevalent in projects
                        > where Scrum is used from the start but as this is a fairly new concept I am
                        > trying out at the moment, most of our projects are "converts" from
                        > traditional methods. Are there any types of projects that are easier to
                        > convert than others?
                        >
                        > I would also appreciate any analogies that could be used to help gain
                        > customers buy-in and focus their minds on thinking at a higher level with
                        > regards requirements. Putting together a sprint objective seems to be
                        > particularly hard for them.
                        ...snip...


                        To Post a message, send it to:   scrumdevelopment@...
                        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...






                        To Post a message, send it to:   scrumdevelopment@...
                        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                        -------------------------------------------------------------------------------
                        This message and any included attachments are from Siemens Medical Solutions
                        USA, Inc. and are intended only for the addressee(s).
                        The information contained herein may include trade secrets or privileged or
                        otherwise confidential information. Unauthorized review, forwarding, printing,
                        copying, distributing, or using such information is strictly prohibited and may
                        be unlawful. If you received this message in error, or have reason to believe
                        you are not authorized to receive it, please promptly delete this message and
                        notify the sender by e-mail with a copy to Central.SecurityOffice@...

                        Thank you
                      • Freya Watts
                        Thanks - it s one step at a time at the moment. Changing the mindset of others, like you say, is the key and I can only do that gradually so it will probably
                        Message 11 of 12 , Nov 3, 2004
                        • 0 Attachment

                          Thanks – it’s one step at a time at the moment. Changing the mindset of others, like you say, is the key and I can only do that gradually so it will probably be an ugly transition phase from traditional to agile for a while making compromises on the way.

                           

                          Thanks to all for their comments.

                           


                          From: Schiel James - SHS Malvern [mailto:james.schiel@...]
                          Sent: 02 November 2004 02:15
                          To: ' scrumdevelopment@yahoogroups.com '
                          Subject: RE: [scrumdevelopment] Buyin

                           

                          One thought --

                           

                          Many of your customers seem like they're still thinking in the traditional project planning mode (i.e., plan the whole schedule up front). Perhaps you should consider creating a project-construct that will be built from some number of sprints with a planned delivery date at the end. Then, you can tell the customers you are able to scope into those sprints that their planned delivery date is your planned delivery date. Sprint works fine in this scenario -- but you'll still need to get the requirements/features prioritized and tenatively planned for the sprints within your project construct.  Make sense?

                           

                          Jim

                          -----Original Message-----
                          From: Freya Watts [mailto:freyawatts@...]
                          Sent: Monday, November 01, 2004 3:35 PM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: RE: [scrumdevelopment] Buyin

                          I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn’t being driven by the business, it’s just something I believe in and have got some backing to trial, I am trying to win people over as I go and then provide some evidence to the decision-makers on policy/process that this is a winner.

                           

                          I’m guessing you have all come across these sorts of issues before and am trying to draw on your experience on how to get the buy-in of people who don’t have to change. It would be a lot easier if it was a business-wide initiative (or even a unit-wide initiative) but until I can prove the theory I was looking for some tips. Sorry if I haven’t explained myself very well

                           

                          Cheers

                           

                          Geoff/Freya

                           


                          From: David Moskowitz [mailto:david.moskowitz@...]
                          Sent: 01 November 2004 15:25
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] Buyin

                           

                          Maybe I've missed something... 

                          Can we assume that they (the customers and the organization) have
                          bough in to the idea of "agile" (any agile process)?    From the
                          questions you've asked I wasn't sure.

                          You asked for "sure fire" -- Do they understand the benefits of what
                          an agile approach using Scrum?  If not, I'd start there.

                          Then you have to make sure that everyone fully participates...  but
                          that might be a separate question/issue.

                          David


                          On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
                          <freyawatts@...> wrote:

                          > Does anyone have any sure fire tips for getting "customers" (internal or
                          > external) on board with moving from traditional development methods to
                          > Scrum? I am finding that it's much more difficult if there are a number of
                          > people whose requirements are being moved to the product backlog and I am
                          > constantly met with the question "When are my requirements going to be
                          > delivered? I need a date". As I am not putting together a long-term project
                          > plan with Scrum but really only planning one or two Sprints in advance, I
                          > don't have a ready answer apart from the fact that the future sprint dates
                          > are known and the priorities will roughly (emphasis on the roughly) match up
                          > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
                          > the one after that. This feeling tends to be less prevalent in projects
                          > where Scrum is used from the start but as this is a fairly new concept I am
                          > trying out at the moment, most of our projects are "converts" from
                          > traditional methods. Are there any types of projects that are easier to
                          > convert than others?
                          >
                          > I would also appreciate any analogies that could be used to help gain
                          > customers buy-in and focus their minds on thinking at a higher level with
                          > regards requirements. Putting together a sprint objective seems to be
                          > particularly hard for them.
                          ...snip...


                          To Post a message, send it to:   scrumdevelopment@...
                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...






                          To Post a message, send it to:   scrumdevelopment@...
                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                          To Post a message, send it to:   scrumdevelopment@...
                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                          -------------------------------------------------------------------------------
                          This message and any included attachments are from Siemens Medical Solutions
                          USA, Inc. and are intended only for the addressee(s).
                          The information contained herein may include trade secrets or privileged or
                          otherwise confidential information. Unauthorized review, forwarding, printing,
                          copying, distributing, or using such information is strictly prohibited and may
                          be unlawful. If you received this message in error, or have reason to believe
                          you are not authorized to receive it, please promptly delete this message and
                          notify the sender by e-mail with a copy to Central.SecurityOffice@...

                          Thank you
                        Your message has been successfully submitted and would be delivered to recipients shortly.