No True Agile, No True Lean, No True Latte

My presentation Complexity vs. Lean has been well received by many, whereas it was berated by a few. And good or bad, it certainly has sparked some interesting debates about "true Lean" and "true Agile". Here’s my take on the matter.

No single truth

I don’t believe there is one “true Islam”. Some people say that the “real Islam” is a peaceful religion, while others think that the “real Islam” calls for the death of infidels who occupy holy territory. I don’t believe either of them. There is no scientific way of determining who is right and who is wrong.

Likewise, I don’t believe there is a “true Christianity”, a “true democracy”, or a “true liberalism”. Worst of all, there’s not even a “true caffè latte”. These are all just words. They are models copied from mind to mind, and mutated to suit people’s purposes. The models are supposed to represent what the world ought to look like, but there are so many different versions in people’s heads that we cannot know which is the real one.

Complexity science taught me that, in the end, all models are wrong. There is no such thing as a single truth. But that doesn’t mean all models are useless. In fact, some versions are less terrible than others. (And caffè latte in Holland can be really terrible.) But not one of them can be the True One.

And so, there is also no “true Agile” and no “true Lean”. Although some versions of Agile and Lean in some people’s heads are undoubtedly more useful than others, it is impossible to determine which ones. There is no objective way of determining who is right and who is wrong.

An aggregate model

Latte2

But if the models are all different, then which is the best model to refer to? How can I speak of Lean when there’s no way of knowing what it “really” is? How can we evaluate Agile when people disagree on the practices? How can I describe how to make a proper caffè latte?

I believe the safest way to approach this problem is to create an “aggregate model”, which means attributing relative weights to versions of the model depending on how often they are being referred to. Just like the reputations of scientists are calculated using citations of their articles. And just like Google’s page ranking algorithm calculates relative weights from hyperlinks to web pages.

No true Agile

Latte3

This would mean that the Agile Manifesto, which is referred to by almost every Agilist, should be regarded as one of the primary sources of the aggregate model for Agile. But the Agile Manifesto does not count as the only source for Agile. Common practices, like TDD, pair programming, and stand-up meetings, are by many people considered to be part of Agile. And therefore they are. It doesn’t matter that the original manifesto doesn’t name specific Agile practices. It’s enough to observe that most Agilists support them.

Many people also say that “self-organizing teams don’t need managers” (which is not really true) and that “cross-functional teams are better than functional teams” (which is also not necessarily true). It doesn’t matter what the original founding fathers of Agile had in mind. The only thing that matters is the similarities of the many models of Agile that people now carry around in their heads. If many people believe that pair programming requires chicken soup, then chicken soup is part of the aggregate Agile model.

It’s no use pointing out what an original document actually meant in the past, whether that was 10 years ago, or 2,000 years ago. What’s important is the ideas that people share now.

No true Lean

Latte4

It’s the same with Lean. We can refer to the original pillars of the Toyota Production System, the 14 principles of Deming, and the 7 principles of Lean software development. They all still carry a lot of weight in the aggregate model, because they are referred to time and time again.

But also part of the Lean aggregate model are interpretations of businesses as linear value chains (which is an oversimplification), the advise to optimize the whole (which is theoretically impossible), and a huge emphasis on kaizen, or gradual improvement (while basically ignoring kaikaku, or radical improvement). Again, what the original gurus really meant is interesting. But what really concerns us most is what Lean practitioners actually practice and preach in the Lean world today.

Don’t forget that we should give most consideration to those who are most often referred to by others. If only one “Lean” practitioner in the world claims that Lean requires a daily bowl of low-fat yoghurt, then we can safely ignore him. But when nearly all Lean practitioners tell you to focus exclusively on the customer, while presenting no original ideas on how to keep the other stakeholders happy, then you have good reasons to claim that Lean is sub-optimizing for customers. And that’s what I did. With style. And pleasure. And a latte afterwards.

No true Latte

Ehm…

Counterarguments

Latte5

Some people gave me the impression that only the ideas of “thought leaders” should count when determining what is “true Lean” and “true Agile”. To this I merely like to point at the Pope, Osama bin Laden, and American TV reverends and ask, “Do thought leaders have the exclusive right to determine what constitutes a true belief?” I think not. And it’s no different with Agile and Lean.

Another argument I heard is that misunderstandings should not count as being part of Lean or Agile. For example, the “working software over documentation” principle is sometimes misunderstood to mean that documentation doesn’t matter at all. And “optimize the value chain” is misunderstood to mean that business is a linear chain. To this I say that misunderstandings are a result of miscommunication. If many people have a tendency to misunderstand your message in the same way, then there’s something wrong with your message. In my view the broken messages, including the common misunderstandings, are all part of Lean and Agile.

Of course, my preference to rely on an aggregate model is my own choice. In the end all models are wrong, including any aggregates. But if you’re looking for a model that is useful, my approach might be a safer bet than guessing which thought leader has the most convincing rhetorics.

p.s. I finished this blog post while enjoying my own version of a latte. It was quite good actually.

