Another diversion

I re-read Donna Fitzgerald’s Cutter Report on Principle-Centered Agile Project Portfolio Management. Most of you probably have never read this. It is only available by subscription to Cutter and therefore I am afeared woefully under-read by those who probably should read it. To make matters worse, I am not even going to synopsize it here – you should all request your management to subscribe to the service and when millions of people do, maybe the price will come down to the point where individuals can afford the collected wisdom of the institute. I will however raise a couple of points that the paper raised to me.

First, Donna starts off on the right foot – talking about a model of an Agile world that is centered on Principles over Rules (remember, we do not forsake that one the right, rather we hold more dear that on the left (No, Tom, I am not referring to Politics)). She states that “Agile organizations align first on principles; control-centered organizations align first on rules.” Donna goes on to define, very succinctly I might add, rules and principles as “Rules are ‘what to do’; Principles are ‘why to do’” and references Glenn Alleman with the insite. Thanks Double, Glenn. I might further simplify by using that old SAT notation: Principles are to Rules as Why is to How.

Next, Donna requites Patton in his famous statement: If you tell people where to go but not how to get there, you will be amazed at the results. This is true. I was told something similar in my youth by my first graduate level professor – It is not important that I teach you [topic], but rather that I teach you how to teach yourself. You will only really grok [topic] when it becomes clear that you are teaching yourself. Learning is self realization. I always found this a much more clear definition of Taoism than any other. Incidentally, my graduate work was in theoretical mathematics.

So, back to principles and rules. Principles guide actions. Rules prescribe action. Rules work well when actions are constant, like in manufacturing or other repetitive operations. Not too long ago, the common thought was that software development was associative to manufacturing. That being true, then prescriptive rules would certainly aid in development throughput. Unfortunately, this turned out not to be true. When we in the industry realized this, we reexamined the theory and discovered that no one software undertaking is really the same as any other. Therefore, rather than creating a machine (rules) that can churn out software, it is far more valuable to help the individuals understand why various steps are necessary and allow them to teach themselves what rules are necessary at each step in the process.

Teach the team to fish and this project be successful, allow them to become skilled and each of the subsequent ones will be so as well! Learning is self-realization. Self realization produces success.