CAS 100, Lean 0 in ‘Complexity Vs Lean, the Big Showdown'

October 25, 2010 — Posted by Al Shalloway

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):

  • Energize People. 'People are the most important parts of an organization and managers must do all they can to keep people active, creative, and motivated.' This is a perfect statement of the intent of Lean – Deming essentially says this himself.
  • Empower Teams. 'Teams can self-organize, and this requires empowerment, authorization, and trust from management. ' Again, this could have been taken from Deming himself
  • Align Constraints. 'Self-organization can lead to anything, and it's therefore necessary to protect people and shared resources, and to give people a clear purpose and defined goals.' While I see this problem all the time with team-based Agile methods. Lean provides alignment by creating a common vision across the organization on how to achieve higher productivity by attending to cycle time.
  • Develop Competence. 'Teams cannot achieve these goals if team members aren't capable enough, and managers must therefore contribute to the development of competence.' One of Deming's 14 points was to institute training. See the webinar The Role of Management in Lean-Agile Transformations to learn more about what Lean says about management.
  • Grow Structure. 'Many teams operate within the context of a complex organization, and thus it is important to consider structures that enhance communication.' Lean is about improving the system within which people work. With people, part of their 'system' is this structure being mentioned.
  • Improve Everything.' People, teams, and organizations need to improve continuously to defer failure for as long as possible.' One of the fundamental aspects of Lean is continuous process improvement. Read Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results for a great representation of how Lean's suggests continuous learning.

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 Net Objectives Support Group (LinkedIn) 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 @ We do training and consulting in Lean at the business, management and team level (including Kanban). Or, watch our Lean Software Development Online series.

Alan Shalloway
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

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Hi Alan,

>> If it doesn't, it may be you are misunderstanding Lean.... It is a way of thinking and learning and is continuously evolving.

This is the problem. No one knows what Lean means. The definition as been debated ad-nauseam on several forums, and the most widely agreed definition is "think for yourself", which is what I would advise your readers to do.

No single "brand" has a monopoly on sensible thought. For Lean to be of any use it needs to be practical and offer practical guidance. The Lean (Software) community are big on slogans short on practical advice IMHO. We need to move beyond these "branding" wars and get back to practice. CAS is only common sense, and should be embraced by everyone doing complex human centric knowledge work. Lean manufacturing offers practical tips on how to approach planned, predictable industrial work. Is this useful for knowledge work? Yes. Is it complete for knowledge work? No, not in the slightest. The fact that the Lean community, led by the LEI, insists on selling its wares to a broad sweep of professionals from nurses to accountants, says more about the ambition of the LEI then the applicability of Lean.

If we limit the discussion to software, and you are looking for practical advice, then I would suggest starting with XP (which includes some Lean ideas) and inspecting and adapting from there, keeping in mind that software development relies on people, people are complex intelligent agents and organisations are complex adaptive systems :)



Paul:I am not a member of the Lean community as led by the LEI.  They are more about services and manufacturing.  I believe the literature very well states what Lean Software Development is - Don Reinertsen's and David Anderson's work being the most definitive.  Clarifying what Lean is a forefront purpose of the Lean SSC as well.  I believe your challenge is you keep referring to things that are well outside of the Lean Software Development community when responding to those in the Lean Software Development community.BTW: Referring to advice,our own Lean-Agile Software Development book describes using Lean across the enterprise.  David's Kanban book and Corey Ladas' Scrumban book lays out the mindset, practices and principles for Lean implementations at both the team and entire value stream. Not to mention the dozens of Lean / Kanban experience reports at the last 5 Lean Software conferences.  

I suggest you will never understand the methods and philosophies espoused by the Lean Software Development community by looking at Lean in manufacturing and services.  As you have said yourself many many many times, software is considerably different from manufacturing.

Alan Shalloway, CEO Net Objectives


