BBC News has more of the details about the experiment undertaken by Transport for London (TfL) in attempt to improve the journey of 50 million customers who pass through Holborn underground station each year. For those not used to the London Underground system, the basic protocol is standing (or riding) passengers to keep to the right while impatient passengers (like me) walk or run (not like me) up the left hand side.
By encouraging all customers to ride the escalator in both streams they were able to use the full capacity of the system, reduced turbulence of customers trying to get into the right lane and improved flow. For some it may seem counter-intuitive and for others who are used to flying up the fast lane they will find their journey a little slow. As a whole, however, the experience and speed through the station improved. Apparently, according to the report of BBC Radio 4’s Today programme, this way of working was found to be the norm when similar studies took place in other parts of the world, such as China.
In delivering software products to market the Lean and Agile movements have brought many benefits to the way work is managed. One of the underlying principles is to help work flow, precisely what TfL were trying to achieve, but this is often forgotten by software teams and the wider organisation.
In order to achieve improved flow TfL have to have a member of their staff at the foot of the escalator to “help” people use both lanes. Signs, rules or even intuition are not good enough and very quickly people begin to fall back into old ways of working. In a Lean and Agile world we need effective scrum masters to do this, to help orchestrate the day to day ceremonies and to remove the blockers. When the role becomes less effective or disappears, teams very quickly fall back into chaos.
TfL saw there were two channels for customers to flow through. One, the standing channel, formed big queues at peak times but the other, channel, although fast for the individual, was under utilised. There’s often a temptation to try to force this with software teams: one or more “steady” teams or stream and a “fast” stream to get things done quickly. Or, sometimes, there’s a move in organisations to encourage, motivate or even force “slower” teams to come up to the same throughput levels as the fast one. Clearly, if this had been tried on the underground, with all passengers having to walk or run up the escalators there would have been mayhem and fatalities.
It’s the simple and sometimes counter-intuitive things that often make the difference. Helping work flow is the responsibility of the organisation and management within it and small changes can often make a big difference.