How I Discovered Lean

Before I delve more into Lean, the best management practice to support Agile, I would like to step back and talk about how I got to Lean. The path I took influences my thinking about the Agile/Lean integration. If you want to skip this post, that is fine. It adds little to the overall discussion.

I have been writing code a long time. I was around when waterfall was introduced as a management process. Two things happened to me in the late 80's:

• I had a chance to study Just-In-Time (JIT) when getting my Masters degree, taught by a leading authority, and
• A colleague from IBM Research gave me a copy of Smalltalk.

I found both topics fascinating, but did not connect them at the time.

The Lean (JIT) Path

Lean is the new name for JIT, a more appropriate name as JIT moved from manufacturing into other sectors. In my graduate studies, I actually wrote a paper for applying JIT to software testing. The thesis was a focus on waste.

When doing testing under waterfall at the time (20 years ago), specialized testers take the code base and run their predefined manual scripts. As a bug was found, it was documented extensively, then the tests were continued. Often, another bug was found quickly. It was documented as well, and tests were again continued. And so on.

As a recipient of these bugs (ie, the programmer that injected the bug in the first place), the first bug was usually real. The second bug, however, was often the same bug just showing up again. As I analyzed the bugs, it would get more and more difficult to discern whether a bug was really a new bug or not. I just wanted to throw those later reports away. But the process dictated that I close the bug as "unable to reproduce" or "duplicate" to complete the bug cycle.

Armed with JIT and its idea of waste, I saw the situation in a different light. The tester was creating work for me by testing after finding the first couple of bugs. It was unlikely these bugs were new. Regardless, I would probably ask the tester to reconfirm the bug after fixes to the earlier bugs. This was all waste!

Rather, the tester should stop testing after finding a couple of bugs. (At the time, I suggested 3 might be the magic number. Now I lean more toward 1 is enough.) My professor loved the idea; the first time I tried it with real testers, they were horrified! The testers were measured on completely running the tests (whether there were bugs or not). They get credit for finding bugs. Did I want them to just sit around and do nothing? Surely, it was more productive for them to at least try the tests.

But it wasn't more productive for the team for them to try more tests. They were better off just sitting around (or better yet, test something else). After a month or so of agony, they began to understand the message, dumped their original metrics, and starting becoming more effective testers.

The OO Path

Although I had early exposure to Smalltalk, my current job didn't let me do anything except play around with it. I do remember loving the introductory books and the cool tools. But when it came time to actually solve a problem with it, I was absolutely clueless.

When I went out on my own as an independent, I finally began to understand the paradigm. For me, the trick was coding GUI interfaces. In most UI frameworks, the system calls the code when something needs to be done. The application is not in control -- the user is! Once I got this reversal, the message-passing metaphor of Smalltalk began to click. I eventually wrote commercial Smalltalk, found a mentor who was part of Ward Cunningham's original team, and began to really learn Object-Oriented Programming. This was still, however, a long 5-6 year process.

Then Came Agile...

I was just starting an OO consulting gig when I attended OOPSLA '98. At a birds-of-a-feather session, Kent Beck, Ron Jeffries, Ward Cunningham, Martin Fowler and others presented eXtreme Programming (XP). There was no book, just a one page handout of the 9 practices and a diagram of how they related to each other.

Having been raised in the Ward Cunningham School of Objects, it instantly clicked. My client agreed to these ideas, and we embarked on an XP project.

I realized quickly that we were in a production process. And Lean was a perfect fit for code production under Agile. We started focusing on waste and cycle times. We immediately started running cycles faster than the stock XP suggested, simply because we could.

I have exclusively done Agile projects since then (1998). I continue to apply more and more Lean management principles as I go.

A Different Path to Agile-Lean

Mary and Tom Poppendieck lecture and write about Lean being applied to Software Development. They describe it very well in their two books. Mary got to the Agile-Lean by a completely different route.

What is marvelous is that we (and many others) have gotten to the same point. Lean is the appropriate management model for Agile.