The next in my series of posts on Lean Agile Scotland 2013. Another common theme was that it is more efficient and valuable to optimise flow than optimise resource use.
Don’t try to keep everyone busy all the time. Allow for some slack so that people are available to keep a piece of work moving. You can’t produce things faster than your bottleneck, so keeping people who aren’t the bottleneck busy is just building up inventory which gets in the way, may end up not being useful, and means they’re not available if something comes up.
There were a few examples of this given. One was a couple of women with suspected breast cancer. Martha goes to the doctor, who can’t decide so needs to do some tests. She makes an appointment with the nurse to get the tests done – first available is a few days later – then has to wait until they come back from the lab. Once they do, the doctor sends her another appointment to discuss them. She goes along, the doctor isn’t sure, so makes an appointment for her with a specialist. When she gets home she’s a bit distracted and has forgotten when her appointment was, so she has to phone up and check, and the receptionist has to look it up and send out an appointment card. She gets the appointment in the post for a couple of weeks later, goes to the specialist, and she needs to do some tests, so … Eventually several weeks later they come to a conclusion.
Contrast this with June, who goes along to a specialist clinic. She is met by a nurse who takes her details and does some initial checks then takes her to the waiting room. A few minutes later, she is taken in to a doctor, who reviews the case and decides she needs more tests. She goes back to the waiting room for 15 minutes and then is called in for the tests. The analysis is done on-site and takes a couple of hours, and the doctor immediately refers her to the on-site specialist , who discusses the results with her and decides she needs more tests. Those tests are done and processed overnight and she is told to come back in in the morning. Next days those results are in and they come to a conclusion.
The actual process and processing time in both cases is very similar – slightly more in Martha’s case because of the admin around managing the appointments. The end result in time is very different – which means that Martha has a lot longer uncertainty and stress than June. It could also affect the prognosis, since the cancer won’t be staying still. The difference is that the clinic has everything there to be able to process straight away, and has sufficient slack in the system that people can be seen immediately. The clinic has emphasised time from start to finish over keeping everyone busy.
Interestingly, studies have shown that in general it doesn’t cost more overall to work in the way of the clinic, and in fact is usually slightly cheaper/more efficient because you don’t have so much tracking overhead of all the queues between stages.
Another he gave example of optimising flow versus resource was a tester. We have Michael at one company and Julie at another. The equipment for the test takes some time to set up, so in both cases there’s the setup time, and then the time for the tests. They both find an issue during testing.
Michael writes down a whole lot of detail and files a bug report into the system then carries on. He finishes the test run, then so that he’s not wasting time, he start setting up the system for the next product to be tested. While he’s doing that, the developers come back asking for more information on the issue. But he can’t re-run it because the system is in the process of being set up for product B. He finishes that, does the testing of product B, then gets the system set up for product A again so he can re-run the test to get more information. He sends it back to the developer, who can now get started on fixing it. Michael then has an issue on product B he needs to re-runs tests for… Julie, on the other hand, goes and finds a developer when she sees the issue. The developer comes down straight away and gather the extra information she needs then goes off to work on it while Julie finishes the test run. Having finished the run, Julie starts working on background tasks – writing up reports, improving processes, working on something she’s investigating for speeding up testing. The developer comes back with a fix and wants to check it, so Julie immediately runs the tests, and sends back the results. Once the testing on product A is complete, Julie can start testing product B.
Julie obviously finishes testing on product A long before Michael does, which means the company can start making money on product A earlier. The interesting thing here, is that Julie actually finishes testing on product B before Michael as well, even though she started later, because of all the switching costs. And this gets worse the more products that Michael has on the go simultaneously. So by optimising Michael’s resource usage, the company is slowing EVERYONE down (remember, the developer was sitting around waiting for Michael to finish testing product B and switch back again before he could get the results to allow him to fix the problem), and slowing down its ability to get products to the market.
TLC Labs has everyone expected to spend 20% of their time working on lower-priority tasks which can be easily interrupted – training, reading, learning, refactoring, process improvement, tools improvement, nice-to-haves. This means when a problem comes along, they have people around who can be called in to swell the numbers. It also means when a sudden opportunity comes up, they have the spare capacity that they can chase it.
An interesting corollary of this is that if you have someone who isn’t on the bottleneck – say a developer when your bottleneck is the UI design – it is more efficient to have that developer working on some UI at a third their normal development speed in order to get something completed than it is to have them working full speed developing stuff which can’t be deployed until it has UI.
Badger Taming 