Why lean software doesn’t work internally

I was going through the Joel Reddit and after reading a very good article in the NY Times comparing development practices between Google and Yahoo, I came to another article talking about lean software development. As one that makes software and one that actually read (half) a book on the Toyota Production Method, the word “lean” triggers my interest when in the context of making products.

The NYTimes article talks about how Google gets new products done very quickly and to the public with a very high “wow” factor, but many of them are without integration and missing what many users consider basic features. It then compares this to Yahoo’s method of following a more traditional development process where you get specs, build, test, and document all before you give it to the public, which takes longer. It then asks which method does the pulic prefer: quick cool-yet-incomplete products, or more complete but delayed products?

The article mentions the scrum method, which basically means a new product every 30-days. Scrum is a method that relies heavily on lean software development.

The second article discusses the lean process, which (in essence) means stripping down a team to a minimal set of people, and also skipping all the formal details of development for the sake of getting products out faster. Getting things out faster - and half-built - means they get incomplete products, but can get feedback faster and find out there is actually any interest so they know if they should continue.

This method is great for Google and Yahoo, but agile practices does not work for internal company development. I’ve tried. However, I must disclaim that I am but one man. If there was an actual team of developers, it might be better, but even then there’s one problem with the whole practice. Companies can just buy things.

We’ve argued the benefit of internal products before, and I believe that internal products hit the bullseye for custom and specific company/department needs. But if you try to employ a scrum-type inside the company, you’re shooting yourself in the foot because employees will not tolerate a feedback cycle of development.

Some people may understand the benefits, but most will not. Most will go try the new, half-built, feature-weak program and when it doesn’t do what they expect out of the gate, they’ll never come back. They will abandon the product and just ask for an off-the-shelf product to replace the one you “tried” to get right.

You can still do upgrades and updates to your programs, but if they are not complete and practically full-featured then there will be no buy-in. No buy-in means you are in danger of losing credibility as a developer, which means you’re on your way to losing your job.

You can still get products out the door fast - I can get a good-sized product out in 60-days - but you still have to go through the steps of specs, design, planning, building, testing, and so on. Plus, internally, you already know people want the product because they asked you for it. You don’t have to find out if they really want it.
When I started my job, I followed a quasi-agile method because I needed to impress people with a quick launch, and it worked. The programs were stable and hit the core of what people needed, but very quickly the novelty of quick launches wore off because people started to see a trend in my work. I had a quick turn around but they were all feature weak; I got the car done fast with four wheels and an engine, but after one time around the block, you really wish it had come with A/C and a radio.

Lean methods are great and I find them fascinating. After I read about Toyota’s agile methods for car manufacturing, I tried to think how I could apply it to my development techniques. I had some ideas and tried them, but quickly realized I’m already lean because I’m all by myself. You don’t get much more lean than that!