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
      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

      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

      - 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.