Recently I had a discussion with Alan Shalloway, the founder and CEO of Net Objectives. Alan is an industry thought leader, trainer and coach in the areas of Lean software development and the Lean/Agile field. He's a popular speaker at prestigious conferences worldwide, as well as a trainer and a coach.
An excerpt from this conversation:
Joe: My audience consists of quite a few continuous improvement type people very familiar with Lean and Six Sigma. So. we have a tendency to think about Lean in the Toyota sense. Does Lean mean the same thing in software?
Alan: It is definitely different. I'm glad you mentioned that because I joke that what I'm called precognitive impaired. I wish I wasn't because I happen to be in Las Vegas right now and if I was precognitive I probably wouldn't be talking to you.
A year ago I actually gave a talk at a Lean conference in Miami, where I was talking about thinking of Lean beyond Toyota. The reason is software is so different, even though the principles, which in my mind are respecting people, taking a systemic view, look to the system for problems, pay attention to time, get through cause, build quality and focus on shortening your cycle time as opposed to raising productivity. Shortening cycle time does raise productivity and it does raise quality and it does lower cost but if you go after those directly you often have an adverse effect.
You can actually think in terms of Lean as separate from Toyota. For software people, it's easy to do that. Think in term of flow and eliminating delays. Don't take the Toyota mindset of which is that of a manufacturing level.
The reason I mentioned the precognitive part is I actually came up with this talk because it always worried me that, what would happen if Toyota had a faux pas or a misstep? Would people say: "Oh, Lean's not working?" The truth is I think Toyota is a great company and I think they've had a major problem but the rules of the game, the things they've been doing for decades are there independent of themselves.
In other words, paying attention to being economically driven, doing product implementation in a way that speeds time to market, focusing on shortening delays instead of speeding up the exact work step you're doing is very relevant. In software the way it actually shows up is different, but the principles are the same.
I'll give you a quick example. In a manufacturing process where you have a line that has a very low variability of the steps, it can make sense after you've eliminated a lot of the delays to try to make every touch point to be a little faster. The big problem isn't really how it takes to say, write a test as much as the time between when you write the test and run the code or when you run the test and give the feedback.
Those delays in software are much more critical because the knowledge degrades much faster in the knowledge worker's mind than on the product manufacturing floor. Errors are harder to see in software feedback than in a physical component in an automobile.
The principles of flow, the principles of a system, and the principles of respecting people is the same. The way they manifest themselves are quite different. It's still Lean in my mind and I think it's a very powerful way to look at things.
Joe: I have always been disappointed that Lean stayed married to Toyota for so long because I thought what I've always called "American Lean" had a lot of value to it. It really has developed as a different animal in the software field. In software, you talk about Scrum, XP and Kanban, are they all agile? Are they all Lean?
Alan: Well, I would say yes. But I would say it's a different meaning now. I kind of view Scrum and XP as the first generation of agile methods and combine and what I'll call lean agile, which we kind of use both of those as a second‑generation or next‑generation methods. I say this for two reasons. One is XP and Scrum are very team centric. If you have a team that wants to embrace, that's good and they're very effective.
The XP, actually in particular, has some very good engineering practices. XP is known for the paired programming, continuous integration, upfront testing and things of that nature. But there are a couple things that are left out in XP and Scrum besides the team focus. Again, our experience as a team isn't really the severe problem but it's where all the drama is. So people are always looking, oh let's fix our team.
But in fact, you have other problems in an organization, such as if you're product portfolio manager isn't managing. By overloading and overwhelming the team, you create waste because you cause a lot of delay and it injects a lot of delay into the team because they're working on two or three things at once. It delays feedback and that makes it harder for developers and testers to...
It actually creates work for them to do because they have to rethink where they were, reset where they were. So more along that nature, a bigger view is necessary, and combine does that. At least combine creates visibility for product managers to what's going on in the team.
Now the other thing, though, is many agilists are very team centric and developer centric where they pretty much believe that is this craft, this is artisanship, and what you need to do is let the team figure out what's necessary. Now, I do believe teams need to figure out what's necessary. I do believe that's fundamental to any lean approach is you have to respect the team and the team's approach on how to implement their own solutions.
However, you have to also make sure that they are paying attention to what I'll call the laws of software development. Too much work in progress is not only going to slow you down but create more work. In software having tests and definitions upfront is usually extremely helpful.
So you need to have explicit policies. Now, you can change them and you should change them. In other words, as the team learns more, they should be changing their policies all the time. Basically the workflow should be defined, but defined as the best way the team knows how.
This is something that is embedded in Kanban and Lean Thinking. It basically says, look there's a system we can understand, we can talk about it, we can try things, and then we can make adjustments to it. Many in the agile community don't believe this. So when we talk about is it agile or not agile, you have to say, well what do I really mean by what agility is.
This is Part One of Two. 2nd part will post this Wednesday.
Related Posts:
Agile, Scrum, Kanban, or is it just a Marketing Funnel?
Pull: The Pull in Lean Marketing
Value Stream Marketing and the Indirect Marketing Concept
Marketing Kanban: Marketing Kanban
) and 
, two books around which Goal Systems International's internationally renowned Thinking Process Course is based; 
. Co-author (with Eli Schragenheim and Wayne Patterson) of 
and 
. 
, was a contributing author to 
, and has authored many articles including the ground-breaking article, Roots of Lean – Training Within Industry: The Origin of Kaizen.
says that the only way to reach common ground is to find fact-based answers to 5 very fundamental questions:
