Friday, January 20, 2006

What happens when you don't "get it"

PragDave
Without exception, these early attempts at imitation failed: the car companies replicated what they saw Toyota doing, but only on the surface. They didn't really understand what was behind these practices. It was like trying to become an artist by copying the angle and velocity of the brush held by a master.
You see this happen often with various "agile" practices, like test driven development, XP, or Scrum. If all of the participants don't grok the practice, then they blindly execute a series of steps, and say, "See. It didn't work!"

There are two possible resolutions to this problem.

You can tighten up the process. Unfortunately, if you didn't "get it" in the first place, you are likely to cause more harm than good. At its pathological extreme, your team works like the staff of a McDonald's, with each person following a carefully prescribed methodology. If you are building the software equivalent of a Big Mac, then this might be perfect for you.

You can invest in your people. The old saw about giving a man a fish versus teaching him to fish applies here. For even the most simple project, it is nearly impossible to prescribe everything. At some point, personal judgement has to kick in, therefore it makes sense to equip the team with the mental tools needed to make the right decisions.

I don't mean to "dis" process, but I think you reach a point of diminishing returns, with "process improvement" whereas "people improvement" will always pay off handsomely.