I was at the LESS 2010 conference last week and heard Jurgen Appelo's talk Complexity Versus Lean. I thought this was very thought provoking. Unfortunately, almost every time he mentioned Lean, he was describing it in a way no Lean thought leaders I know would think about it. I would have liked this talk much better if it were called "Using CAS to avoid misunderstanding Lean" since every time he used CAS to explain why there was something wrong with Lean, he was actually talking about a misunderstanding of Lean. Hence, the name of this blog 'CAS 100(% well described), Lean 0(% well described)'. If you are not familiar with complexity theory, Jurgen Appelo's website is a good place to start. In particular, I like his model of complexity, simplicity, chaos and ordered described in an article called Simplicity-A New Model. I also suggest that you read another blog of mine - Types of Processes – by Don Reinertsen to clear up some common misunderstandings of predictability Vs controllability.
To go into detail for every misunderstanding of Lean presented would make this a very long blog. Instead, I'll just mention some of the misunderstandings with a statement about what virtually all of the Lean thought leaders I know really thinks about Lean. I've put the misunderstandings in bold, with a short explanation of what Lean really suggests after that.
Lean Development is a prescriptive approach to work in social systems. Lean is not at all prescriptive. Lean is about thinking. Yes, it does suggest you should always attend to time and make sure you are not overloading teams. But how you do it depends on the context of the problem. Lean is about learning – not acting without thought. See my blog Rethinking the Practices of Scrum – or What Would Chris Alexander Say? for more.
Lean assumes linear behavior. Lean manufacturing may assume this, but not Lean software development. Kanban boards may often appear to be linear but Kanban boards reflect the way people are doing the work. Hence, if people are working linearly, the board will reflect that. However, Kanban boards can also reflect non-linear work.
Things missing in Lean (quotes are from slides):
Eliminate Waste is not always good. The talk mentioned that holding things around that aren't valuable now may become valuable in the future. One of the biggest wastes in software development are features that are built but not used. Unfortunately, while there may be some value in the future, there is definitely cost of maintenance now. Usually, a horrible tradeoff in software. In any event, Lean's mandate of eliminating waste is not referring so much as to the physical scraps left over as it is telling us to improve the process so you don't create the scraps to begin with. See my blog Resizing stories for a true, but embarrassing story about writing features that aren't needed.
Build Quality In Can Constrain Uses of Products. Lean's focus on quality is not so much as to restrict potential uses of a product as much as not making errors and then having to fix them – focus on not making the error in the first place. See an article on the Role of Quality Assurance in Lean-Agile Software Development for more, If you prefer webinars, watch Session 6 of our Business Driven Software Development series on Acceptance Test-Driven Development.
Create knowledge is only a small piece of the competency puzzle. 'Create knowledge' is shorthand for learn how to solve your problems better. Of course, two words don't tell the whole story.
Defer Commitment may be bad since when one commits to something it mobilizes action. Defer commitment does not mean don't commit yourself to getting something done. It means don't make decisions with incomplete information that essentially commit you to a course of action.
Deliver fast can result in not thinking. Deliver fast doesn't mean act fast. Rather, it means shorten the time from starting your work until it is deployed to the customer. Ironically, Jurgen says 'Think (briefly) then deliver fast.' Deming used to say – Don't just do something, stand there.
Respect people is insufficient to instill a "need" for work. Actually, this may be the one point of disagreement I have with Jurgen about CAS. I do not believe you can really motivate or energize people. You can create an environment in which people's own motivation and sense of worth will energize them. Giving them the proper structure, systems, tools and freedoms will do more to energize a team than anything else a manager can say.
Value streams are always linear. Don Reinertsen talks about value networks instead of value streams. Value streams are not always linear in any event. But in Lean software, calling value stream maps value network maps may be better so one doesn't falsely believe Lean suggests the flow of the value add is linear.
Explicit policies means there is one way to do it. Actually, no. Explicit policies doesn't imply how many ways there are to do things. It simply means you have it stated what your options are if there are options. There is much confusion about 'explicit policies' and being prescriptive. I discuss this a little in my blog Differences in Beliefs Results in Differences in Approach. I discuss explicit policies a little more deeply in The Real Differences between Kanban and Scrum.
When learning Lean, I do suggest you apply what you know about CAS and see if your understanding makes sense. If it doesn't, it may be you are misunderstanding Lean. There are any number of forums with which to question your understanding - the Lean-Agile Yahoo user group being one. Lean is not a set of tools (see Lean Is More than a Set of Tools). It is a way of thinking and learning and is continuously evolving.
If you want to learn more about Lean Software Development, please send me an email (alshall @ netobjectives.com). We do training and consulting in Lean at the business, management and team level (including Kanban). Or, watch our Lean Software Development Online series.
CEO, Net Objectives
Co-author of Design Patterns Explained, Lean-Agile Pocket Guide for Scrum Teams, Lean-Agile Software Development
Currently co-authoring Essential Skills for the Agile Developer