My friend Greg Brougham, a deep thinker, sent me his personal notes on last week's UK Lean / Kanban conference which he says were "not comprehensive", but based on what he thought was interesting. I thought they were interesting too, so I asked if I could share them.
Day 1
A bit of SCRUM bashing was going on the first day but this is likely to be due to most practioners having moved to Kanban from SCRUM practices and therefore they only have this as a baseline. Aside - Chris Matts comic is interesting as it provides an introduction to real options as applied to software development but it also covers ideas from Accelinnova’s book Stand Back and Deliver. Day 2 On the second morning David Anderson (see http://www.agilemanagement.net/Articles/Weblog/blog.html), introduced the Lean Software and System Consortium (www.leanssc.org), a non-profit organisation that is being established with the remit collecting the body of knowledge. Mary Poppendieck, who along with her husband Tom wrote the first book on the application of lean to software development, talk was interesting as it asked the question how did they plan delivery in 1929 before we had MSP. The answer was to focus on flow and the example she gave was of the empire state building for which the core went up in 8 months (steel work, concrete and limestone cladding). It is interesting to note that no building has gone up so fast since then as there were no major build for the following two decades until after WWII and the skills were largely lost. The original worksheet from the 1930 is what we would refer to as a cumulative flow diagram. The concept of flow is key to lean/kanban approaches and is not new as it can also be seen in early software development such as that of Visa’s first BASE1 system (see Dee Hock's One From Many). Allan Shalloway is the principal of NetObjectives an agile and Kanban training company. He asked how long it was take for a development team to complete the task again - the answer is usually of the order of 25%. The implication is that development involves learning but we typically don’t acknowledge this in the way that we approach development as we attempt to treat it as a deterministic process. John Seddon is the head of Vanguard a systems thinking consultancy and has authored a book on systems think in the public services. His talk later in the day didn't disappoint and he was quite scathing of most organisational lean initiatives and particularly of the UK governments attempts. His experience is that managing for cost leads to functional specialisation which in turn leads to increase in ‘failure demand’ (inability to satisfy the customer’s request initially) which in terms leads to increased costs. His approach is based on a bounded systems approach and he mentioned the example of one of his clients who has gone from 144 offshore staff to 22 on shore handling all new business. This was done by focusing on the core activities which lead to the training time being cut from 8 to 2 weeks along with pull based training for the less frequent activities. What was disappointing was for someone who slammed the lean people for focusing on tools he did not mention how he approaches this. Day 3 Don Reinertsen is a former McKinsey consultant is largely credited with bringing lean thinking to product development. His talk covered the science as he believes lean has been a largely science free as it is empirical in nature. His contention is that there a lot of relevant material and there is a sound scientific basis for many of leans practices - queuing theory, traffic flow theory etc. He outlined the value of variability as options allow us to exploit the asymmetric nature of the outcome to improve the upside (this is how options work in the financial markets!). His closing comment was that we have a lot of relevant material in computer science space (operating systems queuing) but as an industry we don't apply it to our processes to manage the non-repetitive and non-homogeneous nature of development. Hal Macomber is involved in the lean initiatives in the building industry. This is well establishing on the building side with the Last Planner but the design side is still work in progress. It would appear that they have added some science and essentially developed their own variant of lean. They are also exploring new forms of commercial contract that incentives reliable workflow (used first on Heathrow term 5) as this allows them to move from task, to system to organisation optimisation. He commented that planning, execution and control have to be integrated which is at odds with what the PMI teaches (his quip was that not many people in the construction industry are members of the PMI!). For an overview on lean construction see - http://www.leanconstruction.org/pdf/Howell.pdf Kenji Hiranabe who has written on Toyota’s Kanban production approach provided an overview of Kanban based on his experience of Toyota. He then presented a video of how WIP could be reduced but it should be noted that this was a marketing presentation and not a best practices guide. The theme, consistent with most lean initiatives, was the reduction of work in progress through the use of one piece flow is desirable (the Toyota practice of Takai). I should point out that this is not practical where there is deep specialisation that you tend to find in many organisations. Marc Baker who is involved in the health initiatives in the UK covered the use of lean in the NHS. It was interesting to note the statistics – 25% of people in hospital are waiting to get out, 99% of time in a hospital is waiting. It highlights that there are significant opportunities for improvement but a lot of challenges. Takeaways As Don Reinertsen points out variability is function of the system as development, in contrast to production, involves non-repetitive tasks, high variability in task duration and non-homogenous flows. Therefore standardisation and increased specialisation at the task level will not eliminate variability and reduce cost, in fact, as John Seddon pointed out, it will lead to an overall increase in cost and reduced flexibility and overall customer satisfaction. We can minimise the impact of variance by focusing on flow and cadence, through the use of small batch sizes and rapid feedback, but we cannot eliminate it entirely. Real option theory, and Toyota practice of set-based concurrent engineering, shows us a way to maximise the upside of variation but you can't change the distribution function as it is a characteristic of the system! Conference slide are available at - http://www.ukleanconference.com/presentations
