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

Re: [scrumdevelopment] Buyin

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.