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

Re: [scrumdevelopment] Re: Scrum Ownership

Expand Messages
  • mike.dwyer1@comcast.net
    Dave: WOW What a huge difference from your posts a year ago. You really need to tell us more about how you got to the point the customer capacity to absorb
    Message 1 of 99 , Apr 4 10:52 AM
    • 0 Attachment
      Dave:
      WOW  What a huge difference from your posts a year ago.  You really need to tell us more about how you got to the point the customer capacity to absorb DONE was saturated.
       
      Congratulations. 
       
      --
      Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


      The greatest oak was once a little nut who held its ground. ~Author Unknown
       
      -------------- Original message --------------
      From: David A Barrett <dave.barrett@...>

      > >I think someone else said that Scrum is a path, not a destination. I
      > >agree with that.
      >
      > I agree too. With regards to "cookie-cutter" solutions, I highly doubt
      > that there are going to be any to be found for anyone.
      >
      > Personally, I think that one of the key strengths of Scrum is that it is so
      > simple it is easy to make the adaptations that will make if a good fit for
      > a particular situation. I think that above all we need to hold on to that
      > simplicity, and continue to regard our adaptations as simply that;
      > adaptations and not improvements or evolements.
      >
      > I've noticed that some of the people on the list have concentrated on
      > squeezing every last ounce of productivity out of a development team.
      > They've made adaptations that seek to reduce the downtime between Sprints,
      > and to strip out all extraneous distractions from the developers and to
      > deliver as much new functionality as quickly as possible. I'm sure this
      > makes sense within their situations, and I'm sure it seems natural to them
      > to assume that these same goals would be universal. From there, I have no
      > doubt it becomes easy for them to view their adaptations as the natural
      > "evolution" of Scrum.
      >
      > Personally, I wonder what such a pace does to the developers over the long
      > haul. Where's the line between an exhilarating, rewarding and successful
      > environment and a sweat shop?
      >
      > As a contrast, I noticed that Scrum is really good at choking off
      > development when required. A lot of customers aren't able to cope with a
      > virtual firehose of new functionality aimed a them. Around here, we're at
      > one of those points with one of our projects. We've almost completed an
      > early stage of development, and the customer is going to need some time to
      > experiment with the software, find out what works and what doesn't, plan
      > training for their staff, train their staff, implement the new software and
      > evaluate how it's going to change their world. I should add that this new
      > software represents a potentially enormous change to them, and the way that
      > they do their jobs.
      >
      > In the meantime, they might want a couple of tweaks to what we've done, but
      > they can't tell us what the next step should be. We, the developers, can't
      > tell either and any work that we might do before we find out stands a very
      > good chance of being useless, unwanted or just plain wrong. Scrum handles
      > this. Nothing on the PB for this project bubbles up to a high enough
      > priority to make a Sprint Backlog. While we wait, we point the
      > functionality firehose at another customer.
      >
      > My point on that is that we're all looking for something different.
      > Vanilla, out of the box Scrum provides a good starting place to achieve a
      > large range of different goals. Maybe Scrum needs someone like Ken to
      > remind us when we're getting caught up in our own situations and losing
      > track of larger world of software development.
      >
      > Dave Barrett,
      > Lawyers' Professional Indemnity Company
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      > <*> To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      >
      > <*> To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      >
      > <*> Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/
      >
      >
      >
    • mike.dwyer1@comcast.net
      Dave: WOW What a huge difference from your posts a year ago. You really need to tell us more about how you got to the point the customer capacity to absorb
      Message 99 of 99 , Apr 4 10:52 AM
      • 0 Attachment
        Dave:
        WOW  What a huge difference from your posts a year ago.  You really need to tell us more about how you got to the point the customer capacity to absorb DONE was saturated.
         
        Congratulations. 
         
        --
        Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


        The greatest oak was once a little nut who held its ground. ~Author Unknown
         
        -------------- Original message --------------
        From: David A Barrett <dave.barrett@...>

        > >I think someone else said that Scrum is a path, not a destination. I
        > >agree with that.
        >
        > I agree too. With regards to "cookie-cutter" solutions, I highly doubt
        > that there are going to be any to be found for anyone.
        >
        > Personally, I think that one of the key strengths of Scrum is that it is so
        > simple it is easy to make the adaptations that will make if a good fit for
        > a particular situation. I think that above all we need to hold on to that
        > simplicity, and continue to regard our adaptations as simply that;
        > adaptations and not improvements or evolements.
        >
        > I've noticed that some of the people on the list have concentrated on
        > squeezing every last ounce of productivity out of a development team.
        > They've made adaptations that seek to reduce the downtime between Sprints,
        > and to strip out all extraneous distractions from the developers and to
        > deliver as much new functionality as quickly as possible. I'm sure this
        > makes sense within their situations, and I'm sure it seems natural to them
        > to assume that these same goals would be universal. From there, I have no
        > doubt it becomes easy for them to view their adaptations as the natural
        > "evolution" of Scrum.
        >
        > Personally, I wonder what such a pace does to the developers over the long
        > haul. Where's the line between an exhilarating, rewarding and successful
        > environment and a sweat shop?
        >
        > As a contrast, I noticed that Scrum is really good at choking off
        > development when required. A lot of customers aren't able to cope with a
        > virtual firehose of new functionality aimed a them. Around here, we're at
        > one of those points with one of our projects. We've almost completed an
        > early stage of development, and the customer is going to need some time to
        > experiment with the software, find out what works and what doesn't, plan
        > training for their staff, train their staff, implement the new software and
        > evaluate how it's going to change their world. I should add that this new
        > software represents a potentially enormous change to them, and the way that
        > they do their jobs.
        >
        > In the meantime, they might want a couple of tweaks to what we've done, but
        > they can't tell us what the next step should be. We, the developers, can't
        > tell either and any work that we might do before we find out stands a very
        > good chance of being useless, unwanted or just plain wrong. Scrum handles
        > this. Nothing on the PB for this project bubbles up to a high enough
        > priority to make a Sprint Backlog. While we wait, we point the
        > functionality firehose at another customer.
        >
        > My point on that is that we're all looking for something different.
        > Vanilla, out of the box Scrum provides a good starting place to achieve a
        > large range of different goals. Maybe Scrum needs someone like Ken to
        > remind us when we're getting caught up in our own situations and losing
        > track of larger world of software development.
        >
        > Dave Barrett,
        > Lawyers' Professional Indemnity Company
        >
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        > <*> To visit your group on the web, go to:
        > http://groups.yahoo.com/group/scrumdevelopment/
        >
        > <*> To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        >
        > <*> Your use of Yahoo! Groups is subject to:
        > http://docs.yahoo.com/info/terms/
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.