MORE ENTRIES
- Whether to mention a pregnancy in a job interview
- A possible meeting protocol
- What are an end-user's responsibilities?
- Another take on opening PCs, or not
- Getting some process going
- Selling a more open environment to management
- Running an effective meeting
- Licensing rules for virtual machines
- The ROI of metrics
- Legal challenges to virtual machines
Advice Line | Bob Lewis »
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
RATE THIS ARTICLE:
February 23, 2008 | Comments: (0)
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
Posted by Bob Lewis on February 23, 2008 03:28 PM
RATE THIS ARTICLE:
-
- COMMENTS
|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
ADDITIONAL RESOURCES
- Virtualization: A Step by Step Approach to Success
- Dialing up Agility with Business Transformation
- 5 Things You Need to Know About Storage Virtualization
- Is your smaller organization ready for High Availability?
- Is system maintenance doing more harm than good?
- Virtual Test Lab Automation: Manage development infrastructure
