Models, methodologies, menus and recipies

Dear Bob …

In this week’s Keep the Joint Running, “Capability Maturity Model revisited,” (2/18/2008), I think the most thought-provoking point of the whole interview was the statement that “CMMI is a model, not a standard.” I would really love to see you explore that thought a bit more, because I suspect it is very consistent with your view of the world (extrapolating what I think it means).

– Mature modeler

Dear Modeler …

Credit where it’s due: Hillel Glazer (my interviewee) discussed this as the difference between a menu and a recipe in an article he wrote for CrossTalk titled “Dispelling the Process Myth: Having a Process Does Not Mean Sacrificing Agility or Creativity,” (November, 2001). Menus tell you what but not how; recipes prescribe exactly how.

Hillel likens CMMI to a menu as opposed to a recipe. I’m not sure I buy this entirely. I’d say CMMI is more like a restaurant reviewer than either a menu or a recipe. Good restaurant reviewers are open to whatever type of menu a restaurateur chooses to offer, and the recipes followed in the kitchen. What matters is how well each restaurant executes based on its particular model.

At least, that’s what CMMI ought to be – a way of scoring application development in terms of how well it achieves what it sets out to achieve.

The menu/recipe metaphor is, however, worthwhile in the overall context of application development, and mirrors one leadership and one management principle that are worth exploring.

The leadership principle is the difference between delegating tasks (recipe) and goals (menu). This isn’t a matter of the right way and wrong way so much as it is a matter of how mature the relationship is between delegater and delegatee (which, usefully enough, has a parallel with SEI’s use of “maturity” in describing what it’s modeling).

Immature delegater/delegatee relationships focus on tasks. As the two parties work together better, the delegater assigns goals instead of tasks, leaving it more to the delegatee’s discretion to figure out how.

It’s a move from recipe to menu.

The management principle is the difference between processes and practices. The best illustration of the contrast I know of is that bowling is a process; hitting a pitched baseball is a practice.

In the perfect bowling alley, all lanes and pins are identical in all respects. In the perfect bowling alley, throw the ball exactly the same way each time and you’ll get exactly the same result every time. Quality comes from reducing variability.

If, in contrast, a batter was to swing a baseball bat the exact same way every time, he’d strike out every time, unless the pitcher was as big a schlemiel as he (or she) was. Batters have to outguess the pitcher, choosing from a “menu” of swing choices rooted in judgment and the ability to make split-second decisions , depending on what the ball looks like as the pitcher releases it.

The point of a process is to reduce variability so as to increase the consistency of results. Along the way, process aims to reduce the impact of individual differences – to make employees more interchangeable, just as cooks are more interchangeable than chefs. Recipes.

The point of a practice is to define a toolkit, and sometimes the basic steps a practitioner needs to use to achieve a successful result. Practices are the right solution in competitive situations where following the same steps over and over again just makes you predictable and easy to beat (hitting a baseball).

They are also the right solution for complex or chaotic situations, where analysis only gets you so far and judgment and experience have to carry you the rest of the way, which is why medicine is a practice rather than a process, at least thus far.

Practice and process are not, by the way, alternatives. They are endpoints on a spectrum of intermediate alternatives.

Or, really, I guess they’re two of three vertices of a triangle; the third being making it up as you go along.

– Bob