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

RE: [scrumdevelopment] Dynamic Scrum

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