I am ever seeking to expand my Lean learning. This week I am attending and speaking at the Lean Kanban Conference in Miami, FL. I’m excited about the opportunity to engage in more Lean learning with some great people. Real conversations with the folks behind the books and on the forefront.
In my post on my Leaning Bookshelf about my Lean learning, I included Craig Larman and Bas Vodde‘s wonderful book : Scaling Lean and Agile Development, based on their collective experiences in very large (and distributed) Agile software development.
I love this book. Given my interest in the book, and knowing both Bas and Craig a little, I invited them to tell us a few things about themselves and the book.
Q. [JET] I’m very interested in Systems Thinking and yet don’t find too many people in our software development field talk about it. So it was a wonderful surprise to see it as the opening topic in your book.
Tell me, why do you feel it is so fundamental to the work of scaling lean and agile development?
[Bas] I do think systems thinking is discussed in the software development field. Gerald Weinberg, of “Psychology of Computer Programming” fame, has written three books on the topic. Of all the topics Jerry talks about, I think this is probably the one he has written the most about. Also, Mary and Tom Poppendieck wrote about the topic in their lean software development books. But perhaps you are right, it is still not covered enough.
In large-scale development everything tends to have an effect on everything else. It is easy and common to quickly respond to events or draw conclusions. For example, if there are many bugs in your system, it is easy to relate that to something you did recently and act based on that. When, after acting, the bugs increase or decrease, it is too easy to conclude that these two relate.
These mistakes in cause-effect thinking are especially common in large-scale development and therefore it is important to try to think of the system as a whole. System thinking helps thinking about the whole system and especially doing that together so that perspectives become aligned and a common understanding is created.
[Craig] The large-scale immediately (and usually, painfully) bumps us into the organizational structures and policies, and their impact to support or inhibit the flow of value. And large-scale development organizations have more formal policies and structures compared to the small-scale. The organizational design reflects the psychological and systems insight — or lack thereof — of the people in management.
Most business (and broader) problems have their root cause in mental and emotional limitations or weaknesses: command-and-control management and “Theory X” managers, not seeing the true nature of causal relationships, not grasping non-linear effects and delays in the workplace, lack of kindness and transparency, and so forth. And it extends to deeper issues: awareness of and healthy suspicion of our own mental models, double-loop learning, skillful listening and conversation, emotional intelligence … Great organizational designs reflect people in leadership with great personal mastery — and part of that mastery is people who can do systems thinking.
Q. [JET] Craig is a great guy. I’ve enjoyed the few times I’ve had to talk with him. As you were writing the book together, what would you describe as something in particular you were grateful that you learned from him?
[Bas] The book is a result of years long co-operations and discussions. So to limit what I learned from him to writing the book wouldn’t be fair.
Over the years, I mostly appreciated the countless discussions we had on large-scale development. I’m not always good at expressing my thoughts and Craig is a patient listener who really tries to understand different perspectives. Then, he is not shy on giving very direct feedback. I think it’s these discussions (and the ones we will have in the future) that I’m most grateful for.
Then, specifically to writing the book. I’m not a native English speaker and not an very experienced author. I don’t think I could have learned more about English language and writing in a shorter period.
Q. [JET] I love the “Try-Avoid” model you use throughout the book as well as inside the covers. It seems to walk a nice tight rope between prescription/non-prescription. What inspired you to come up with this approach?
[Bas] That is interesting. I wish I could take any credit for this, but I’m afraid Craig actually made that decision. I even argued against it since I felt that it would hurt the readability of some parts. Not all parts are easily put into this “experiment-format.” After many discussion on the format, I agreed with going forward and over time started to appreciate it.
What inspired the approach? I’ll let Craig answer this more thoroughly, but the main thing was the illusion of knowing the answer. Every situation, product, culture and company is different. Every product we go, we learn new things and experiment with new ideas.
So instead of giving “the solutions” we’d like people to think about their context and about the different experiments they could do. Learn from these and find themselves the best solution in their context.
[Craig] First, to reiterate what Bas said, kaizen in Toyota, and empirical process control in Scrum, emphasize a culture of structured experiments, rather than defined process or a cookbook of process recipes to follow, and I hoped to emphasize that notion.
Second, I become frustrated when reading a book and I have to dig around in the text to find specific actionable advice the author is offering. I want to respect my reader’s precious time, and make it as easy and immediate as possible for them to find that.
Q. [JET] Several years ago Bas, you and I roamed through Powell’s bookstore’s used computer books in Portland, Oregon together. That gave me a glimpse into your love of books; your bibliography for “Scaling Lean and Agile Development” is yet another indicator!
So here is a tough question for you: what were the top 5 books that inspired you in writing this book?
[Bas] Yeah, the visit to the bookstore was nice. :) I’ll change the question a bit. I’ll answer it with the top 5 books that inspired the content of the book… but weren’t mentioned in the book. There was no appropriate place to recommend them.
- - Debugging the Development Process – Steve Maguire. Steve wrote two classics in 1995. One related to writing code “Writing Solid Code” and one related to the processes for writing code called “Debugging the Development Process” which describes how he managed software development groups within Microsoft. The book is full of insightful advice about software development and it is a book I always get back to and re-read parts of. Still today, most of Steve his writing is exceptionally relevant.
- - Secrets of Consulting – Weinberg. Gerald Weinberg has contributed so much to the knowledge of software development. Not just his 40 books, but he has a group (Weinbergians) who he trained and is still in contact with. I know some of them and Weinberg’s influence is visible. Of all the books he wrote, this one was perhaps one of the most insightful ones. It is, like all his books, full of stories and small insights on working together with people and companies.
- - Juran on Quality by Design – Juran. It is quite amazing that we did not have any place where we could recommend the work of Joseph Juran. Juran, next to other “quality gurus” such as Deming, Crosby, has been a huge influence on my personal thinking about organizations and developing quality products. I especially enjoyed this book of Juran and his insights related to quality planning and product development.
- - The Gold Mine - Balle and Balle. We recommended a lot of lean books, but not this one. This lean book is written as a novel, which makes it hard to find a good place to recommend it. It is quite much like “The Goal” which is the well known business novel introducing Theory of Constraints. The Gold Mine, however, didn’t introduced any new concept, but it does a great job of clarifying lean in a form that is easy and engaging to read.
- - The Peter Principle – Lawrence Peter. Some organizational behavior is so taboo that you shouldn’t be talking about it. But, of course, you can ridicule it. Thats exactly what the Peter Principle does. It shows that human society is rising in the animal hierarchy and has reached its level of incompetence. Books like this one give a great perspective to behavior in organizations and are very funny to read. Painful, but true :P
[Craig] In the same spirit of Bas, on relevant works that weren’t really emphasized:
- The Birth of the Chaordic Age by Dee Hock; and,
- various books by Ralph Stacey on the illusion of the belief of how much we can influence or control our complex non-linear social work systems (Stacey’s work is touched on in Beedle and Schwaber’s first Scrum book). There is a deep assumption in most people at work: we can control complex things. Once a great doubt arises about this core assumption, it opens a major can of worms that pulls the rug out from underneath many organizational design ideas.
Q. [JET] You mentioned to me that you and Craig discovered that in the writing of your book, you were uncovering “an embarrassment of riches”. This led you to decide to divide your work into two books.
What sort of preview can you give us to the material coming in the second book?
[Bas] Oh yeah. We kept saying “Oh that must be there.” Then we kept removing things to only leave the essentials. But soon it became clear that all the things we wanted to say would not fit in one book. Influenced by Don Reinertsen’s “The Design Factory,” we wanted to split the book in thinking and action tools. However, we had a group of ideas which didn’t fit well in either, so we came up with the “organizational tools.” Suddenly we had two logically consistent books and decided to do that.
The second book will be the “action tools.” The goal is to give concrete advise on how to do particular practices. How to do planning? How to do design? What do with with multi-site development? What to do with legacy code? All of these chapters will use the action and organizational tools from the first book. When people read the book, they ought to have concrete experiments for their current situation.
[Craig] We maintain a current-vision TOC at:
Chapters include: Contracts, Offshore, Multisite, Product Management, Legacy Code, and more.