Principles, not Processes

In Lean Software Development, Tom and Mary Poppendieck discuss the story of the Freemont, California GM plant which was completely turned around in a joint venture between Toyota and GM. Toyota ran the plant, but rehired the GM workers that had been working there before the plant closed down. GM has not been able to duplicate the success of that plant, and Tom and Mary say:

We believe that transferring practices from one environment to another is often a mistake. Instead, one must understand the fundamental principles behind practices and transform those principles into new practices for a new environment.

This quote was particularly interesting because a common question on the XP lists is about what the minimum practices a team can do and still be called “Agile” or “XP”. Indeed, Ron Jeffries often is seen saying something along the lines of what does it mean to “be XP”? There is no reward for being XP, except delivering value to your customer.

So, if a team wants to realize the value from XP, how do they do it? If it is a top-down implementation, the team gets Kent Beck’s book, maybe gets an agile coach, or some training, and goes for it. Because surely if they just follow the prescription from the book, they too can become agile, right?

Actually, probably not. The only way to really become agile is to look at the practices and understand the principles behind why you would want to do them, then fit them into your organization. For example, one organization I was with had planning games, but they were basically all of the developers sitting around the room listening to a manager explain the velocity for the previous iteration, then rehashing the spreadsheet which had what they were doing next. There was very little planning, and very little value from the meeting. But the meeting went on anyway – because it was in the book.

After a while, the developers began to not like the meeting, and finally it became evident that there wasn’t a lot of value from the meeting, so it was cancelled. But in talking with some of the developers, the thought of bringing up the idea to cancel the meeting when it first became evident to them that there was little value was difficult. Why? Again, because that was the XP way, and without a point of reference to go by, or a thorough understanding of the principles behind the planning game, they didn’t know how to make it better.

Perhaps not surprisingly, the advice from Tom and Mary don’t just apply to Software Development. When I was a firefighter you couldn’t just grab a hose and spray it on a fire. You had to understand what was going on. For example, in a typical house fire, the fire gets put out not from water, but from its conversion to steam. It literally suffocates the fire. So you take the hose, give it a short squirt or two, and that knocks the fire out. Then you can go in and really see what is going on, and be a lot more targetted in your attack.

Until we understand that it isn’t the practices, dummy, it’s the principles, I’m afraid that the thing some companies call “Agile” will continue to be misrepresented and misunderstood, turning developers and business people alike off on one of the best ways of developing software I’ve ever worked in.