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

RE: [scrumdevelopment] Buyin

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