James Coplien in a past Business901 Podcast (Related Podcast and Transcription: Is Architecture Needed in Agile?) gave an interesting overview of Lean and Agile. Not sure I can do it justice with just this excerpt but see if interest you enough to go to the long version above. You can find Jim at Gertrud & Cope , a small family business driven by Gertrud Bjørnvig and Jim Coplien
James Coplien: Unfortunately, what happened in the market is, first of all, people took this very one-sided view. They took some provisions of what are in the Agile manifesto, which is this document that kind of launched the Agile movement. It came out of a meeting of these 17 guys in the US, back 10 years ago.
The other thing is that, of course, a lot of people kind of interpreted it in their own way, and then, added a lot of stuff that wasn’t intended. But more importantly, Agile really was a reaction against some of the methodological excesses of the 1980s and 1990s.
And too often, they ended up throwing the baby out with the bathwater. There’s a lot in there about doing, and building software, and talking with customers, and so forth. But there’s very, very, very little about thinking. So, one of the casualties of Agile has been architecture. The Agile people would tell you that architecture is only emergent and that you shouldn’t do any upfront thinking because its waste and you’re not going to need this. I think that posture largely came out of ignorance on the part of the young, eager folks at the time to try to do something good.
So it was well meaning, but it really ended up doing a decade of a lot of damage. What I’m trying to do is get the pendulum to swing back somewhere near the middle, where we can blend some of the principles of Agile with the more deeper and older and more classic Lean principles of thinking and upfront planning.
Joe: And is that where Lean fits in then?
Jim: The Lean part, a lot of it has to do with the upfront planning. Some of these notions that we find in Lean like decision structure matrices and this whole idea that you’re thinking about what you’re going to be doing before you do it. Now that doesn’t mean you commit to doing it. Of course, you still have some of the so-called Agile principles where you can change your mind. But, of course, those were fundamental to Lean long before Agile came along. And since you’re a Lean guy and this is a Lean audience, there’s just, I think, a lot of common misconceptions in the broad software world about the relationship between Lean and Agile. I think that also explains a lot of the posture of the book. A lot of people will come out and say, “Well, Agile and Lean are the same thing,” and some other people will say they have nothing to do with each other, and both of those are wrong.
Most of what you find in Agile was already there in Lean, both in terms of what’s in the manifesto and in terms of the culture and the practices. There are some emphases that Agile have that are good and are useful and go beyond Lean. But probably the main distinguishing factors of Lean that come out in the Lean Architecture book that you don’t find in Agile are this notion of doing some upfront planning and looking at some issues of system form, of architecture, and of some of the focus you find in Lean on the process, whereas the focus in Agile is solely on the product. I think Lean has more of a balance of these two.
Joe: That’s what I found in the book when I first picked it up and looked at it, it was like a Lean book to me. It wasn’t driven, let’s say, by the software side of it where I would get lost. That connection between Lean and Agile, I thought, was made very well because everybody, Jim, always tries to make their own methodology, the umbrella, the thing that’s bigger than life, ’cause that’s my methodology. I thought you put a nice balance to that in the book.
Jim: Well, actually that’s good to hear on both counts. So first of all, thanks. That’s good feedback that is general. And yes, I agree that everyone has their hammer and so every problem looks like a nail. But one of the early reviews, I think it was maybe Trygve Reenskaug’s review said something very similar to what you just said. It said this book isn’t just selling a given technique. What it’s trying to do is look at the Lean principles and it’s not just a methodology. It’s taking people down the path of thinking, of adapting some of these principles to their own industries, their own products, using the principles as a touchstone to figure out what they’re going to do.
Joe: I found it interesting that you talk about Lean and then thinking, kind of blending them two together.
Jim: Well again, as we briefly discussed maybe before you started the recording, Lean means many things. Lean was coined by these authors of this great Lean book back in 1991 in the US. It was actually about the Toyota production system, which, of course, has swept a lot of the industry in Japan. They coined the term “Lean” for it. That helped popularize the term and some of the approaches in America. GM was doing some really good Lean things for a while that were part of Toyota’s early forays into the American market through the NUMMI plant. Ford tried to get on the bandwagon as well. But if you look at broad American industry, a lot of places that use the term “Lean,” it’s in a different sense than the Japanese use it. So what I’ve been doing for years and years and years is making an investment in trying to understand what does Taiichi Ohno mean by Lean? What did Takeuchi and Nonaka mean by what they were talking about in “This New New Product Development Game,” which is the paper that appeared back in 1984 in the Harvard Business Review that launched Scrum? Trying to go back to those fundamental roots.
I know that Jeff Sutherland, who’s the inventor of Scrum – Jeff and I worked together… also was very inspired by elements of Japanese culture and even as deep into issues as Buddhist meditation. Now this gets the designer and the enterprise into a thinking mode where you’re not just reacting but you’re thinking about how do I fit into the larger ecosystem? How do I fit into society? How am I going to make a fundamental contribution in the society in which I am indebted? What does value mean? What are my value streams?
As a consultant when I go into companies, one of the things I’ll ask them is, “What are your value streams?” And they say, “Duh?” And, “Oh, what are your products?” And I’ll often get an answer that “Well, you know. We have two products” or “We have 200” or “We have 40. Well, it’s something in between. Well, we do stuff and we make money.” And they don’t really have this thought, this discipline, of what value means to them. So they’re very Agile sometimes, but they’re not Lean. This leads to all the more commonly known Lean consequences like waste and inconsistency and a lot of the practices and tools.
What I find in the broad industrial world, particularly in the US, is they know the tools, but they really don’t know the underlying principles and structure. What I’m trying to do with this thinking, and particularly upfront thought that comes with architecture, is take people more in that direction.
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook