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

RE: [scrumdevelopment] Dynamic Scrum

Expand Messages
  • 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 1 of 11 , Mar 1 7:54 AM
    • 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 2 of 11 , Mar 2 8:41 AM
      • 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 3 of 11 , Mar 2 9:33 AM
        • 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 4 of 11 , Mar 2 10:10 AM
          • 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 5 of 11 , Mar 3 4:17 AM
            • 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 6 of 11 , Mar 3 4:39 AM
              • 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 7 of 11 , Mar 3 4:12 PM
                • 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 8 of 11 , Mar 4 7:03 AM
                  • 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 9 of 11 , Mar 4 8:35 AM
                    • 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 10 of 11 , Mar 10 7:48 AM
                      • 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.