I hesitated to reply to this because what I'm about to say could be taken as pedantic. However, it is my experience that many people experience a good way of working, apply a label to it and then use that label thinking that it will communicate all of the good things that they intended. This is rarely the case. At some point you see many articles entitled "Why X doesn't work" where they describe a broken version of X and why it doesn't work. The broken version ends up getting more popular than the unbroken version for some reason and there is a general consensus that "X doesn't work and anyone that uses X is an idiot", even though X works perfectly fine if you use it correctly.

With that in mind, "lean" as a principle is organized around the idea that it is better have people request functionality (pull) than for you to imagine what people want and then try to sell it (push). Many "lean" organizations happen to be very good at continuous improvement, but you can be "lean" without any capability for improvement.

"Kaizen" is the Japanese word for continuous improvement. It was introduced to western eyes primarily from the "Toyota Way", which is a lean manufacturing system that concentrates on continuous improvement. It is important to understand, though, that while workers have a responsibility for identifying problems, it is the managers who are responsible for working with the workers to implement improvements in the Toyota way. So there are clear demarcations of responsibility, unlike many of the IT processes that borrow the word "kaizen".

Even "continuous improvement" can be a loaded term with respect to responsibilities. The first time I ran across the term was dealing with CMM (the Capability Maturity Model). Once you are up to level 4 or 5 you are using metrics to improve your process in order to obtain continuous improvement. In every organization I've seen that attempted to achieve CMM level 4 or above, the primary driver was management (and often workers were not even consulted about improvements or why they were necessary -- they were only told to do things a certain way). I'm not saying it was successful, but it was very common ;-)

I guess my point is that if you are lucky enough to be working on a team that does continuous improvement well, be aware that what you call "Lean" or "Kaizen" is unlikely to be what other people call it. You can not communicate what it is you want to communicate using those words alone. If you have been reading literature using these words and believe that if you simple follow a "Lean" system and embrace "Kaizen" that you will transform your organization into one that does continuous improvement well, I'm sorry to burst your bubble. If only it were that easy. Unfortunately, all the difficult problems are people problems and those problems almost always require unique solutions. It can be quite tricky no matter what you are doing.

I think the lesson to learn from this is to be wary of anybody who says they can look at a system for organising people that works well and write down a recipe for how to reproduce the essential elements of that system. Even if they were partially responsible for creating it. Most likely, nobody understands why it works in enough detail to write down precisely what it would take to reproduce it.

W. Edwards Deming got the closest I think?

System of the organization comprises the relationship between systems within it, how those systems change and vary, the methods of knowledge learning and transfer, and the psychology and behavior of the people within it. And importantly, it's how all those pieces interact with each other that makes the most difference.

It's a system. There are some common elements. Above that base level, there is much truth in what you say, but the most important thing you can learn is a mental model for organizations in the most general way possible.

One of the hardest parts of this is organizations are not separate from there problem domain. A process that works for manufacturing cars (high value) may not work so well for manufacturing radios (low value) let alone banking software. Pay, education, and company size are all huge factors that are often ignored.

I found myself imaging someone writing down a recipe for yogurt like so:

1) Heat up milk 2) Find something with the consistency of yogurt to put into the milk 3) Wait

Having a living thing there that knows what the final product should be and can stand as an example is largely how we transfer culture.

Part of the extreme difficulty in defining a mental model for an organization is that organizations are necessarily complex systems. You're exactly right.

Regarding people problems, my one note is that we are all more alike than we seem, and you eventually start to see the same classes of problems everywhere. This is why an understanding of psychology and behavior is so critical.

Except this big catch is that employees are compensated for the improvements they bring about. That basically never happens in a typical software company. Maybe if you keep bringing in important changes someone will notice and maybe you'll get stock options or you'll be promote to management

yeah there are a gazillion companies that claim to be Lean, Kaizen or what else but guess what, in practice only a small fraction actually are :)

That seems like something that is worth (tactfully) screening for in interviews when given the opportunity to respond.

So instead of asking "are you Kaizen?" you would ask about practices performed that imply Kaizen, including the spirit of the law and not the letter.

Yep - this is something that I'm thinking about actively. How do you start the conversation in an interview (as either interviewer or interviewee) that gives you insight into how people treat problems? Is their instinct more individual or systemic? Do they naturally look for improvement, or point fingers?

I've had some success, but they're always very deep interviews, which can either be drastically good or quite startling to the other party depending on what direction it goes. So your note to do it 'tactfuflly' is very prudent.

I have often found that two things work well for this:

* have your antennae out for anything that seems weird (weak signals, indeed) in your conversations about the work

* check references (as an interviewee). That's a fancy way of saying, look to see if anyone you know knows someone who works there, who can give you the straight scoop.

At more than one company, "Agile development" means "the CEO gives his cell number to every customer, and Waterfall development happens very fast."