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

Re: [scrumdevelopment] Dynamic Scrum

Expand Messages
  • 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 1 of 11 , Mar 2, 2004
    • 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 2 of 11 , Mar 3, 2004
      • 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 3 of 11 , Mar 3, 2004
        • 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 4 of 11 , Mar 3, 2004
          • 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 5 of 11 , Mar 4, 2004
            • 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 6 of 11 , Mar 4, 2004
              • 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 7 of 11 , Mar 10, 2004
                • 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.