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

Re: [scrumdevelopment] Dynamic Scrum

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.