Leaning

Fuzzy again...

The Poppendiecks are my favorite methodologists. I have yet to be disappointed with Lean thinking.

(Get their books if you have not yet. And read their other articles too.)

Mike has some good quotes and I'll pull some others out here. Another nice article from that pair. They provide a setting for having discussions with the rest of the business, less tied to the jargon and rigidity that has overtaken a true "agile" approach to software development. Here they are quoting Taiichi Ohno of Toyota...

"Years ago, I made them hang the standard work documents on the shop floor. After a year I said to a team leader, 'The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.' I said 'What do you come to work to do each day? If you are observing every day you ought to be finding things you don't like, and rewriting the standard immediately. Even if the document hanging there is from last month, this is wrong.' At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them. This gave me a good reason to scold the team leaders, saying 'Have you been goofing off all month?'

"If it takes one or two months to create these documents, this is nonsense. You should not create these away from the job. See what is happening on the gemba and write it down."

Years ago I attended several weeks of CMMI training from a couple of really good instructors from SEI. They taught us essentially this. Start where you are, make small, incremental improvements.

I was the "agile" person there, and of course identified with this immediately. Most of the other people there were from "the CMMI team" whose job it was to "improve" everyone else. Unfortunately after years of discussion, they never really understood how to make improvements. To a large degree this was due to the fact that none of them ever developed much software, ever made many improvements, and were determined to force a made-up, "ideal" process on all the developers and project managers, who did nothing but resent it.

And so it goes. Now we have "agile" groups acting just as rigidly about their crown jewels.