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

Re: [scrumdevelopment] uh-oh -- we're not gonna make it

Expand Messages
  • Alan Dayley
    Dave, Scrum helps the team fail faster so learning and eventual success happens faster. You now have hard data about how your team is working and that
    Message 1 of 14 , Feb 6, 2009
    • 0 Attachment
      Dave,

      Scrum helps the team fail faster so learning and eventual success
      happens faster. You now have hard data about how your team is working
      and that something is not working. Looks like Scrum is working for
      you!

      I would have suggested your third choice but the team gave you even
      more valuable feedback about your stories. So, to your question, what
      do you do?

      1. Abort the sprint. If you can see that you will literally have
      nothing shippable at the end of the sprint, this option may be
      necessary. Kind of like ripping of the bandage quickly rather than
      another week of "death march" to the failed Sprint Demo or Review.

      2. Continue the sprint if you can find things that are able to
      complete by the Sprint Demo day. Demonstrate those few things for
      Product Owner acceptance. Take the low velocity data as real data,
      because it is.

      Whatever you do to end the sprint, hold a retrospective to record what
      happened, why it happened and what will be done to improve in the next
      sprint! Important! Do it!

      The retrospective may bring out things like:
      - Need a complete definition of done that includes testing,
      documentation, etc. before a new story gets attention.
      - Stories need to follow the INVEST model
      (http://weblogs.asp.net/bsimser/archive/2007/05/02/invest-in-your-stories-with-smart-tasks.aspx)
      It sounds like you have issues around the "I", Independent.
      - Maybe you need code reviews or pair programming.

      The other responses in this thread already touched on all this. I
      just want to make sure you see the huge value in this current failure.
      If the lessons can be pulled out of it and applied, it's a huge help
      for the future!

      Alan

      On Fri, Feb 6, 2009 at 12:49 PM, Dave Burke <dave@...> wrote:
      > So here's the scenario:
      >
      > It's late in the third week of a four-week sprint. We've been plugging
      > along, making good progress against the user stories (new features and
      > enhancements to a web product), and now we're focused on testing in the QA
      > environment, and logging defects. A lot of defects. After a couple of days
      > of testing, we're up over 100 -- more than we can probably fix before
      > sprint's end.
      >
      > What's the best thing to do at that point in terms of the Scrum process?
      > Options I can think of include:
      >
      > - extending the sprint to complete testing and fix all the critical bugs,
      > then deploy
      >
      > - completing the sprint without any deployment, rolling the bug fixes over
      > to the next sprint, and continuing
      >
      > - focusing our efforts on fixing a subset of the stories in order to deploy
      > them, then roll the remaining stories over to the next sprint
      >
      > The last option appealed to my Scrum instincts, but the team felt strongly
      > that the features were so integrated with each other that trying to break
      > them apart and re-test would be more work and time than fixing all the
      > defects.
      >
      > What are your thoughts? I'm interested in ideas for avoiding the situation
      > in the first place, but I'm particularly interested in ways to deal with
      > that scenario once it has occurred.
      >
      > Thanks!
      >
      > db
      >
      > --
      > dave burke
      > dave@...
      > skype: dave.e.burke
      > linkedin: http://www.linkedin.com/in/daveburke
      >
      >
      >
    • Roy Morien
      Well, it s real because it s happening to you. But, why so many defects ? What happened to in-line testing, hopefully automated testing? It seems that you are
      Message 2 of 14 , Feb 7, 2009
      • 0 Attachment
        Well, it's real because it's happening to you. But, why so many 'defects'? What happened to in-line testing, hopefully automated testing? It seems that you are doing end-of-line QA, which is a real No No in Scrum and iterative methods generally (except to keep the client happy at the end of it all, and demonstratng how error free the final product is :) ).
         
        How come the problem wasn't revealed until the sprint is 75% complete, in time terms? What happened at the Daily Standups way back in week 1 and every day since? Didn't anyone indicate problems and defects that they had?
         
        Could you have disentangled the User Stories a bit? What is it about the stories that are so integrated that you have this apparently one great lump of development to do?
         
        I would suggest that in future you consider 2 week sprints. My thinking is that 4 weeks still gives a deadline a bit too far away to give the mental impetus of having to meet a deadline.
         
        So what to do now, in the current problem? Well, I think if you are able to salvage some success from the sprint, by being able to deliver at least some good, defect free functionality, then you should finish the sprint. But not extend it. If that seems to provide dubious success possibilities, then cancel the sprint, put the stories back on the Product Backlog, re-estimate them, and start a new sprint (a shorter sprint). Before you do that, have a good retrospective on what the hell happened. That is the first big step in avoiding having the same problem again. It seems that those defects may themselves create User stories.
         
        But I think your attitude should be 'Whoops, we have pretty much wasted 4 weeks. Why? That's not a tragedy (a bit of a bummer though), but it is an imperative for a learning experience. What can we do better, and How? Then get on with it, in a manner that will not repeat the bad experience.
         
        Regards,
        Roy Morien.


        To: scrumdevelopment@yahoogroups.com
        From: dave@...
        Date: Fri, 6 Feb 2009 14:49:02 -0500
        Subject: [scrumdevelopment] uh-oh -- we're not gonna make it


        So here's the scenario:

        It's late in the third week of a four-week sprint. We've been plugging along, making good progress against the user stories (new features and enhancements to a web product), and now we're focused on testing in the QA environment, and logging defects. A lot of defects. After a couple of days of testing, we're up over 100 -- more than we can probably fix before sprint's end.

        What's the best thing to do at that point in terms of the Scrum process? Options I can think of include:

         - extending the sprint to complete testing and fix all the critical bugs, then deploy

         - completing the sprint without any deployment, rolling the bug fixes over to the next sprint, and continuing

        - focusing our efforts on fixing a subset of the stories in order to deploy them, then roll the remaining stories over to the next sprint

        The last option appealed to my Scrum instincts, but the team felt strongly that the features were so integrated with each other that trying to break them apart and re-test would be more work and time than fixing all the defects. 

        What are your thoughts? I'm interested in ideas for avoiding the situation in the first place, but I'm particularly interested in ways to deal with that scenario once it has occurred.

        Thanks!

        db

        --
        dave burke
        dave@...
        skype: dave.e.burke
        linkedin: http://www.linkedin .com/in/daveburk e



        Let ninemsn property help! Need a new place to rent, share or buy?
      • Ilja Preuß
        ... In the past, whenever I ve found myself in such a rathole, I used to convince myself that just continuing going down was the most effective solution. In
        Message 3 of 14 , Feb 7, 2009
        • 0 Attachment
          2009/2/6 Dave Burke <dave@...>:

          > The last option appealed to my Scrum instincts, but the team felt strongly
          > that the features were so integrated with each other that trying to break
          > them apart and re-test would be more work and time than fixing all the
          > defects.
          >
          > What are your thoughts?

          In the past, whenever I've found myself in such a rathole, I used to
          convince myself that just continuing going down was the most effective
          solution. In retrospect, it always turned out that I was just kidding
          myself - the rathole was deeper than I admitted, and going back and
          finding a different way would have been much easier than I thought.

          You would think that, with all that experience, I'm much wiser today.
          Well, sometimes I manage to be...

          Cheers, Ilja
        • leiderleider
          ... What are the team s and the product owner s opinions on the situation and the possibilities? - The team seems to think they re not gonna make it. Do they
          Message 4 of 14 , Feb 7, 2009
          • 0 Attachment
            --- In scrumdevelopment@yahoogroups.com, Dave Burke <dave@...> wrote:
            > environment, and logging defects. A lot of defects. After a couple of days
            > of testing, we're up over 100 -- more than we can probably fix before
            > sprint's end.

            What are the team's and the product owner's opinions on the situation and the possibilities?
            - The team seems to think they're not gonna make it. Do they think they will be able to
            deliver some defect-free product? - Would this product be ok for the PO? - If so, then
            continue the sprint to deliver these features. If not - just stop immediately. A situation like
            this tends to not end up to a plannable date.

            Let the team and the po decide. Give them the information you got in this group and tell
            them about your instinct.

            Do not expand the sprint. Then the worst thing happening is another lost week.

            Anything else has already been written by others.

            By,
            Andreas
          • C. Keith Ray
            ... the QA ... of days ... bugs, ... fixes over ... deploy ... strongly ... break ... situation ... IMO... End this sprint without deploying. Instead of
            Message 5 of 14 , Feb 8, 2009
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, Dave Burke <dave@...> wrote:
              >
              > So here's the scenario:
              >
              > It's late in the third week of a four-week sprint. We've been plugging
              > along, making good progress against the user stories (new features and
              > enhancements to a web product), and now we're focused on testing in
              the QA
              > environment, and logging defects. A lot of defects. After a couple
              of days
              > of testing, we're up over 100 -- more than we can probably fix before
              > sprint's end.
              >
              > What's the best thing to do at that point in terms of the Scrum process?
              > Options I can think of include:
              >
              > - extending the sprint to complete testing and fix all the critical
              bugs,
              > then deploy
              >
              > - completing the sprint without any deployment, rolling the bug
              fixes over
              > to the next sprint, and continuing
              >
              > - focusing our efforts on fixing a subset of the stories in order to
              deploy
              > them, then roll the remaining stories over to the next sprint
              >
              > The last option appealed to my Scrum instincts, but the team felt
              strongly
              > that the features were so integrated with each other that trying to
              break
              > them apart and re-test would be more work and time than fixing all the
              > defects.
              >
              > What are your thoughts? I'm interested in ideas for avoiding the
              situation
              > in the first place, but I'm particularly interested in ways to deal with
              > that scenario once it has occurred.

              IMO...

              End this sprint without deploying.

              Instead of logging bugs, your testers and programmers should sit
              together and fix them (unless your Product Owner really finds it
              acceptable to ship with those bugs -- find out before the end of the
              sprint).

              It's best if your product owner can approve stories as "done done"
              during the sprint. To avoid this problem in the future, don't start
              working on 'new' stories until the older stories are tested and
              approved. Keep the stories small so that testing and programming can
              be finished on the same day.

              I suggest you google for "done done" and "scrum". Here's one page that
              should be helpful:
              http://www.infoq.com/news/2008/10/PowerOfDone
              (note that it links to an interview with Ken Schwaber)

              PS: You might want to shorten your sprints to weekly until your team
              really gets the hang of *sustainable* agile development. In one week,
              your team should be able to program and test 5 or more stories and
              have a code-base that's clean enough to start the next sprint without
              fixing bugs.

              PPS: If your stories are longer than a week, you'll have to learn how
              to break them down into smaller stories.

              PPPS: Test-Driven Development (TDD) helps a lot, to avoid creating bugs.

              --
              C. Keith Ray, IXP Coach, Industrial Logic, Inc.
              http://industriallogic.com 866-540-8336 (toll free)
              Groove with our Agile Greatest Hits:
              http://www.industriallogic.com/elearning/
              http://agilesolutionspace.blogspot.com/
            • Tom Mellor
              +1 on Keith s comments and advice. Do not lengthen the Sprint. Tom Mellor Certified Scrum Trainer
              Message 6 of 14 , Feb 9, 2009
              • 0 Attachment
                Re: uh-oh -- we're not gonna make it

                +1 on Keith's comments and advice.  Do not lengthen the Sprint.

                Tom Mellor
                Certified Scrum Trainer
                 

              • Dave Burke
                thank you all so much for the thoughtful responses (and feel free to keep the discussion going). this is incredibly helpful. we are indeed a team moving to
                Message 7 of 14 , Feb 9, 2009
                • 0 Attachment
                  thank you all so much for the thoughtful responses (and feel free to keep the discussion going). this is incredibly helpful.

                  we are indeed a team moving to Scrum from years of waterfall, and obviously we fell back into some old ways on this sprint, which in the thick of it, i didn't even realize. so i've gotten discussion points for our retrospective today, some of which are:

                  - swarm one story at a time to completion, including testing
                  - check/certify the backlog for INVEST
                  - never, ever expand the timeline for a sprint

                  thanks again!

                  db

                  --
                  dave burke
                  dave@...
                  skype: dave.e.burke
                  linkedin: http://www.linkedin.com/in/daveburke


                  On Mon, Feb 9, 2009 at 7:36 AM, Tom Mellor <tom.mellor.c5t2@...> wrote:

                  +1 on Keith's comments and advice.  Do not lengthen the Sprint.

                  Tom Mellor
                  Certified Scrum Trainer
                   


                • James Schiel
                  Good luck, Dave! The good news ‹ you found out fast! It¹ll be a lot easier to break these old habits having experienced a real failure. You won¹t have to
                  Message 8 of 14 , Feb 9, 2009
                  • 0 Attachment
                    Re: [scrumdevelopment] Re: uh-oh -- we're not gonna make it Good luck, Dave!

                    The good news — you found out fast! It’ll be a lot easier to break these old habits having experienced a real failure. You won’t have to work so hard to convince the team that a different approach is called for. They’ve lived it.

                    Take care.

                    Jim Schiel


                    On 2/9/09 3:20 PM, "Dave Burke" <dave@...> wrote:


                     

                    thank you all so much for the thoughtful responses (and feel free to keep the discussion going). this is incredibly helpful.

                    we are indeed a team moving to Scrum from years of waterfall, and obviously we fell back into some old ways on this sprint, which in the thick of it, i didn't even realize. so i've gotten discussion points for our retrospective today, some of which are:

                    - swarm one story at a time to completion, including testing
                    - check/certify the backlog for INVEST
                    - never, ever expand the timeline for a sprint

                    thanks again!

                    db
                  Your message has been successfully submitted and would be delivered to recipients shortly.