The Toyota Way / Lean presentation

Few days ago I had an opportunity to attend a presentation which hosts by ThoughtWorks in Australia. The presentation was about an introduction of the Toyota way or Lean in both manufacturing and I.T industries. This is the first time I attend an official presentation that talk about Lean.The presentation gave an very good introductory of Lean. The presentation last around an hour. I would like to share some of the important points that I had learnt from the presentation.

First, the presenter mentioned 2 basic concepts in Lean.
- Just in Time (JIT), and
- Stop the Line

In short, Just in Time (JIT) is about providing resource whenever the resource is needed. The presenter gave an example in the supermarket. When an item was taking by a customer, a staff will provide a new item back. So it reduces waste by avoiding over stock problem. To apply in I.T. development area, I personally think it means we only implements what the business need, we should never develop something out of scope. We should minimise the "predict future" thinking. So when business need a new feature, we implement exactly what it should do with appropriate code refactoring. Do not over architect what the business need.

For Stop the Line concept, it means if a problem occur, we should stop the process and fix the issue before continuing. If there is a problem, although it may be a tiny problem, we should not cover it up and leave it until later, the problem might grow to a big issue. For example, if you feel dizzy, start a little bit coughing, you should better go to see a doctor rather than wait for a couple of days and "hope" that those symptoms goes away. Otherwise, you will suffer more than just taking a few pills. It seems like it is a very basic concept. Everyone should know, but I guess only a few people can actually "act". To apply it to I.T., we should watch out the problem carefully, we should keep continuing on code refactoring whenever necessary. We should not be afraid of doing it. If we do not face to the problem, we might get a larger problem at the end.

After those 2 basic concepts, the presenters spent some other time talking about Waste concept. There are 8 elements of Waste in manufacturing industries, they are:
- waiting (e.g. waiting for next process)
- over production (e.g. produce more than demand)
- transport or conveyance (e.g. unnecessary stock reallocation)
- over processing (e.g. poor tool)
- rework (e.g. without clearly process and work)
- stock (e.g. keep too much stock)
- motion (e.g. unnecessary staff movement in the working environment)
- resource

Waste elements in I.T. industries:
- extra feature (over production)
- delay (waiting)
- hand-offs (loss of information)
- re-learning
- partially done work (not JIT)
- task switching (reduce throughput)
- defects (unecessary rework)
- unused employee creativity

Finally, the presenters brought an interesting topic. The presenter said there are lots of people are doing multitasking, multi-project at a time because usually, for instance, when project A needed a confirmation from senior management, the workforce will be idle. To reduce the workforce idle time, people will be assigned to other projects.

To illustrate it, assume there are 4 projects: A, B, C and D. Every project needs 4 iterations to be finished. So, the time frame for those people who handle multi-projects are:

ABBD ABCD ACCD ABCD

So all the projects will be finished at the last iteration, at the same time. However, if the projects are well organised, 3 of the projects (A, B and C) are actually delivered earlier as in the following illustration:

AAAA BBBB CCCC DDDD

So what the presenter was trying to say is that moving people around in order to reduce the idle time is a wrong idea. To make the projects success, projects should be clearly identified before it starts.

However, I don't agree with the presenter on the above since the case is too ideal. And it is not agile. I don't think people could find such ideal situation in the reality. I would say we can only minimise people switching between projects as much as possible. If delay happens unfortunately, both project's iteration should be maintained together, swap enough people to the other project, maintain team structure and rotate people in between projects within a couple of iteration so that people will not feel too much distraction from different projects.