Jurgen Appelo is an award-winning speaker, trainer, and author of Management 3.0, a management book for software development. You can hire him as a speaker or trainer, to add some spice to your discussions, workshops, or conferences.

  • Agile Management Workshop
  • Agile Application Lifecycle Management (ALM)
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • http://profile.typepad.com/donandre Don Andre

    I think thought leaders are an emergent of a model definition. They do not exist before the model, they’re emerging through popular models. IMO you can also imagine your model as a tree. I think your aggregate model is the tree trunk. It grows bigger and taller over time, holds many branches and makes sure that there is continuous flow of “resources” (people, ideas) from the base to support the growing of the branches and the growing of the trunk. The branches on the other hand support themselves as well as the trunk by producing leafs (case studies) that collect power (interest) and feed this into the branch itself, but also into the trunk.
    The truth is that there are people, ideas and interest. Everything else is imaginary.

  • http://profile.typepad.com/mmazur M_mazur

    You have a good point. Models should be derived from reality not the other way around. If everyone includes yoghurt in their SCRUM implementation the model needs to be updated to include yoghurt.
    However I can’t keep from feeling that there are really two separate ideas mixed here.
    One is that of language semantics. Words like Lean have a meaning, a original meaning, if practitioners of Lean change their behavior is it still Lean? If most of the people in the world decide that orange juice should actually be called coffee. Is a latte a cup of OJ with milk? I don’t know, but to me coffee will always be coffee.
    The second idea is the idea of principals. Agility is not really about TDD, stand ups and other practices the same way religion is not about praying.
    Basically every practice is derived from a principle. My theory is that if you completely remove all the practices from any working Agile methodology you will find the same principals in place. However each Agile has its own interpretation of these principals and the practices are based on these interpretations. This is why there might be contradictions between different flavors of Agile methodologies. This is exactly what is happening in religion. Different people read the scriptures differently and create different practices.
    My point is that while there might not be any true Agile methodology, true agility exists and it’s about the principals. Most agile practitioners agree on the principles, it’s the interpretations that are usually causing debate. If you change the principals you can’t call it agile anymore, this doesn’t mean it’s bad.

  • Scott F

    Indeed, a dictionary does not define the meaning of a word, it describes it’s usages. Otherwise we would have one definitive dictionary from 1698 or – horror – the Academie Francaise!

  • http://donttakemyword.blogspot.com/ Scott F

    I do sympathize with M_mazur. Once a word means everything, it means nothing. If we allow Agile or Lean to change usage weekly than we have to throw it away; it is of no use to us.
    Some terms have a squishiness baked in from the beginning and succeed because each hearer can define it any way she wants. Perhaps “Compassionate Conservatism” was never meant to have a specific meaning beyond the reassuring sound of its syllables. In any case, whatever meaning some speech-writer intended was hijacked so quickly in the popular imagination that it didn’t have a chance to solidify. I think this is what has happened to Lean and Agile. They had some original intent, for good or ill, but they were scooped up so quickly by the Disgruntled, the Greedy and the Desperate – starring Clint Eastwood, of course 😉 – that the carcass has no meat left on it.
    Leaving aside the horribly mangled metaphors, this curmudgeon believes that Agile is all but dead. Some of it’s practices have penetrated the software development culture but not in any coherent way. As to the term itself, it has been virtually stripped of meaning and seems to obfuscate rather than enlighten. If I were starting a career as a management consultant, I am not sure I would harness myself to this term.

  • http://www.pab-data.blogspot.com Paul Beckford

    Hi,
    I would say that your aggregate model approach is decidedly unsafe. What works for me is a primary source approach. So the models I give the most weight to are the models in the minds of the people who chose to adopt and label an approach in the first place. I also like to place these primary models within some type of historical context, understanding what lead the initial thinkers to adopt such a mental model in the first place.
    For both Agile and Lean, the original proponents were coining labels which they felt were easily marketable. Selling the ideas in each has lead to a dilution as the original models have been stretched to meet the needs of new audiences who are attracted by the sales pitch, but aren’t necessarily aligned with the underlying values and principles.
    So following the masses isn’t the answer I don’t think. The masses don’t like to be challenged so are likely to modify the original model into something that is more accommodating of the status-quo.
    Another thing I look out for is the practical experience and credibility of the original proponents. So for example, Lean was coined at MIT by a bunch of researchers into motor vehicle manufacturing. They based their recommendations on the practices they observed at Toyota, but they didn’t create these practices themselves. So I don’t find Lean as defned by MIT a credible source on Manufacturing excellence. I would rather go to a primary source on the subject like Henry Ford or Taiichi Ohno and his TPS.
    Which brings me to my last point when assessing a model, relevance. If my interest is software, I would study the mental models of celebrated software practitioners. I would not look to the models of manufacturing practitioners or academics who chose to study manufacturing.
    All common sense really. It comes down to doing your research. Once you’ve done so thoroughly, you are in a much better position to create an informed mental model of your own.
    Regards,
    Paul.

  • http://management.curiouscatblog.net/2010/11/22/no-true-lean-thinking-or-agile-software-development/ Curious Cat Management Improvement Blog

    No True Lean Thinking or Agile Software Development

    There is no true value of any characteristic, state, or condition that is defined in terms of measurement or observation. Dr. W. Edwards Deming. The value depends on your operational definition. Once you operationalize management …

  • http://profile.typepad.com/mgb1 78mgb

    Nice post…
    I had some comments that just kept getting longer so I just posted them:
    http://blog.risingtideharbor.com/2010/11/comments-on-no-true-agile-no-true-lean.html
    …but to sum up, I mostly agree with you 🙂

  • http://donttakemyword.blogspot.com/ Scott F

    Great post, Paul. Thanks

  • http://profile.typepad.com/tijman Anko Tijman

    A sidenote: I believe misunderstanding comes from communication , rather than miscommunication. Just like a model can never be completely right, neither can communication result in complete understanding.

How to Change the World - free Workout - free
CLOSE