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

Re: [scrumdevelopment] Buyin

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