http://tinyurl.com/pysl4f

Having experienced Lean principles first hand I have always had a strong gut feeling that in many ways Agile and Lean are very different. Alan spells out the differences in beliefs very well in his article.

A difference that is related to the idea of “self organisation” is the concept of a “defined process”, which is more commonly referred to as “Standard Work” in Lean parlance.

Now Alan believes in a “defined process” for software and using PDCA as a process improvement technique. Having being trained and experienced in both over many years and experience them work in manufacturing and fail in software, I don’t. I mean that “defined processes” aren’t a universal good and are appropriate for a given context.

Self organisation in Agile also means having the freedom to change the process on the fly. In fact it goes further. It means spontaneous process creation, guided by values and principles, resulting in innovative and creative solutions to problems on the spot. Kind of like improvisation in the theatre. Lean does not allow for this, If it did, statistical process control would be impossible, because there would be no “defined” basis on which to base the maths.

Agile does. Is either wrong or right? Again it depends on context and the nature of the work. Is the work ndustrial or is it? Most work has both qualities but a dominant component. The types of software project I have worked on have been mostly artful (what Jim Highsmith would describe as high exploration). Some software projects (like maintenance and bug fixing) could be considered mostly industrial in nature (low exploration).

I could expand further, but this is long enough as it is. The main point is tat theory that can sound very rational may not work in practice depending on your context.

Paul.

Good points, and I must say I agree with everything you say. The teacher student relationship is key. It starts with the idea that you need good teachers and those teachers need to be respected.

Ideally the teachers should be the people in management positions. I don’t know why, but in my experience this is seldom the case. The motive for people going into management seems more to do with Ego and attaining a pay grade, then empowering and teaching others. Perhaps its not East versus West, but it is definitely cultural issue in a lot of organisations.

Ultimately what you describe as “Lean” is where we want to be. I suppose you’re right “Agile” in this regard is a watered down “tactical” alternative.

Given the reality of the organisational cultures I’ve had to work in though, Agile has proven a practical alternative, that provides space for true leaders to emerge. It is a bit hap hazard granted, but with some coaching and a team of people who have established mutual trust and respect then good leaders can emerge. Often this is in contrast to almost certain “poor leadership by management”.

Thanks for your reminding me. Just to back up what you say Mary Poppendieck has an excellent presentation on Leadership:

http://www.infoq.com/presentations/poppendieck-agile-leadership

If the Lean proponents in software at the moment focused more on this aspect and less on “process”, then I agree, “Lean” in Software would be serving its true objective.

Paul.

In other words what’s the difference? I just don’t see any. And if there is none, why the need for new names at all? It would probably be more constructive to drop all names and just call this way of working “software development”. Simple.

I believe you touch a very important point that we constantly miss in software (and I bet will continue to miss): Lean works bwcause it is a system, not a bag of tools.

This has vey deep implications, Kanban for example was a tool devised in Toyota to solve a specific set of problems, but was followed by other tools once the impact of Kanban was recognized. TPS is a system (not a tool or set of tools) that evolved over many years. In software we don’t seem to be patient enough to rip the benefits of Lean and are rushing into tools forgetting they cannot work alone.

I’m not saying that teams can’t make their own decisions. I’m saying that every person on a team is not always entitled to take any decision that suits them.

A team includes it’s captain. A team without a captain isn’t as effective as a team with a captain. A “true leader” might emerge from a team, but it’s not exactly common. A dominant or dominating player will usually emerge from a team, but there’s no guarantee that he’ll be what I think of as a teacher/director in a Lean tradition.

Self-organization isn’t self-direction or self-determination. Self-organization has devolved into self-determination over the past few years in mainstream Agile as teams seek means to deal with poor management, but the answer to this problem isn’t to swing the pendulum to an opposite extreme.

So, I’m not talking about TPS per se – or TPDS. I’m merely talking about Lean. Not Agile’s watery agilification of Lean, but Lean, and it’s explicit central thrusts and value system, which includes creating learning organizations.

Frankly, I find it quite disturbing that the most that we’re getting out of Lean is yet more process improvement efforts. That’s an impoverished view of Lean. We’re failing to look at Lean without doing so through colloquial Agile’s lens.

I don’t think it’s an East vs West thing. The presence of learning culture and its organizational mechanics and protocols isn’t a given in eastern companies just as its absence isn’t a given in western companies. If we strip Lean down to something the size of colloquial Agile, we’re going to leave a heck of a lot on the cutting room floor.

Indeed there’s a lot of value to thinking for oneself – especially when one has been guided by his teacher or teachers to think methodically and to seek ever deeper root causes. Whether any legendary Toyota manager came up with the 5 Why’s (and it’s not always strictly 5 of them), the result wasn’t an undirected workforce but a rather strict hierarchy of very competent and talented people who had the responsibility to teach others and workers with the responsibility to learn.

Whether or not we have these flows in our corporate cultures isn’t really the point. The point is that the objective of Lean at its heart is the create them and sustain them – as well as all of the process mechanics, kanban, heijunka, genchi genbutsu, etc, etc, etc.

If we fail to realize this in the software industry, then we’re following on the heals of other industries who also had narrow interpretations of Lean and who chalked up Lean organizations successes to the eastern versus western mind and who failed to duplicate the successes of companies who successfully transformed themselves into the organizational and cultural shapes that we now call “Lean”.