“Implementing Lean Software Development: Practitioners Course”, by Mary and Tom Poppendieck

Kim Horn — Thu, 10 May 2007 18:10:00 GMT

Having attended the two day “Implementing Lean Software Development: Practitioners Course”, I encourage you to join Mary and Toms classes or speeches if you get the chance, they are very inspiring and their knowledge about lean and agile are amazing.

Mary and Tom have done a great job in transforming Lean principles from the manufacturing environment to software development. The course take you trough the Lean history, give you a brush up on the theory behind Lean and give you a lot of god techniques, tools and ideas on how to improve your existing projects and use the power of Lean.

A few “lessons learned”:

Success factor for implementing Lean: look at the whole supply chain, not only development or test. Think products (end to end) and not only projects.
Use pull rather than push. Be aware of utilization: an operations manager will react when a servers cpu utilization is getting close to 100% - but what about people utilization …
When implementing Lean it isn’t enough just to use Just-in-time and stop-the-line. It is the people doing the actual work that have the potential to make it a success. They have the good answers and ideas.
All queues and stacks of work is WASTE. Remove the cues, improve the cycle time and get better overall performance and quality. Value stream maps are a powerful tool to identify queues and their size.
Without automatic tests you are asking for trouble. Don’t buy the “we don’t have time to implement automatic tests” excuse, if you wait your problems will grow…
And NO it is not ok to have a backlog that contains work for more than 3 iterations, including ideas for the future – get rid of the WASTE and focus on the important stuff that adds value to the customer.

Why Going Faster Matters

Martin Jul — Sun, 04 Feb 2007 17:34:00 GMT

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.

Ative at Work : value stream mapping

“Implementing Lean Software Development: Practitioners Course”, by Mary and Tom Poppendieck

Why Going Faster Matters