What can development teams learn from Copenhagen buses?
Foreword: Thanks to my good colleague Vadym Volkovynskyi for the analogy that I use in this story.
CHAPTER 1: A tale of two bus lines
Do you recall the country that is always on the top of the world happiness and life satisfaction indexes? Yes, we are talking about Denmark, and to be precise the capital city of Denmark, Copenhagen! This wonderful city had a famous bus line, 5A, that served the capital between 2002 and 2017. It was the first A line (special line that runs more frequently and it has many bus stops with relatively shorter distances) bus, and its route was relatively long, passing through the city center in the middle of the route. Besides, it was the busiest bus line of the whole country, carrying more than 20 million passengers every year.
The buses used in the line were regular sized (13.7 meters), and the passengers would enter from the front door, exit from either the middle door or the rear door.
As it was the busiest bus line, you would occasionally read in the newspapers various optimization suggestions from the experts — not selling ticket on the bus, different door entry/exit combinations, route optimizations, etc. Besides, there were many attempts to observe other cities and experiment with different set ups in order to ease the capacity problems, especially in the rush hour.
After years of experimentation, line 5A was transformed to line 5C in 2017. C-line was new, indicating city line concept, and 5C is the first example of a C-line. It was a transformation (!) like the agile transformations or cloud transformations that you can hear frequently these days. New bus type, more seats (147 instead of 82 in 5A) and space, more doors, new entry/exit combination (all 5 doors could be used for entry/exit), dedicated bus lanes in some parts of the route, option of checking in/out the using the card readers in the bus stop, rather than doing it using the card readers inside the bus, biogas engine, and more!
Years of research and experiments, longer buses with more doors and more seats, environment-friendly engine; what was not to like? Sadly, the buses reported two major problems: delays and accumulation of two-three buses in succession (a.k.a. bus bunching).
These were not new problems to be fair, as 5A was notorious with both of the cases. However, the problems got magnified with the transformation from 5A to 5C.
The author of this article together with the originator of the analogy, Vadym Volkovynskyi, experienced both of the problems by first hand. They would wait in the bus stop for longer time (compared to before) in the cases of delay, and when the bus showed up, it would often be followed by one or two more 5C buses. In other words, upsetting the passengers (a.k.a. clients) and making them miss the 5A (the previous product), even though it was notorious with the same problems, just not as bad as 5C (the new product).
CHAPTER 2: Poppendieck family brings the learnings from the lean manufacturing to the software world!
A year after the 5A line was launched, Mary Poppendieck and Tom Poppendieck decided that the time had come for a new paradigm in the software industry and published their book, “Lean Software Development: An Agile Toolkit”. It was transferring and adapting the learnings from the Lean Production — that was Toyota’s approach to manufacturing — to the software development world. Of course, there is much more to that, and interested reader can find a faithful account of the history in the recently published doctoral thesis of Liv Gingnell (chapter 4).
No, Poppendieck’s are not among the signatories of the Agile Manifesto (2001, Utah) but their contribution to the Agile world is undeniable.
Among other things, Lean Software Development was focusing on reducing waste and improving flow.
But, what is flow? It is flow of software, value, solutions, and of course BUSes!
How do we improve the flow? Among other things, we reduce the batch size and reduce the cycle time! Smaller batch size means, faster delivery of the result and faster feedback. Shorter cycle time means, non-value adding waste is eliminated so that the time between client’s request and the delivery of the solution being reduced.
Having said that, and thanks to Eiler Læssøe Møller, a degree of effort will often be made in order to get wiser and produce a better solution, and exactly what is waste and what is not waste is not always obvious.
“The fundamental mental shift that lean requires is this: flow efficiency trumps resource efficiency almost all of the time.” Mary Poppendieck
At this point we should also mention Donald G. Reinertsen, who is one of the pioneers that studied the flow topic deeper, which was until then basically a topic of discussion that was brought by Lean world but not elaborated. Reinertsen started publishing about “development organizations moving from distinct development phases to continuous flow with overlapping activities” and “introducing queuing theory to product development” in the 90s.
CHAPTER 3: What does 5C and Poppendieck’s have in common?
A decent software company would pay attention to improve ways of working and helping their employees, who are all talented and good at what they are doing, in understanding how to optimize globally and delight the customer.
In this quest, and thanks to the guidance from our agile coaches, we have started rolling out workshops (designed by Frank Olsen) where we refrained from teaching/lecturing anything, instead focusing on facilitating a common understanding of flow for our scrum teams. And while thinking of creative examples to demonstrate flow (in this case a flawed flow), my colleague Vadym Volkovynskyi and I found this bus transformation that affected our daily lives as a useful analogy. Let us tell you the story:
With the replacement of 5A buses with 5C, where the buses are longer with more seats, the buses started to get even longer delays in the bus stops. This has multiple root causes, some of them being the slowed maneuvers of the long buses and longer times for entry/exit to the buses.
When a bus (B1)gets delayed, the following bus (B2) actually catches up the delayed bus B1 somewhere in the route. That is partly because, as B1 is waiting for collecting all the passengers from a stop, not many passengers are left for B2 to collect so it spends less time in the stops. Often there would be a third bus also catching up (B3) because it will have even fewer passengers to serve.
Remember the batch size? We want it to be smaller, right? How about 5C, it got much bigger. Remember the cycle time? We want it to be shorter, right? And for a passenger to be transported from stop A to stop B, got longer in this case — even if you omit the bus bunching effect, it was due to the limited maneuver abilities of the new long buses.
CHAPTER 4: What can we learn from 5C?
Here is some of the things that can help your skilled colleagues think about the flow, inspired by the Copenhagen’s busiest bus line:
- The client wouldn’t be happier if you send her a bigger, spacier solution (in this case 3 buses, two of them being almost empty) if the solution arrives late.
- The client wouldn’t appreciate those loads of functionality that you deliver (in this case, more space, more check in options, environment-friendly engine, etc.) if you fail satisfying her main needs.
- It is a good way of losing clients, to release intermittently with a non-constant flow.
- More rapid flow of value, is better even though it doesn’t have all the bells and whistles (5A was a very crowded bus, but got less delayed).
- Resource efficiency is the mindset that needs to be replaced with flow efficiency. In the bus case, having all the fleet on the route does not help if buses are bunching in threes where two out of three are not carrying passengers. In the development case, having all your employees fully utilized and busy with work does not make sense, if the client is not getting constant value in shorter time.
Acknowledgements
Thanks to Vadym Volkovynskyi, the public transformation system in Copenhagen, all the thought leaders from lean and agile community, enthusiastic scrum teams of SimCorp, many great colleagues including but not limited to Frank Olsen, Piet Syhler, Neil Cook, and Iuliia Gumeniuk.
