Thinking for a Change

In a previous post, I urged you to go out and learn a bit more about non-IT stuff, so that you can talk to the rest of the company. I don’t usually follow my own advice, but this time I have: I’ve bought a few new business books.

This week I have mostly been reading “Competitive Advantage”. Competitive advantage is a management classic by Michael Porter. It was recommended by John Favaro during his XP2005 keynote.

In the book, Porter dissects the activities of a company in a “Value Chain”. He analyzes how companies can gain and sustain a competitive advantage. A company can either have a “differentiation” or a “cost” strategy.

The book is a 2004 edition, but I was disappointed to see that it’s essentially the 1985 version. And it shows. I haven’t read the whole thing yet, but there are only a few vague references to “methods used by Japanese companies”. For example, if we want to respond to the customer faster, Porter recommends to increase inventory or to get surplus capacity. Ouch! What about reducing inventory, increasing inventory turns, removing waste, establishing flow, reducing cycle time, building quality in…?

I’m also reading Bill Waddel and Norm Bodek’s “Rebirth of American Industry“. This one is more fun and easier to read than Competitive Strategy. In the book, Bill and Norm describe the history of (car) manufacturing. From the Lean early Ford, over Sloan and Dupont’s definitely not Lean GM and back to Lean Toyota.

Their main point is this: Sloan and Dupont created a management and accounting system at GM that essentially goes against Lean, as it considers inventory an asset and labor a liability. The strengths of the early Ford and current Toyota production system is that they focus on cash flow and empower their employees to continuously improve production processes. The Toyota Production System didn’t spring fully formed from the (brilliant) minds of Taichi Ohno or Shigeo Shingo. They evolved gradually, by solving problem after problem.

The GM management and accounting practices went on to become the de facto methods in American industry. As everyone was doing it, nobody really noticed the inefficiencies in the system. Until the Japanese arrived…

I believe the same is true in software development: there’s something structurally wrong in management and accounting (measurement) of IT projects. These lead us to work in large batches (have to keep those analysts busy!), to count work in progress as value and to have long cycle times. Agile, like Lean, will always be limited to implementing a few easy technical tools that don’t require us to change the way we work (unit tests, continuous builds, refactorings), unless we can change the way we manage and measure. And if the want to do that, we have to speak the lingo. Back to Porter…