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

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

Expand Messages
  • 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 1 of 14 , Feb 7, 2009
      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 2 of 14 , Feb 7, 2009
        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 3 of 14 , Feb 7, 2009
          --- 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 4 of 14 , Feb 8, 2009
            --- 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 5 of 14 , Feb 9, 2009
              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 6 of 14 , Feb 9, 2009
                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 7 of 14 , Feb 9, 2009
                  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.