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

Re: [scrumdevelopment] Scrum for buses

Expand Messages
  • Stephen Haberman
    ... Okay, I ll give it a try. I don t think the constant distance idea is good. It s a planned approach and would just slow the buses down even more (e.g. all
    Message 1 of 2 , Sep 30, 2003
    • 0 Attachment
      On Tue, Sep 30, 2003 at 07:26:08PM -0600, Mike Cohn wrote:
      > So, how would Scrum alter bus scheduling?

      Okay, I'll give it a try.

      I don't think the constant distance idea is good. It's a planned
      approach and would just slow the buses down even more (e.g. all
      buses would be delayed by any stoplight any bus hit instead of just
      their individual stoplights).

      [Okay, upon rereading this, the constant distance might actually
      improve human flow, despite the slower bus speed; it seems
      unintuitive, so would have to be simulated or what not]

      Scrum is an empirical process: frequent inspection and adjustment.

      So, my rough guess is to let the buses go freely and then every
      10/15 minutes take a poll (either manually or via GPS), see where
      the buses are at, and create a new solution specific to that
      situation.

      There are probably typical problems, e.g. too big of a gap between
      individual buses or a group of buses traveling together.

      For each typical problem, you could probably develop a set of common
      solutions for each problem, just as a ScrumMaster has a general set
      of common solutions for problems in software development (though
      granted the ScrumMaster does a lot of tailoring to specific
      situations and adding of their own solutions).

      So lets say several typical solutions are:

      - If you have two buses half-full lined up behind each other, have
      one unload (giving its passengers to the other bus) and have
      the unloaded bus turn around to deal with demand in the other
      direction.

      - Or have one of the buses sit a stop for 5/10 minutes.

      - If you have a large gap between buses, perhaps have a variable
      number of buses in service and bring in more to respond to demand.
      E.g. 2 or 3 buses sit out at certain spots along the route and
      then can dynamically be brought in to respond to gaps between
      other buses.

      I dunno; I hesitate in suggesting an algorithm could be developed.
      An algorithm could equate to a plan, which is bad in Scrum. But the
      algorithm could also be equated to a process, e.g. Scrum itself, and
      be something the bus system carries out to psuedo-empirically
      respond to situations.

      Granted the job of a ScrumMaster can't be put in an algorithm, but
      I'm tempted to think that the bus-routing domain is a lot simpler
      than software development (even though it is chaotic as well).

      I'm sure others have thought lots more about bus-routing than I, and
      had much better solutions. That's just my Scrum-based take, per
      your original question.

      - Stephen
    Your message has been successfully submitted and would be delivered to recipients shortly.