What makes any of the sources you describe definitive? Davids book is about Kanban, an approach which he defines in its own terms. Likewise with Corey and Scrumban. Scrumban is Scrumban not Lean. If the Lean Software Development community have a definition of what Lean Software development actually is then they should tell us. Define it, like the Agile Manifesto. A call to arms. Something concrete we can all agree on and get behind.

You know as well as I do, no such document exists and pretending otherwise is discourteous at best. All Agile methods borrow ideas from Lean Manufacturing, even Scrum. This doesn't seem to qualify Scrum as Lean though. I am over the moon that Lean Software development is distinct from Lean Services or Lean Manufacturing. Hooray!!

Now that we have got that out of the way. Please define what Lean Software Development is, or better still point to a community agreed definition that is detailed, practical and unambiguous.



I do not believe having a Lean Software Development manifesto would necessarily be a good thing.  There have been many many presentations made by myself and others where we have defined what lean software development is.  I agree a  more concise statement is necessary and would be very useful.  However, when I get together with other Lean Software Development thought leaders there is fairly strong agreement on what Lean is. I am working with the Lean SSC to help present a better understanding of Lean Software to the world to make it easier - but I would say your attacks are grossly unwarranted and lack evidence.  There are many sources for mindsets, principles and practices.  Saying we don't provide guidance is to ignore a huge amount of literature.   One of the problems is Lean Software is somewhat new,even though it is based on old principles. 

To be honest, when you've made comments on our website they always seem to be an attack on lean not an attempt to understand. I'mhappy for you to keep posting, but I may not engage in a 'conversation' via comments.

Alan Shalloway, CEO Net Objectives

Hi Alan,

Amongst your list of sources, you forgot to mention what I believe to be the most definitive source:

Lean Software Development - An Agile Toolkit, by the Poppendieks. This book was the first (the only?) to coin the term Lean Software Development, and rather then offering an approach in contrast to Scrum, XP etc, the Poppendieks mined Lean Manufacturing and Design (yet again) for additional techniques that could be applied to software development. These techniques are presented as practices that may be applied in addition to other Agile approaches, hence the idea of a toolkit. The techniques described are interesting. Some of them are just a restating of pre-existing Agile ideas like "last responsible moment" being a restating of YAGNI. Others are somewhat new, but still useful, like concurrent design. Nothing described here could be considered an alternative to Scrum say, or in conflict with CAS theory. It's just a toolkit where you can take or leave each technique on its own merits.

Which brings me to "attacks". I'm sorry you think I'm attacking, I really am not. I am merely looking for clarity and defending ideas you choose to dismiss. If you remember I said to you over a year or two ago to stop "attacking" Scrum and CAS or whatever, and spend your time instead explaining your own ideas around Lean. I'm glad that you and the LSSC are still working on those ideas. This blog is an excellent opportunity to express them as they evolve.

Until you express your own ideas and thoughts in a clear and concise way, without seemingly knocking the work of others, what you are doing will be open to the allegation of meaningless marketing and a "branding" war. I'd much rather read about what you think, then hear you dismiss what other people think. I look forward to your concise description of what Lean Software Development means to you.




Actually, the Poppendieck's weren't the first to coin Lean Software Development - Bob Charette was - several years before them. 

I've written a book explaining our approach, I've written a book explaining how to do Scrum from a Lean perspective, I'm writing a book on Essential Skills for the Agile developer due out in a few months. I do an average of 5 webinars a quarter, write 1-2 blogs a month and present at 7 conferences a year.  Most people would consider that expressing myself. 

Given you do not consider that enough I am not sure how I can expect to have a reasonable interaction with you.

I  have never dismissed people's ideas but have always engaged with them.  After a while, however, when nothing seems to move forward, I disengage.  BTW, you seem to forget that I was thrown off and am still banned from the Scrum Development group for engaging with Ken Schwaber on whether Scrum of Scrums worked and how to improve it.  

I am not sure what your point here is.  You are discussing me and not the ideas I've expressed.  I actually don't want to engage in that anymore - so post comments away but don't expect me to continue.

Alan Shalloway, CEO Net Objectives

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban