It is commonly accepted wisdom that agile development is an IT thing, now making its way out into “the business”.
But it appears to me that the bus drivers in a city called Perth went agile without the IT guys showing them the way.
(warning – this is a bit of a long read).
According to the generally accepted history of agile, the agile movement was born on agile mountain in February 2001 when 17 “anarchists” went up the mountain and came down agile.
There is some dispute about the actual detail – did they go skiing while they were there? Did they drink wine or just Jolt Cola?
For example – One of the key fundamental questions is “did they really say documentation is bad and that agile people must refuse to document anything or they will incur terrible agile wrath”?
Actually I guess that one is solved since they published a document called the Agile Manifesto that got the whole agile thing started … and the manifesto is clearly a document. I can and will debate what agile means and how different generations and tribes of agilstas have interpreted this great text.
But enough ancient history. Let’s jump forward to modern times.
According to the perceived wisdom of agile you should build stuff in sprints rather than stupid waterfall. That is kind of the point of agile – short, sharp sprints to incrementally add value.
You can definitely use agile for non-IT work … but there should be fortnightly sprints and a daily stand-up.
Actually you can be agile in non-IT but you also need a Kanban wall to be one of the cool agile teams and the latest rage in agile is to use social contracts to ensure agile goodness among the diverse team members.
So on that basis you could do an agile taxi service – as long as you sprint all over the place with passengers.
But running a bus service agile would be really bad.
The passengers would all get really upset when the driver stopped for a 15 minute meeting with the other drivers to say “yesterday I drove the 378 and today I am driving the 72 Express”.
Plus you would not have a fortnightly “sprint planning” session with all the drivers to select what buses they are driving and then take all the trips out of the backlog and put them on the story wall.
Even worse, what would the regular showcase look like – a bunch of photos of happy passengers? Maybe with the odd video of a really sad passenger who was on the wrong bus?
Well not everyone agrees. [warning – sales plug for some of my partners]. I sat through “Business Agility Accelerator” with Pat Reed as part of the SoftEd agile offering. It was a great course and you should definitely click here to do lots of other agile courses with SoftEd.
But Pat didn’t really seem to understand the official history of agile. There was barely any mention of IT, there was no talk of sprints and certainly no discussion of stand-ups.
Instead there was lots of talk about value and creating the right ecosystem to allow well-meaning people to become agile.
That is probably OK because the course is for “business people” – Ie those less agile partners of IT who might be scared if they were exposed to the whole agile mindset, way of working and process all at once.
So we can send business people to a gentle introduction to agile and then they can learn the core stuff when they work with their local agile IT team. Everyone wins.
Or so I thought.
I am running a course on “the fundamentals of agile” for agile teams in Perth, Western Australia.
Due to cost cutting I am catching buses rather than our usual trainer limousines … and the experience has given me time to reflect on what agile is.
According to the “business view” of agile there is no point in a team being really efficient if they are not adding business value. So rather than sprinting everywhere really fast, they should stop to wonder why they are sprinting anywhere at all.
Same as buses I guess – they can go really fast but I don’t want to catch a fast bus in the wrong direction. Obvious, but in fact that is not the point.
In Perth, unlike a lot of places I have been, there has been some thought as to why the buses exist at all.
Apparently buses in Perth exist to “get the people of Perth where they want to go.’ (according to their website anyway).
I guess the assumption is that they want to go somewhere in Perth, or they would be flying in a plane.
Think about it though – if that is their value … then should they make a profit?
In Sydney (also in Australia) there seems to be an unspoken assumption that we should make a profit from public transport.
Since, of course we don’t – maybe there is something wrong with the way the transport people are doing things.
If we can’t make a profit out of the city’s buses then at a minimum we should focus on running the buses as cheaply as we can, because making a bigger than necessary loss is just bad business.
Interestingly, in Perth they run buses for free in the central city (and trains too). This is clearly stupid if they want to make a profit.
In Perth though, the point is not to make a profit, nor to “minimize costs” even if both of these would be great.
The point of public transport is to get people where they want to go … in a way that frees the city from congestion and makes it easy for people to get around.
This means that people can get on with other things that add value to the city.
With this in mind they I guess it makes sense to have free buses in the city if (and only if) the value of doing so (for the people of Perth) exceeds the cost of having to pay rates and taxes to maintain the buses (which, after all, is paid for by the people of Perth).
It also makes sense to charge for the rest of the bus trips – since the people of Perth don’t want to subsidize personalized super-buses for each other. They want to use prices to understand and respond to demand, getting the users to pay for some of the value they receive while never expecting to actually make a profit out of it.
So they started with value and worked out what to do based on that.
This is where most agile people would claim you should start. Agile is not about going fast, it is about adding value without creating pointless waste. That is why agile is not actually anti-documentation, it is more about “document-only-if-worthwhile”.
So far so good, but lets face it, bus drivers are not really as agile as us IT folk. They can start with value but how much further can they take it.
These are bus drivers not Ruby developers – they could never understand Kanban, Silicon Valley, personas and so forth.
Or so I thought.
In Perth they actually do have “kanban on the buses:”
Here is a “Kanban” board for a free bus – showing expected time until you can get a bus as well as a pretty clear picture of what you are getting when you catch it – there is a map and a documented set of stops. That is a bit better than what I see some IT people put up on their Kanban-Wall-of-Agile-Glory.
They also have other kanban boards at the bus station showing all the routes and bus timetables … and when I got off the bus there was another simple sign to tell people which buses stop at that stop and (you cant really see it here) when they should come.
OK – I am just stretching the title of Kanban a little – these things are not really a story walls with “in development,” “in testing” and “done”. That would be a bit dumb since all the buses are already in production.
Yet let’s be fair – the story wall is a tool that helps the interaction of the team … so the team can add value.
So this is a Kanban wall if it helps the team add value – and in the weird mind of the bus drivers of Perth they are not a stand-alone vendor but part of the team, along with the passengers.
You don’t believe me since we all know bus drivers drive and passengers ride. Drivers are responsible for driving the bus where it should go and passengers are responsible for knowing where to go.
No collaboration is needed – it is just as if someone said that developers are part of the business and they need to collaborate daily with “business people” when the obvious fact is that the developers know how to code and the passengers business know where they want to go.
So it appears that bus drivers might inadvertently be using some agile things without really knowing what agile is.
Could they actually do real agile though?
If so I would expect to see personas and the latest in agile coolness – the social contract.
And can passengers really be part of the team? I don’t pay for my ticket so I can help drive the bus.
Well, here is something really odd.
In Perth they do have personas at the bus stop. They even publish a team social contract to help passengers add value while on the bus.
Here are two personas I saw at the bus stop. I apologize for the poor photography but that is a reflection of my legacy technology and my poor photo-taking. These are, I believe, actually personas:
In fact here are about 45 or 50 more personas.
It is a bit confusing that you would need a persona to drive a bus so let me explain.
In Perth the agile bus drivers believe that bus drivers and passengers should travel together daily throughout the year.
They also believe something else – the customer experience on a bus is not just about the bus driver sprinting them between stops … it is also about the experience the passenger has on the bus.
Interestingly in Perth they think the experience you will have on a bus is partly about the seats and partly about the rapid sprinting to your destination … and also partly about the behaviour of the other passengers.
This is why they have personas.
They probably tried providing long list of rules like “passengers are instructed not to punch other passengers because that is really rude” and “concession fare holders must absentify their seats if a full paying or less abled passengers is of a higher seat allocation priority and is in direct requirement of a seating allocation”.
But instead they thought that if they share stories with the passenger (and each of the 49 personas has its own story) then both passengers and drivers could think for themselves and act like civilized people.
Indeed, if you catch a bus in Perth you will notice that people say “good-day” (or at least g’day) to the driver and “bye” when they get off. Drivers also say hello and goodbye.
Just to make sure though, they even use passenger charters to share their expectations with the public instead of printing a long list of rules on the bus.
Here are two examples
In the second charter I learned that you are not allowed to eat on the bus (which I knew already), but I also learned that after 7pm I don’t need to wait for a bus stop to get off. I can just tell the bus driver where to stop and he will let me get off there. I didn’t expect that one.
For a better picture of the charters you can probably find something on the website again.
So are they agile?
I don’t think the bus drivers were given the money to go to a ski resort and discuss agility for a few days, but they do seem to get it. And I don’t think they checked with the IT guys – I think they invented bus-agile all on their own.
And they did this in secret – while I was off trying to convince “the business” to listen to “the agile guys in IT”. No manifesto of bus delivery and no delivery of bus experiences through sprinting or through showcases at the end of each trip.
So Kudos to the crew who bring the agile buses to Perth (and trains and the odd ferry I assume). I think they have created an agile approach to public transport.
In fact I think the IT crew might be able to learn something from the way they did it.
James King 