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

RE: [scrumdevelopment] RE: What to do with "loose ends"

Expand Messages
  • Kerri Rusnak
    My experience is that if you reduce the workload, people gold-plate the work or slow the rate to meet the deadline. Consider increasing the quality of the
    Message 1 of 26 , Apr 1 1:36 AM

      My experience is that if you reduce the workload, people gold-plate the work or slow the rate to meet the deadline.  Consider increasing the quality of the software through increasing the detail of the requirements provided.   You end up with the same number of features but each feature has more breadth.

       

      Just a thought :)

       

      - Kerri

       

       

       

      -----Original Message-----
      From: Karl Scotland [mailto:karl.scotland@...]
      Sent: Saturday, 13 March 2004 4:13 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] RE: What to do with "loose ends"

       

      Comments embedded below...

      > -----Original Message-----
      > From: PaulOldfield1@...
      >
      > (responding to Karl)
      >
      > >> Has anybody measured what happens if the team commits to
      > >> less during a sprint?  There was a hypothesis that it might
      > >> lengthen the "decompression" time at the beginning of the
      > >> sprint and shorten the rush at the end.  This would hypothetically
      > >> give better quality software owing to more time to think about it,
      > >> but you still get the rush at the end of the sprint.  If
      > you're in a
      > >> rush all the time, OTOH,  then committing to less should help.
      > >
      > > I've not got any scientific measurements, but I can report that we
      > > consciously decided to plan with a reduced velocity, with the
      > > intention that it would result in increased quality.  The perception
      > > so far is that it has succedded.
      > >
      > > The other thing we have focussed on to minimise loose ends is
      > > acceptance testing (we're XPing aswell as Scrumming if you
      > > hadn't guessed!).  This has reduced the number of false
      > > assumptions which the developers make about the finer
      > > details of the expected behaviour.
      >
      > Thanks, Karl; useful iformation.  IIRC from your presentations,
      > your interactive TV sounded like it was always 'in a rush' and
      > your iterations were probably short enough not to have much
      > if any 'decompression time' at the beginning.  If this latter is
      > the case (would you concur?) then I agree, "committing to less
      > should help".

      In some senses it is always a rush because we are doing full releases at
      least every month.  On the other hand, we have managed the rush by
      reducing the amount of work we commit to.  The "decompression" happens
      at the start of every release, so the amount of decompression depends on
      the length of release.  A very short release allows for less
      decompression.  What I found interesting (and satisfying) was that it
      was the business team that suggested we commit to less in order to
      improve the quality, because the impact of committing to too much was so
      visible.

      > I find it interesting that people can have a 'decompression time'
      > at the start of an iteration even when they *know* that they
      > always end up leaving loose ends in the rush at the end.  I just
      > don't know what lessons to learn from this observation (yet).
      > Perhaps better feedback on estimation so the loose ends get
      > included would help?

      I've found that the burn down indicates when the decompression is
      decompressing too much.

      Karl

      BBCi at http://www.bbc.co.uk/

      This e-mail (and any attachments) is confidential and may contain
      personal views which are not the views of the BBC unless specifically
      stated.
      If you have received it in error, please delete it from your system.
      Do not use, copy or disclose the information in any way nor act in
      reliance on it and notify the sender immediately. Please note that the
      BBC monitors e-mails sent or received.
      Further communication will signify your consent to this.


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




    • Cook Linda
      I have a recent experience with a team who was very conservative in their sprint committment. One contributing factor may be that they have seen other teams
      Message 2 of 26 , Apr 1 6:36 AM
        I have a recent experience with a team who was very conservative in their
        sprint committment. One contributing factor may be that they have seen
        other teams workinglong hours to meet goals. The result was once the team
        felt they could accomplish more they worked to add sprint goals. The team
        met the original goals plus the goals that they added.
        From my perspective, trustung in the team and a bit of faith in the process.
        --------------------------
        Sent from my BlackBerry Wireless Handheld
      • J. B. Rainsberger
        ... I find that when I get to work at my own pace for a while, then I start to feel like I have no real deadline, and as Peopleware taught us, the team without
        Message 3 of 26 , Apr 1 9:49 AM
          Cook Linda wrote:

          > I have a recent experience with a team who was very conservative in their
          > sprint committment. One contributing factor may be that they have seen
          > other teams workinglong hours to meet goals. The result was once the team
          > felt they could accomplish more they worked to add sprint goals. The team
          > met the original goals plus the goals that they added.
          >>From my perspective, trustung in the team and a bit of faith in the process.

          I find that when I get to work at my own pace for a while, then I start
          to feel like I have no real deadline, and as Peopleware taught us, the
          team without the deadline finishes first and best.
          --
          J. B. Rainsberger,
          Diaspar Software Services
          http://www.diasparsoftware.com :: +1 416 791-8603
          Let's write software that people understand
        Your message has been successfully submitted and would be delivered to recipients shortly.