QTB: Lean Times Require Lean Thinking
I went to watch the latest ThoughtWorks Quarterly Technology Briefing on Tuesday, which was presented by my colleague Jason Yip and Paul Heaton, titled ‘Lean Times Require Lean Thinking‘
I’ve been reading quite a bit of lean related material lately but I thought it would be interesting to hear about it directly from the perspective of two people who have been involved with applying the concepts in organisations.
What did I learn?
- It was pointed out that lean thinking is particularly relevant at the moment with the global financial crisis requiring organisations to come up with more effective ways of operating with little cash at their disposal. Toyota of course derived the Toyota Production System when they were in big trouble and needed to find a way out of their own financial crisis in the 1950s.
- Lean is not just about manufacturing, it is being applied in many other industries as well. Paul pointed out that KMT are introducing it to the service side of many organisations. I think it is a different challenge introducing it into software development and while the Poppendiecks have written some excellent material on lean software development, there is still more for us to learn about how to do this successfully.
- Although I've read quite a bit of material about lean I've never been convinced with the normal definition that I hear of lean in that 'it's about reducing waste' but I didn't have a better definition until Jason came up with 'it's about engaging everyone to solve problems'. It does still feel a bit generic but I like it better than the other definition.
- The most interesting part of the presentation for me was when Jason spoke about the different types of waste in lean in terms of software development:
- Extra features (Over Production)
- Delays (Wait and Queue) e.g. waiting for business sign off of stories
- Hand-Offs (Internal Transport) e.g. passing work onto someone else
- Re-learning (Over Processing) e.g. the same problems coming back when we have already previously learn about them. The first time we find a problem that counts as learning.
- Partially done work (Inventory) - e.g. work requiring late integration which hasn't been done yet. At an extreme I think this could be taken to mean any work which isn't in production since it is only when we put something into production that the value from it is realised.
- Task switching (Motion) - e.g. doing several projects at the same time. Here we end up with the problem that all of these projects are delivered late. Jason pointed out that just because people are busy doesn't necessarily mean they are adding value.
- Unused Employee Creativity
- There was mention of set based concurrent engineering which Brad Cross has an excellent post about. The idea is that when there is doubt about the best solution to a problem we pursue several different options at the same time before deciding on the best option at the last responsible moment.
- Jason spoke about the difference between authority focus and responsibility focus, the latter being a more lean approach where we focus on 'What is the right thing to do?' and 'How can I help?' rather than the far more common approach I have noticed of 'Whose job is this?' and 'Not my problem'. If we can get the responsibility focus going then suddenly the working environment becomes much more pleasant. Related to this I quite liked Liz Keogh's recent post where she talks about rephrasing the language we use when talking about problems to avoid the blame culture.
- Value streaming was also mentioned with relation to how our goal is to find added value for our customer and that most organisations only achieve around 20% of value added activity in their value streams. A comment which really stood out for me was how 'no problem is a problem' in lean thinking. People like to hear good news and you can often be referred to as being negative when you point out problems. In lean we recognise there are going to be problems and get these raised and sorted out as soon as possible.