The Magic Bus or BustrophobiaWritten by Steve Blais
Back in the day, The Who, a British Rock group consisting of Roger Daltrey, John Entwistle, Pete Townshend and Keith Moon wrote and sang about a Magic Bus that would carry the singer to his girlfriend’s house. The Beatles another British Rock group of the time also sang of a bus on which a Magical Mystery Tour would roll on. And Paul Simon sang of looking for America on a cross country Bus. Ken Kesey took his Merry Pranksters across the United States on a Magic Bus and Tom Wolfe described the bus and tour in The Electric Kool Aid Acid Test. During the days of the nineteen sixties and seventies the bus metaphor was a positive thing.
Today we have a Mysterious Bus that seems to prowl the roadways of IT searching to run over the best and brightest of IT workers. In project risk identification the bus reappears as an apparently valid concern as someone will ask, “What if our lead analyst were run over by a Bus?” It appears to be the same Bus that runs over these people regardless of where the project takes place. It’s a Bus that really gets around, targeting the more experienced members of the team or the members who have a specialized and usually irreplaceable skill. The Bus seems to be quite finicky as well, since it never takes after anyone but IT people.
In the agile world this Bus has earned a different status: the Bus Ratio. The Bus Ratio measures the number of people on your team who could be wiped out by that Menacing Bus without seriously damaging the project. The higher the ratio, the better. In other words, when a team has a high Bus Ratio knowledge and skill are shared among the team so that each team member backs up the others and is similarly backed up. In many traditional teams, the Bus Ratio is low signifying a tendency toward job security over team sharing such that if one person got hit by The Bus there would be a significant loss of organizational memory and skill set requiring a retooling of the team and an immediate call to the recruiters. The message of the Bus Ratio is clear whether you are agile oriented or not: share the ride.
What is interesting about the Bus Ratio is its application solely to the development team. The same team that is concerned about a high Bus Ratio among the team members, is adamant about maintaining only “One neck to wring” on the business side meaning one and only one Product Owner. The Bus has special radar that searches only for developers. There seems to be no concern that a Wandering Bus might happen to wipe out a Product Owner as collateral damage while hitting a developer head on. Either the agile community values the developers much more than the Product Owner, or they assume that the Product Owner’s knowledge is so common that anyone else from the business can step in after the Bus takes its toll.
That Bus is also apparently on call for the politicians on our teams and in our offices. When things start to go wrong, or “Go South” as the phrase is stated – which brings up another question: why would heading in a southerly direction indicate one is having problems? - someone decides to duck the blame or responsibility by throwing someone else “under the Bus”. The Terrorizing Bus will always happen to show up just in time for someone to be thrown under it. The assumption seems to be that once the unwilling team member is thrown under said Bus that person is not heard from again, lost perhaps in some metaphysical science fantasy plot wherein they become the Bus driver and seek other Bus victims.
Of course the one ducking the responsibility and throwing a compatriot under this Busy Bus might get caught and in that case the person is Bus-ted, an appropriate phrase all things considered.
So it is not surprising when a colleague in a agile team coaching role was recently met with silent stares when she used the phrase “we all need to get on the team bus”. She was referring to a sports team bus traveling to away games, especially in High School and College. The analogy was that if you want to play you have to get on the Bus; otherwise you are not on the team. A good analogy as long as the team members do not suffer from bustrophobia. (I did not make this word up. It is in the annals of psychology and relates to a perceived loss of control). It is hard to get people on a Bus when that Bus has been known to be cruising the streets waiting to run you down.
I should put in a bit of a disclaimer. Due to increasing pressure from those among us who feel that the Bus Metaphor is too negative – referencing violent death, for example – and the protests from the Bus Driver’s Union and various cities Public Transportation Departments who claim that Busses in general have a bad enough reputation, the new replacement metaphor to be politically correct is the lottery. The ratio becomes the Lottery Ratio which asks the question how many people on your team can win the Lottery and the team will still function? Of course this assumes that anyone winning the Lottery would quit their job and that the odds would allow for multiple Lottery winners. Then again, other than disallowing team members to cross the street there is no way to prevent the Itinerant Bus from striking the unsuspecting developer, but the organization can prohibit the purchase of Lottery tickets by members of the same team to reduce the risk of the Lottery Ratio. Of course I’m not sure if throwing someone under the Lottery makes sense to avoid blame, so another metaphor will be in order. Then again, when Gamblers anonymous hears about the Lottery Ratio, we will have to come up with another politically correct metaphor.
So the message is clear: to avoid bustrophobia keep BUSy, follow the syllaBUS, do roBUSt work, avoid aBUSive people, learn everyone else’s BUSiness for backup purposes, don’t combine comBUStible components, and most importantly: look both ways before crossing the street.
Don't forget to leave your comments below.
Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.