I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.

One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.

“The term Oxymoron originates from the Greek oxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.”  Wikipedia’s Etymology for Oxymoron

Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.

Agile as an umbrella term

First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code.  It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.

My rendition of the geneology of Software Development Approaches

Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.

I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.

Lean merges with capital-A Agile

I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.

Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)

• Small batch sizes, short cycles that create rhythm
• Reduction in queues through pull
• Reduction in work in process inventory
• Design quality in
• Stop-the-line defect control
• Value streams the link to the customer
• Integrated learning through reflection
• Last responsible moment decision making

These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD.  I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me. 

What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?

I’ve been thinking about leaning a lot lately, and not of the pressed-wood bookshelf nuisance variety. I talk about Lean with my colleague and President of Rally, Ryan Martens. So when I talk about a leaning bookshelf, I’m referring to my interest in Lean in all its forms. I am talking about the books I’ve been reading  that pertain to Lean. And, more specifically, how can I turn my “Leaning bookshelf” into a continuous “learning bookshelf”?  How can I think about my evolution of thought and practice with regard to Agile as influenced by Lean? What could be a good, rewarding goal?

And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:

• How to learn
• How to teach others to learn
• How to encourage organizational learning
• How to avoid/eliminate re-learning

And so in this post, I thought I would share what I am reading, have read, or am about to read, and ask you for your comments and recommendations with regard to my leaning—>learning path. Some of the books may not look directly associated with Lean. I just know that they have been part of my lean learning journey.

The Contents of My Leaning Bookshelf:

1. Getting the Right Thing Done – Pascal Dennis
2. Hitotsubashi on Knowledge Management – Hirotaka Takeuchi and Ikujiro Nonaka
3. Implementing Lean Software Development: from Concept to Cash – Mary and Tom Poppendieck
4. Lean Software Development: An Agile Toolkit – Mary Poppendieck and Tom Poppendieck
5. Lean Thinking – James P. Womack amd Daniel T. Jones
6. Lean Transformation: How to Change Your Business into a Lean Enterprise – Bruce A. Henderson and Jorge L.Larco
7. Learning to See – Mike Rother and John Shook
8. Managing to Learn – John Shook
9. Product Development for the Lean Enterprise – Michael N. Kennedy
10. Ready, Set, Dominate – Michael Kennedy, Kent Harmon, Ed Minnock
11. Scaling Lean and Agile Development – Craig Larman, Bas Vodde
12. Scrumban – Corey Ladas
13. The Knowledge-Creating Company – Ikujiro Nonaka and Hirotaka Takeuchi
14. The Elegant Solution – Matthew E. May
15. The Toyota Way – Jeffrey Liker
16. Thinking Beyond Lean – Michael A. Cusumano and Kentaro Nobeoka
17. The Art of Lean Software Development – Curt Hibbs, Steve Jewett, & Mike Sullivan
18. The Goal – Eliyahu M. Goldratt

Looking at my leaning bookshelf and thinking of my focus on learning, I realize I haven’t included any Senge books or others about organizational learning. That will have to wait for another post.

What books are important to you on your leaning/learning path?