Re: [scrumdevelopment] Scrum for buses
- 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
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.