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

stabilization sprints?

Expand Messages
  • mikeborozdin
    another question (starting a separate thread for this one). Do people have stabilization/perf sprints? What if releasing the software iteratively is not an
    Message 1 of 10 , Aug 5 2:38 PM
    • 0 Attachment
      another question (starting a separate thread for this one). Do
      people have stabilization/perf sprints?

      What if releasing the software iteratively is not an option
      (multiple examples to that can be given). The point is that the
      situation is that you can iteratively release the product within
      your company, but at one point in time you have to have a big
      sales/marketing push. As you close in on that push it's highly
      unadvisable to have any code churn.

      In case the answer is "yes" then the difference between SCRUM starts
      getting waterfall-like flavour.
    • Mike Cohn
      Depending on the nature of the project and the team, I have used Stabilization Sprints in the past. I ve found these handy in these situations: a) a team
      Message 2 of 10 , Aug 5 2:58 PM
      • 0 Attachment
        Depending on the nature of the project and the team, I have used
        "Stabilization Sprints" in the past. I've found these handy in these
        situations:

        a) a team developing shrinkwrap software
        b) a team doing ISO 9001 where we had some traceability junk to do extra
        that we didn't want in every sprint
        c) a team just getting used to Scrum

        If you can avoid a stabilization sprint, do so. If you use one, try to keep
        it as short as possible and try not to go into with any shoddy work. For
        example: in the teams above when we went into a stabilization sprint we'd
        still delivered high quality code and did not expect to find any more
        defects. We'd use the stabilization sprint to do some weird testing, to
        catch up the printed docs with final screen shots, to fill out the ISO
        documentation, etc. We didn't go into it expecting to find bugs in parts of
        the system that were shoddy.

        --Mike Cohn
        Author of User Stories Applied for Agile Software Development
        www.userstories.com
        www.mountaingoatsoftware.com


        -----Original Message-----
        From: mikeborozdin [mailto:EZXS@...]
        Sent: Thursday, August 05, 2004 3:39 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] stabilization sprints?

        another question (starting a separate thread for this one). Do
        people have stabilization/perf sprints?

        What if releasing the software iteratively is not an option
        (multiple examples to that can be given). The point is that the
        situation is that you can iteratively release the product within
        your company, but at one point in time you have to have a big
        sales/marketing push. As you close in on that push it's highly
        unadvisable to have any code churn.

        In case the answer is "yes" then the difference between SCRUM starts
        getting waterfall-like flavour.




        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • Mike Dwyer
        Is there a difference between refactoring and stabilization? ... Mike Dwyer Program Manager - Information Technology One Research Drive Suite 301 Westboro, MA
        Message 3 of 10 , Aug 5 7:46 PM
        • 0 Attachment

          Is there a difference between refactoring and stabilization? 

           

          -----------------------------------------

          Mike Dwyer

          Program Manager – Information Technology

           

          One Research Drive

          Suite 301

          WestboroMA    01581

          1 508 948 6018

           

          -----Original Message-----
          From: mikeborozdin [mailto:EZXS@...]
          Sent: Thursday, August 05, 2004 5:39 PM
          To:
          scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] stabilization sprints?

           

          another question (starting a separate thread for this one).  Do
          people have stabilization/perf sprints?

          What if releasing the software iteratively is not an option
          (multiple examples to that can be given).  The point is that the
          situation is that you can iteratively release the product within
          your company, but at one point in time you have to have a big
          sales/marketing push.  As you close in on that push it's highly
          unadvisable to have any code churn.

          In case the answer is "yes" then the difference between SCRUM starts
          getting waterfall-like flavour.



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




        • Mike Cohn
          Yes, they are completely different. Refactoring means changing the underlying structure of the code without changing its behavior. This means a refactoring
          Message 4 of 10 , Aug 5 7:55 PM
          • 0 Attachment

            Yes, they are completely different.

             

            Refactoring means changing the underlying structure of the code without changing its behavior. This means a refactoring neither corrects nor introduces a bug.

             

            Stabilization usually refers to putting the finishing touches on a product, which often means doing some additional testing and bug fixing, as well as things I’ve mentioned before like getting user’s guides or help systems totally in sync with the software.

             

            --Mike Cohn

            Author of User Stories Applied for Agile Software Development

            www.userstories.com

            www.mountaingoatsoftware.com


            From: Mike Dwyer [mailto:mdwyer@...]
            Sent: Thursday, August 05, 2004 8:46 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] stabilization sprints?

             

            Is there a difference between refactoring and stabilization? 

             

            -----------------------------------------

            Mike Dwyer

            Program Manager – Information Technology

             

            One Research Drive

            Suite 301

            Westboro,  MA     01581

            1 508 948 6018

             

            -----Original Message-----
            From: mikeborozdin [mailto:EZXS@...]
            Sent: Thursday, August 05, 2004 5:39 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] stabilization sprints?

             

            another question (starting a separate thread for this one).  Do
            people have stabilization/perf sprints?

            What if releasing the software iteratively is not an option
            (multiple examples to that can be given).  The point is that the
            situation is that you can iteratively release the product within
            your company, but at one point in time you have to have a big
            sales/marketing push.  As you close in on that push it's highly
            unadvisable to have any code churn.

            In case the answer is "yes" then the difference between SCRUM starts
            getting waterfall-like flavour.



            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@...




          • Kristan Vingrys
            Yes I believe there is a difference. Stabilising is making something work reliably. Refracturing is keeping the same functionality but making the design
            Message 5 of 10 , Aug 5 8:05 PM
            • 0 Attachment
              Yes I believe there is a difference.
               
              Stabilising is making something work reliably.
               
              Refracturing is keeping the same functionality but making the design cleaner.
               
              I would suggest that if you need to stabilize at the end of the iteration then the requirement was not implemented/tested correctly in the first place. Part of implementing a requirement should also be concerned with the performance aspect of the requirement. Performance/Stability should be done iteratively and not at the end.
               
              Regards,
               
              Kristan
               
               
              -----Original Message-----
              From: Mike Dwyer [mailto:mdwyer@...]
              Sent: Friday, 6 August 2004 12:46 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] stabilization sprints?

              Is there a difference between refactoring and stabilization? 

               

              -----------------------------------------

              Mike Dwyer

              Program Manager – Information Technology

               

              One Research Drive

              Suite 301

              WestboroMA    01581

              1 508 948 6018

               

              -----Original Message-----
              From: mikeborozdin [mailto:EZXS@...]
              Sent: Thursday, August 05, 2004 5:39 PM
              To:
              scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] stabilization sprints?

               

              another question (starting a separate thread for this one).  Do
              people have stabilization/perf sprints?

              What if releasing the software iteratively is not an option
              (multiple examples to that can be given).  The point is that the
              situation is that you can iteratively release the product within
              your company, but at one point in time you have to have a big
              sales/marketing push.  As you close in on that push it's highly
              unadvisable to have any code churn.

              In case the answer is "yes" then the difference between SCRUM starts
              getting waterfall-like flavour.



              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@...



            • Mike Cohn
              A good way to make this type of work happen during the sprint is to do it first. This is part of why I like doing test-driven development. If a team runs out
              Message 6 of 10 , Aug 5 8:12 PM
              • 0 Attachment

                A good way to make this type of work happen during the sprint is to do it first. This is part of why I like doing test-driven development. If a team runs out of time to test, we make sure they don’t by doing the tests first. Then maybe they run out of time to add one more feature but that’s better than putting out low-quality, untested software (in most cases IMO).

                 

                I’ve done a number of projects where we were concerned with performance and so we started very early with performance testing. We’d have a user story that was something like “A user must see the next screen with 2 seconds 90% of the time with 100 users on the site.” We’d code up a test facility to simulate users and when the only thing in the system was log in / log out we’d run the test. Pretty easy to pass! A few sprints later we might have more consuming transactions going on and maybe the test would have trouble. Each sprint we’d adjust the test so it simulated other paths through the system but that was it.

                 

                --Mike Cohn

                Author of User Stories Applied for Agile Software Development

                www.userstories.com

                www.mountaingoatsoftware.com


                From: Kristan Vingrys [mailto:kvingrys@...]
                Sent: Thursday, August 05, 2004 9:05 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] stabilization sprints?

                 

                Yes I believe there is a difference.

                 

                Stabilising is making something work reliably.

                 

                Refracturing is keeping the same functionality but making the design cleaner.

                 

                I would suggest that if you need to stabilize at the end of the iteration then the requirement was not implemented/tested correctly in the first place. Part of implementing a requirement should also be concerned with the performance aspect of the requirement. Performance/Stability should be done iteratively and not at the end.

                 

                Regards,

                 

                Kristan

                 

                 

                -----Original Message-----
                From: Mike Dwyer [mailto:mdwyer@...]
                Sent: Friday, 6 August 2004 12:46 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] stabilization sprints?

                Is there a difference between refactoring and stabilization? 

                 

                -----------------------------------------

                Mike Dwyer

                Program Manager – Information Technology

                 

                One Research Drive

                Suite 301

                Westboro,  MA     01581

                1 508 948 6018

                 

                -----Original Message-----
                From: mikeborozdin [mailto:EZXS@...]
                Sent: Thursday, August 05, 2004 5:39 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] stabilization sprints?

                 

                another question (starting a separate thread for this one).  Do
                people have stabilization/perf sprints?

                What if releasing the software iteratively is not an option
                (multiple examples to that can be given).  The point is that the
                situation is that you can iteratively release the product within
                your company, but at one point in time you have to have a big
                sales/marketing push.  As you close in on that push it's highly
                unadvisable to have any code churn.

                In case the answer is "yes" then the difference between SCRUM starts
                getting waterfall-like flavour.



                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@...




              • Boris Gloger
                ... What experience any of you have in implementing this to teams who are not used to do so? My issue is most of the time to get an awareness for the
                Message 7 of 10 , Aug 6 12:20 AM
                • 0 Attachment
                  On 06.08.2004, at 05:12, Mike Cohn wrote:

                  > I’ve done a number of projects where we were concerned with
                  > performance and so we started very early with performance testing.
                  > We’d have a user story that was something like “A user must see the
                  > next screen with 2 seconds 90% of the time with 100 users on the
                  > site.” We’d code up a test facility to simulate users and when the
                  > only thing in the system was log in / log out we’d run the test.
                  > Pretty easy to pass! A few sprints later we might have more consuming
                  > transactions going on and maybe the test would have trouble. Each
                  > sprint we’d adjust the test so it simulated other paths through the
                  > system but that was it.

                  What experience any of you have in implementing this to teams who are
                  not used to do so? My issue is most of the time to get an awareness for
                  the importance of testing and then it takes again a couple of
                  weeks/month to have the tools in place to be able to run all these
                  test.

                  Do someone has a miracle recipe?

                  --- boris
                • Boris Gloger
                  ... I would love to be in such situations that I would have had software development teams who had this kind of engineering practice in the past - wow. I am
                  Message 8 of 10 , Aug 6 12:21 AM
                  • 0 Attachment
                    On 06.08.2004, at 05:12, Mike Cohn wrote:

                    > A good way to make this type of work happen during the sprint is to do
                    > it first. This is part of why I like doing test-driven development. If
                    > a team runs out of time to test, we make sure they don’t by doing the
                    > tests first. Then maybe they run out of time to add one more feature
                    > but that’s better than putting out low-quality, untested software (in
                    > most cases IMO).
                    >

                    I would love to be in such situations that I would have had software
                    development teams who had this kind of engineering practice in the past
                    - wow. I am faced always with software development teams which did not
                    have made their homework. They did not deliver the documentation, or
                    they do not have test cases, the development environments are not worth
                    to name this, the deployment processes are not automated and and and.

                    So in this kind of environment I always have to stabilize the
                    "application" most of the time. The customer is claiming bugs, does
                    not want to pay for them, the code basis is not very maintainable and
                    the engineering practices are bad. In such an environment I usually
                    make the whole situation transparent by implementing Scrum, then all
                    these issues come to the surface. We start then negotiations with
                    customers, about how to deal with bugs, explain them how to proceed in
                    future, with bugs and new functionality and I start implementing better
                    engineering practices.

                    I call this stabilization, all the other things - stabilization of the
                    application is only a side product - we usually have to do this first,
                    because there are not only functional bugs, but the application itself
                    runs not smoothly - to slow, crashes or the applications servers are
                    not up.
                    - then we stabilize the "production processes" - how to deploy, create
                    fix release dates, etc.
                    - and after that we establish better engineering pracitices - using the
                    same editor, having code conventions, starting to create documentation,
                    etc
                    - if this is in place - maybe three to six month afterwards, we are
                    able to start refactoring

                    The out of the book Scrum approach has to be modified in such ways -
                    that we need to be aware that all these tasks are part of the sprint
                    backlog - Sure it slows down the creation of new functionality - but if
                    you cleaning you house you usually do not build a new room :))

                    boris
                  • Boris Gloger
                    ... What experience any of you have in implementing this to teams who are not used to do so? My issue is most of the time to get an awareness for the
                    Message 9 of 10 , Aug 6 12:22 AM
                    • 0 Attachment
                      On 06.08.2004, at 05:12, Mike Cohn wrote:

                      > I’ve done a number of projects where we were concerned with
                      > performance and so we started very early with performance testing.
                      > We’d have a user story that was something like “A user must see the
                      > next screen with 2 seconds 90% of the time with 100 users on the
                      > site.” We’d code up a test facility to simulate users and when the
                      > only thing in the system was log in / log out we’d run the test.
                      > Pretty easy to pass! A few sprints later we might have more consuming
                      > transactions going on and maybe the test would have trouble. Each
                      > sprint we’d adjust the test so it simulated other paths through the
                      > system but that was it.

                      What experience any of you have in implementing this to teams who are
                      not used to do so? My issue is most of the time to get an awareness for
                      the importance of testing and then it takes again a couple of
                      weeks/month to have the tools in place to be able to run all these
                      test.

                      Do someone has a miracle recipe?

                      --- boris

                      From boris.gloger@... Fri Aug 6 09:21:13 2004
                      Mime-Version: 1.0 (Apple Message framework v618)
                      In-Reply-To: <200408060312.i763CGjZ011381@...>
                      References: <200408060312.i763CGjZ011381@...>
                      Content-Type: text/plain;
                      charset=WINDOWS-1252;
                      format=flowed
                      Message-Id: <32A43952-E779-11D8-A57F-000A9591DAF2@...>
                      Content-Transfer-Encoding: quoted-printable
                      From: Boris Gloger <boris@...>
                      Subject: Re: [scrumdevelopment] stabilization sprints?
                      Date: Fri, 6 Aug 2004 09:21:13 +0200
                      To: scrumdevelopment@yahoogroups.com


                      On 06.08.2004, at 05:12, Mike Cohn wrote:

                      > A good way to make this type of work happen during the sprint is to do
                      > it first. This is part of why I like doing test-driven development. If
                      > a team runs out of time to test, we make sure they don’t by doing the
                      > tests first. Then maybe they run out of time to add one more feature
                      > but that’s better than putting out low-quality, untested software (in
                      > most cases IMO).
                      >

                      I would love to be in such situations that I would have had software
                      development teams who had this kind of engineering practice in the past
                      - wow. I am faced always with software development teams which did not
                      have made their homework. They did not deliver the documentation, or
                      they do not have
                    • Gary F
                      ... My definition of stabilization is a bit different. I think of it applied to projects that are unstable. So it can be large amounts of bugfixing (i.e. the
                      Message 10 of 10 , Aug 8 4:37 PM
                      • 0 Attachment
                        --- Mike Cohn <mike@...> wrote:
                        > Stabilization usually refers to putting the finishing touches on a
                        > product, which often means doing some additional testing and bug
                        > fixing, as well as things I've mentioned before like getting user's
                        > guides or help systems totally in sync with the software.

                        My definition of stabilization is a bit different. I think of it
                        applied to projects that are unstable. So it can be large amounts of
                        bugfixing (i.e. the open bug list becomes the top of the backlog). One
                        would hope that this isn't done near the finish, but on the other hand,
                        I've known products that got released, and desperately needed a
                        stabilization update. There's also the old DEC approach, at least for
                        VMS, in which even numbered releases represented new functionality,
                        while odd numbered releases were primarily bug fixes (i.e.
                        stabilization) releases.

                        Often, the product is unstable because some component is fragile. In
                        this case, refactoring can become a particular approach to achieving
                        stability, but it's not the only one. There are other stabilization
                        tactics, such as going through the entire code base to find memory
                        leaks or buffer overruns.

                        Gary




                        __________________________________
                        Do you Yahoo!?
                        Yahoo! Mail - 50x more storage than other providers!
                        http://promotions.yahoo.com/new_mail
                      Your message has been successfully submitted and would be delivered to recipients shortly.