februar 2007 - Posts

• The Five Whys of Lean

  Root cause problem resolution is one of the core practises in agile. If the engine requires new oil every 500 km we don't just top it up with oil. We fix the engine.  Adding oil is just a hack that leaves technical debt in the system and slows down our journey. It reduces our sustainable pace. Good operations people get this. Many developers, however, do not. We would happily work overtime walking with a stone in our shoe rather than stopping for a moment to remove it. To increase the awareness of removing the cause rather than treating the symptoms of the problem, Taiichi Ohno of Toyota implemented the simple practise of asking "Why?" five times when something went wrong. As we keep on asking, we get closer to true cause of the problem, not just its symptoms. It is a simple technique and it works very well. In my career I have seen many systems that take weeks or months to integrate and deploy after the developers declare them "done". When integration is very expensive people tend to put it off and build up huge batches of work-in-progress - software that the developers have declared to be done but which cannot be deployed to production yet. From a Lean perspective that is a waste. Taiichi Ohno's "5 whys" technique proves quite useful in a situation like this. "Why not release to production at the end of each sprint instead of just once per year?" "Well, yeah, that's a good idea, but we can't do that." "Why?". "It is very expensive". "Why?". "We have to test it all and get all the bugs out." "Why does that take so long?". "It's a manual test, and we have to deploy to a very complex environment and there are a lot of bugs." "Why don't you do automated testing, then?". "Oh, we tried that - it does not work." "Why?". "You see, we create tests but when we run them two months later they are all red....". "Why?". "Time passes and so the monthly batch jobs run and update the data. This breaks the tests... so we can't do automated testing.". "Why not let the tests create a set a known test data when they start and then test against that?". "No that wouldn't work. You see the test data is a snapshot of the production data." "Why?" "So that we have examples of all the kind of data we need to test on. Creating the test data is very complex and takes too long." "Why?" "Well, there is so much data to enter." "Then why not automate it then?". "We cannot do that - you see, the legacy system does not really have the hooks for that." "Why? - who wrote it?" "Don't be stubborn. We wrote it... but , you see management doesn't want us to change the legacy system since it costs so much to test." "But that's the problem we are trying to solve!" Getting to the root of the problem and fixing that is the core of lean and agile practises. Next time you encounter a problem, try asking the five whys, and ask yourself - "are we treating the symptom, or removing the cause?" This is the way to go faster and improve quality. Posted feb 20 2007, 01:06 by Martin Jul with 4 comment(s) Filed under: lean, five whys

• Why Going Faster Matters

  I did a talk on Value Stream Mapping from Lean last Thursday at the Danish Agile User Group meeting (slides in Danish are available at http://tech.groups.yahoo.com/group/DanishAgileUserGroup/files/ (registration required)).  One of the many interesting questions that came up was why faster is better - could it be that slower would be more efficient? The context was that be that faster could be more expensive - ie. adding more people to fix the problem. In that case there is a chance that slower is in a sense better. Dogmatic software development even has it that resources, timeline, quality and feature set are interrelated. If you want to go faster or to increase the quality, it costs more. The underlying assumption is that the process is perfect and therefore that all the work is essential and valuable. That, however, is a myth. From the perspective of the Seven Wastes that I blogged about recently I would like to rephrase the question to "is less waste always better?" I think the reason that many people connect lean with faster is that the most obvious waste in value stream maps is the waste of waiting. So on first impression lean is all about eliminating that and keeping extra resources available to solve tasks immediately when they arise with with no delay. That would be wonderful however but if we have a great variation in the workload we will take on a huge overhead to have peak capacity available at all times. Since this would be a waste when demand is slow lean has a practise of balancing work and capacity to keep the variation low. In case there is extra capacity available we use it for kaizen - process improvement. In software, for example, we could spend it on refactoring a legacy system to a cleaner state so we can work faster in the future. This would enable us to take on extra demand with the same number of resources. Now there are other wastes than waiting and it is by looking at them that we see that lean is actually not a cause of stress as many seem to belive. The aim is not working faster doing the same thing. The goal is to only do the work that is actually valuable. This means getting to the goal faster by doing less. It does not mean burnout or overtime. From this perspective I believe that lean is a more humane approach than the obvious alternative of status quo where speeding up is derived from the project manager pressuring and threatening employees to work overtime, cut quality etc. In that traditional context faster means evil, but in the agile world, where respect for people is the centerpiece faster also means better. It denotes less meaningless work. It means freeing up all the untapped human talent of the team and putting it to bear on doing exciting work - to spend our working hours creating something that will please the customer faster and at a better quality than ever before. That is the essence of agile - and it's the source of great job satisfaction. Posted feb 04 2007, 06:34 by Martin Jul with 2 comment(s) Filed under: lean, speed, waste, value stream mapping