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

Re: [scrumdevelopment] Dynamic Scrum

Expand Messages
  • Jeff Sutherland
    When Ken and I were working with the first Scrums in various companies it was essential to freeze the backlog for 30 days to get work done. We had no way to
    Message 1 of 11 , Mar 1, 2004
    View Source
    • 0 Attachment
      When Ken and I were working with the first Scrums in various companies it was essential to freeze the backlog for 30 days to get work done. We had no way to manage any backlog change in real time.

      At PatientKeeper we have totally automated backlog tracking. Developers only work on backlog items which have been incorporated into our bug tracking systems. Bugs and development items can be managed simultaneously.

      We are building mobile/wireless systems which have required point releases almost every week while building quarterly major releases. The product managers manage the backlog. In real time, the Product Steering Committee can decide to alter the backlog. This resets all charts and graphs in real time and consequences of delivery date slippage are known immediately.

      As a result, we have moved to a Dynamic Scrum process that everyone feels comfortable with. New clients are coming in at an accelerating rate. We can dynamically change backlog based on the client mix on a weekly basis driven by the Product Steering Committee which includes all key players in the company.

      Dynamic Scrum requires total automation of backlog so current state can be viewed in real time in a single system that everyone uses. Change impact can be seen in real time. This is similar to Cisco's claim to be able to balance their books in real time at any time. It is not recommended without this high level of automation.

      In addition, Dynamic Scrum has incorporated many features of XP. Instead of pair programming, most programmers work full time in a development conference room in a "team programming" mode. This has been extremely effective when multiple layers of the architecture (PDAs, middle tier caching and business logic, backend adapters, and multiple backend systems) must all be altered in concert.

      Jeff Sutherland


      ________________________________________________________________________
      >
      > Message: 4
      > Date: Mon, 01 Mar 2004 04:23:12 -0000
      > From: "grewalhs" <grewalhs@...>
      > Subject: Requirements Changes
      >
      > Sorry, I am new to this mailing list. I tried to search for my
      > question, but did not get any satisfactory results. If this question
      > is already posted, it would be great if someone can send me the link
      > to the thread.
      >
      > I was reading about some basic literature on Scrum and it came to my
      > attention that once a Sprint Backlog is decided, the
      > team "maniacally" works on getting the items done with the commitment
      > from the product owner that new requirements will not be introduced
      > in the current sprint. If there were new requirements, those will
      > addressed in the next sprint planning. Therefore, my question is what
      > happens if there are genuine requirements changes that must be
      > incorporated in the current sprint? Will Scrum allow the sprint
      > backlog to be changed? If not, how is this situation handled? Will
      > some items from the current sprint be tossed out (for now)?
      >
      > Any help will be appreciated.
      >
      > Thanks!
      > H.
    • Mike Cohn
      Jeff-- How does your Dynamic Scrum handle the following situation: The team starts on a sprint (2 or 4 weeks, it won t matter). One of the sprint backlog item
      Message 2 of 11 , Mar 1, 2004
      View Source
      • 0 Attachment
        Jeff--
        How does your Dynamic Scrum handle the following situation:

        The team starts on a sprint (2 or 4 weeks, it won't matter). One of the
        sprint backlog item requires them to tear some guts out of a class or
        sub-system, which they think will take four days. Three days into that you
        want to dynamically shift things around, dropping that item but adding new
        items.

        It seems like the original four-day task goes back to the product backlog,
        the 3/4ths work is thrown away, and delivery dates are now based on what is
        added. Does your automated system do that?

        Thanks,
        Mike



        -----Original Message-----
        From: Jeff Sutherland [mailto:jeff.sutherland@...]
        Sent: Monday, March 01, 2004 6:55 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] Dynamic Scrum

        When Ken and I were working with the first Scrums in various companies it
        was essential to freeze the backlog for 30 days to get work done. We had no
        way to manage any backlog change in real time.

        At PatientKeeper we have totally automated backlog tracking. Developers only
        work on backlog items which have been incorporated into our bug tracking
        systems. Bugs and development items can be managed simultaneously.

        We are building mobile/wireless systems which have required point releases
        almost every week while building quarterly major releases. The product
        managers manage the backlog. In real time, the Product Steering Committee
        can decide to alter the backlog. This resets all charts and graphs in real
        time and consequences of delivery date slippage are known immediately.

        As a result, we have moved to a Dynamic Scrum process that everyone feels
        comfortable with. New clients are coming in at an accelerating rate. We can
        dynamically change backlog based on the client mix on a weekly basis driven
        by the Product Steering Committee which includes all key players in the
        company.

        Dynamic Scrum requires total automation of backlog so current state can be
        viewed in real time in a single system that everyone uses. Change impact can
        be seen in real time. This is similar to Cisco's claim to be able to balance
        their books in real time at any time. It is not recommended without this
        high level of automation.

        In addition, Dynamic Scrum has incorporated many features of XP. Instead of
        pair programming, most programmers work full time in a development
        conference room in a "team programming" mode. This has been extremely
        effective when multiple layers of the architecture (PDAs, middle tier
        caching and business logic, backend adapters, and multiple backend systems)
        must all be altered in concert.

        Jeff Sutherland


        ________________________________________________________________________
        >
        > Message: 4
        > Date: Mon, 01 Mar 2004 04:23:12 -0000
        > From: "grewalhs" <grewalhs@...>
        > Subject: Requirements Changes
        >
        > Sorry, I am new to this mailing list. I tried to search for my
        > question, but did not get any satisfactory results. If this question
        > is already posted, it would be great if someone can send me the link
        > to the thread.
        >
        > I was reading about some basic literature on Scrum and it came to my
        > attention that once a Sprint Backlog is decided, the
        > team "maniacally" works on getting the items done with the commitment
        > from the product owner that new requirements will not be introduced
        > in the current sprint. If there were new requirements, those will
        > addressed in the next sprint planning. Therefore, my question is what
        > happens if there are genuine requirements changes that must be
        > incorporated in the current sprint? Will Scrum allow the sprint
        > backlog to be changed? If not, how is this situation handled? Will
        > some items from the current sprint be tossed out (for now)?
        >
        > Any help will be appreciated.
        >
        > Thanks!
        > H.


        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • J. B. Rainsberger
        ... I don t think this is a PM problem; this is a problem with the mechanics of refactoring. Spending four days ripping out the guts of something is very
        Message 3 of 11 , Mar 2, 2004
        View Source
        • 0 Attachment
          Mike Cohn wrote:

          > Jeff--
          > How does your Dynamic Scrum handle the following situation:
          >
          > The team starts on a sprint (2 or 4 weeks, it won't matter). One of the
          > sprint backlog item requires them to tear some guts out of a class or
          > sub-system, which they think will take four days. Three days into that you
          > want to dynamically shift things around, dropping that item but adding new
          > items.
          >
          > It seems like the original four-day task goes back to the product backlog,
          > the 3/4ths work is thrown away, and delivery dates are now based on what is
          > added. Does your automated system do that?

          I don't think this is a PM problem; this is a problem with the mechanics
          of refactoring. Spending four days "ripping out the guts" of something
          is very risky, no matter what the situation. This task needs to be
          approached much more incrementally, especially if either:

          * the task may be dropped
          * the task occurs near the end of the iteration

          This way if the task must be dropped, then the work done so far doesn't
          need to be thrown away. Obviously, this depends on whether the "gut
          tearing" is a true refactoring or involves adding features that are not
          backwards compatible.
          --
          J. B. Rainsberger,
          Diaspar Software Services
          http://www.diasparsoftware.com :: +1 416 791-8603
          Let's write software that people understand
        • Mike Cohn
          It s nice for us to think that we can theoretically make all changes in small pieces but that isn t always practical. If that were the case it would be simple
          Message 4 of 11 , Mar 2, 2004
          View Source
          • 0 Attachment
            It's nice for us to think that we can theoretically make all changes in
            small pieces but that isn't always practical. If that were the case it would
            be simple for us to stop a sprint at any point but that isn't the case.
            There are often times when a developer is in the midst of something that
            will take a few days to have been worth starting.

            I could give any number of examples but how about a few:

            --I've got a programmer right now who is working on some of the ugliest code
            ever seen. He has a particularly buggy module (set of perhaps 12 classes)
            and he is completely rewriting it. Not refactoring it, rewriting it.

            --The system I'm working on stores data about company retirement accounts.
            When the system was first established it was built with a certain set of
            functionality around payroll processing. Specifically, that a company could
            pick a payroll frequency (monthly, biweekly, weekly) and then stick with
            that forever. After running the system a few years it's clear this is
            woefully inadequate--some companies change payroll frequencies, others have
            multiple frequencies (one set of employees is paid weekly, another group
            monthly), others pay at unpredictable frequencies. This area is being
            rewritten. Until it reaches a certain critical mass, it cannot replace the
            existing system.

            I agree we always want to minimize these changes but there are definitely
            times when a change either needs to be taken forward or thrown away (or
            possibly shelved to be returned to later but will deliver no value until
            then).

            --Mike

            -----Original Message-----
            From: J. B. Rainsberger [mailto:jbrains@...]
            Sent: Tuesday, March 02, 2004 9:41 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Dynamic Scrum

            Mike Cohn wrote:

            > Jeff--
            > How does your Dynamic Scrum handle the following situation:
            >
            > The team starts on a sprint (2 or 4 weeks, it won't matter). One of the
            > sprint backlog item requires them to tear some guts out of a class or
            > sub-system, which they think will take four days. Three days into that you
            > want to dynamically shift things around, dropping that item but adding new
            > items.
            >
            > It seems like the original four-day task goes back to the product backlog,
            > the 3/4ths work is thrown away, and delivery dates are now based on what
            is
            > added. Does your automated system do that?

            I don't think this is a PM problem; this is a problem with the mechanics
            of refactoring. Spending four days "ripping out the guts" of something
            is very risky, no matter what the situation. This task needs to be
            approached much more incrementally, especially if either:

            * the task may be dropped
            * the task occurs near the end of the iteration

            This way if the task must be dropped, then the work done so far doesn't
            need to be thrown away. Obviously, this depends on whether the "gut
            tearing" is a true refactoring or involves adding features that are not
            backwards compatible.
            --
            J. B. Rainsberger,
            Diaspar Software Services
            http://www.diasparsoftware.com :: +1 416 791-8603
            Let's write software that people understand


            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          • Ron Jeffries
            ... It s not appropriate to say that we have to do something when we choose to do it. It would seem likely that any rewrite can be done piecemeal. And
            Message 5 of 11 , Mar 2, 2004
            View Source
            • 0 Attachment
              On Tuesday, March 2, 2004, at 12:33:14 PM, Mike Cohn wrote:

              > It's nice for us to think that we can theoretically make all changes in
              > small pieces but that isn't always practical. If that were the case it would
              > be simple for us to stop a sprint at any point but that isn't the case.
              > There are often times when a developer is in the midst of something that
              > will take a few days to have been worth starting.

              > I could give any number of examples but how about a few:

              > --I've got a programmer right now who is working on some of the ugliest code
              > ever seen. He has a particularly buggy module (set of perhaps 12 classes)
              > and he is completely rewriting it. Not refactoring it, rewriting it.

              It's not appropriate to say that we have to do something when we choose to
              do it.

              It would seem likely that any rewrite can be done piecemeal. And certainly
              any rewrite can wait indefinitely to be plugged in, can it not?

              So I can see no reason not to stop the sprint based on this issue.

              > --The system I'm working on stores data about company retirement accounts.
              > When the system was first established it was built with a certain set of
              > functionality around payroll processing. Specifically, that a company could
              > pick a payroll frequency (monthly, biweekly, weekly) and then stick with
              > that forever. After running the system a few years it's clear this is
              > woefully inadequate--some companies change payroll frequencies, others have
              > multiple frequencies (one set of employees is paid weekly, another group
              > monthly), others pay at unpredictable frequencies. This area is being
              > rewritten. Until it reaches a certain critical mass, it cannot replace the
              > existing system.

              There is a way to replace a payroll system incrementally in almost every
              case. Hint: Does the existing old payroll system accept and apply input
              transactions that add entitlements or take out deductions?

              > I agree we always want to minimize these changes but there are definitely
              > times when a change either needs to be taken forward or thrown away (or
              > possibly shelved to be returned to later but will deliver no value until
              > then).

              I believe quite strongly, based on hindsight, that there are a lot fewer
              such cases than I thought when I was using foresight.

              Ron Jeffries
              www.XProgramming.com
              Testing should be done...
              (a) ...from the beginning of a project.
              (b) ...starting at some point in the middle of a project.
              (c) ...on those who think it should only be done at the end of a project.
              -- A poster spotted at Rational
            • Robert Henley
              ... Speaking for myself, I find it hard to interrupt thinking through a complex issue. There is an intense focus involved in wrapping my head around a complex
              Message 6 of 11 , Mar 3, 2004
              View Source
              • 0 Attachment
                Ron Jeffries wrote:
                > It would seem likely that any rewrite can be done piecemeal. And certainly
                > any rewrite can wait indefinitely to be plugged in, can it not?
                >
                > So I can see no reason not to stop the sprint based on this issue.

                Speaking for myself, I find it hard to interrupt thinking through a complex
                issue. There is an intense focus involved in wrapping my head around a
                complex
                problem. I find it very hard to shift gears, and generally it costs me
                significant time and
                extra work when I have to do so and then go back to the work later.
                Sometimes
                working through such an issue in the code takes me several days.

                I find it similar when a feature is partly done, but not completely working,
                and
                during complex debugging. Those are times when stopping on a dime means
                tossing what's in progress rather than carrying it through. Maybe I can
                resurrect my work later, but most likely I have to recreate the thought
                process that brought me to the point where I left off, and that costs
                effort.

                I prefer the stability Scrum provides for this, except in unusual
                circumstances
                when an Abnormal Termination is called for and work must be discarded.

                So I disagree that incomplete rewrites can be stopped without cost or "wait
                indefinitely to be plugged in." At least not by me.

                Robert Henley
                Software Architect
                Certified Scrum Master
              • Ron Jeffries
                ... I am familiar with the problem. I ve found that working in smaller bites goes better for me, and I suspect that learning to work in smaller bites would be
                Message 7 of 11 , Mar 3, 2004
                View Source
                • 0 Attachment
                  On Wednesday, March 3, 2004, at 7:17:52 AM, Robert Henley wrote:

                  > Ron Jeffries wrote:
                  >> It would seem likely that any rewrite can be done piecemeal. And certainly
                  >> any rewrite can wait indefinitely to be plugged in, can it not?
                  >>
                  >> So I can see no reason not to stop the sprint based on this issue.

                  > Speaking for myself, I find it hard to interrupt thinking through a
                  > complex issue. There is an intense focus involved in wrapping my head
                  > around a complex problem. I find it very hard to shift gears, and
                  > generally it costs me significant time and extra work when I have to do
                  > so and then go back to the work later. Sometimes working through such an
                  > issue in the code takes me several days.

                  I am familiar with the problem. I've found that working in smaller bites
                  goes better for me, and I suspect that learning to work in smaller bites
                  would be good for most everyone.

                  I have observed many programmers working on "big complex problems". What
                  most of them were doing was working on big complex /programs/, which they
                  themselves had written.

                  > I find it similar when a feature is partly done, but not completely
                  > working, and during complex debugging. Those are times when stopping on a
                  > dime means tossing what's in progress rather than carrying it through.
                  > Maybe I can resurrect my work later, but most likely I have to recreate
                  > the thought process that brought me to the point where I left off, and
                  > that costs effort.

                  A situation calling for complex debugging is, in my opinion, in most cases,
                  a situation where the program in question needs rewriting /again/. Good
                  code, in my experience, doesn't need complex debugging. Complex debugging
                  connotes complex code, which is more often than not (by a wide margin in my
                  estimation) a result of poor understanding, not of the inherent complexity
                  of the problem.

                  Doubtless there are exceptions. Most of the complex debugging in the world
                  is not, however, aimed at one of the exceptions -- just at crummy code.

                  > I prefer the stability Scrum provides for this, except in unusual
                  > circumstances when an Abnormal Termination is called for and work must be
                  > discarded.

                  I understand. I, too, have often wished for stability. I've found that
                  learning the ability to do big things in small steps has been more valuable
                  to me. I believe that it'd be more valuable to other folks who currently
                  feel the need for stability, but of course I could be entirely wrong. It's
                  just that I'm not. ;->

                  > So I disagree that incomplete rewrites can be stopped without cost or "wait
                  > indefinitely to be plugged in." At least not by me.

                  Yes. My point is that complete rewrites need not be done all at one go, and
                  that doing a rewrite all at one go is hardly ever a necessity. Further, in
                  my opinion, doing a big rewrite all at one go is almost always a mistake.
                  As such, I could imagine interrupting a scrum SOLELY to kill off such a
                  mistake.

                  Imagine. Suppose everyone's code had to be committed to the main line every
                  day. No one could ever make a mistake bigger than a day. Wow.

                  Ron Jeffries
                  www.XProgramming.com
                  If not now, when? -- The Talmud
                • Mike Beedle
                  I think this is why a 30-day Sprint also works best for most. It allows us technical people to really concentrate on what we are doing. As
                  Message 8 of 11 , Mar 3, 2004
                  View Source
                  • 0 Attachment
                    Message
                     
                     
                    I think this is why a 30-day Sprint also works best for most.  It allows us technical people to really
                    concentrate on what we are doing.
                     
                    As developers/architects/programmers *we strongly value* the time that people allow us
                    to have for technical work.  Although we value planning, tracking, estimation, customer interaction,
                    developers interaction, testing, integration, release management, etc.; we don't want to be interrupted
                    or distracted from our technical work so often that it makes it impossible to complete quality work,
                     
                     
                    - Mike
                     
                     
                    Robert Henley  wrote: 
                    Speaking for myself, I find it hard to interrupt thinking through a complex
                    issue. There is an intense focus involved in wrapping my head around a
                    complex
                    problem. I find it very hard to shift gears, and generally it costs me
                    significant time and
                    extra work when I have to do so and then go back to the work later.
                    Sometimes
                    working through such an issue in the code takes me several days.

                    I find it similar when a feature is partly done, but not completely working,
                    and
                    during complex debugging. Those are times when stopping on a dime means
                    tossing what's in progress rather than carrying it through. Maybe I can
                    resurrect my work later, but most likely I have to recreate the thought
                    process that brought me to the point where I left off, and that costs
                    effort.

                    I prefer the stability Scrum provides for this, except in unusual
                    circumstances
                    when an Abnormal Termination is called for and work must be discarded.

                    So I disagree that incomplete rewrites can be stopped without cost or "wait
                    indefinitely to be plugged in." At least not by me.

                    Robert Henley
                    Software Architect
                    Certified Scrum Master



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



                  • Bradley Singletary
                    Out of curiosity, does anyone s sprint length vary due to the length of a contract? i.e. If you ran a 3 month contract, would you stick with 3 sprints, or use
                    Message 9 of 11 , Mar 4, 2004
                    View Source
                    • 0 Attachment
                      Out of curiosity, does anyone's sprint length vary
                      due to the length of a contract? i.e. If you
                      ran a 3 month contract, would you stick with 3
                      sprints, or use 6.

                      Or does most of the discussion on sprint length apply
                      to product scale development, where the durations
                      might be 6 months to 2 years? I assume that there
                      would be minor variance in sprint lengths in either
                      case.

                      Thanks,

                      Brad

                      On Wed, 2004-03-03 at 19:12, Mike Beedle wrote:
                      >
                      >
                      > I think this is why a 30-day Sprint also works best for most. It
                      > allows us technical people to really
                      > concentrate on what we are doing.
                      >
                      > As developers/architects/programmers *we strongly value* the time that
                      > people allow us
                      > to have for technical work. Although we value planning, tracking,
                      > estimation, customer interaction,
                      > developers interaction, testing, integration, release management,
                      > etc.; we don't want to be interrupted
                      > or distracted from our technical work so often that it makes it
                      > impossible to complete quality work,
                      >
                      >
                      > - Mike
                      >
                    • J. B. Rainsberger
                      ... I operated a 10-week contract this way: 3x2 weeks, then 4x1 week. As we got closer to the end, we increased the rate of delivery and feedback so that the
                      Message 10 of 11 , Mar 4, 2004
                      View Source
                      • 0 Attachment
                        Bradley Singletary wrote:

                        > Out of curiosity, does anyone's sprint length vary
                        > due to the length of a contract? i.e. If you
                        > ran a 3 month contract, would you stick with 3
                        > sprints, or use 6.

                        I operated a 10-week contract this way: 3x2 weeks, then 4x1 week. As we
                        got closer to the end, we increased the rate of delivery and feedback so
                        that the customer could steer more precisely. We did this mainly in
                        response to the fact that we were not going to deliver everything we
                        expected to deliver and we wanted the client to have maximum flexibility
                        for choosing the last four weeks' worth of features.

                        <snip />
                        --
                        J. B. Rainsberger,
                        Diaspar Software Services
                        http://www.diasparsoftware.com :: +1 416 791-8603
                        Let's write software that people understand
                      • Jeff Sutherland
                        In my previous not on Dynamic Scrum it may not have been apparent how we handle loose ends, how the product owner manages the sprint backlog, and other
                        Message 11 of 11 , Mar 10, 2004
                        View Source
                        • 0 Attachment
                          In my previous not on "Dynamic Scrum" it may not have been apparent how we handle loose ends, how the product owner manages the sprint backlog, and other features that deal with a multitude of issues raised yesterday on the list, in a completely transparent way.

                          1. Any issue an any time can be entered by anyone into our Scrum tracking system. I have worked hard to keep this totally open. If anyone bitches from the field they are not getting something they need, they are asked where are their entries in the Scrum tracking system. It they are not there, they are told to stop bitching and start using the system. If they object to priorities, they are told to work it out with the product owner who owns the priorities. This has eliminated a huge amount of noise.

                          We use the open source GNATS bug tracking system modified with a very few extra fields for this. So it just looks like a bug or task. The "bug" or "task" initially goes into a Triage category not attached to a release milestone.

                          2. The product owner (Product management in our case) manages issues out of the triage list. She consults with the Director of Engineering so development needs are always a key priority. "Bugs" or "Tasks" are move out of Triage into a Release Milestone on a daily basis.

                          3. The current Scrum works on tasks in the current Release Milestone. The product owner can move "Bugs" or "Tasks" in or out of the current Scrum as appropriate to meet changing needs or requirements. Since the tracking system automatically generates charts and graphs every day that are sent to everyone, this is a highly visible action and impact on dates can immediately be seen, as well as who in development has become a new bottleneck on the critical path.

                          4. Since the action of the product owner is so highly visible to everyone, including its impact on delivery dates, it may cause management to scream, development to scream, sales to scream, or client services to bitch. As a result it becomes a somewhat democratic process which culminates in a weekly Product Steering Committee. Every key person in the company is at that meeting. The meeting is led by the product owner and the CEO is the tie breaker on hot issues.

                          As a result of this open process, the product owner is very deliberate in what she does, and carefully balances competing needs.

                          5. Developers only work on tasks assigned to them for the current release milestone. This is the first thing they look at in the morning and the last thing they update at night. The tasks are specified as high, medium, or low priority. The developers prioritize their own work given the list they see.

                          6. If new tasks appear that need updated user stories, the developer simply reassigns the task back to the product leader for feedback.

                          The bottom line is that all of this has become so transparent and routine, that most of the questions about how to prioritize things or where to add them have just vanished. The "Dynamic Scrum" has become part of the corporate culture. High noise level and high energy clashes are confined to a one hour Product Steering Committee meeting once a week among key players.

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