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

Re: [scrumdevelopment] Dynamic Scrum

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