PM World Today Letters To The Editor

A Happy New Year to all the Friends of the PMFORUM world-wide.

David Curling
Webmaster PMFORUM

Glen Alleman replies to Max Wideman's Letter on Agile PM...

Not sure where your going here Max.

Are you saying that since the end is not in hand for software development that increment movement toward that goal (via new methods like XP and SCRUM) add no value to the quest?

I might also ask "does your colleague practice any of the agile practices for money on a daily basis?" We do, so I have some experience in their appropriateness. There is certainly many gaps to be filled in the quest for understanding, but one critical aspect of filling the gaps in software development of the try some of the things out first hand, learn from them, make improvements.

Regarding your description of PP, I would recommend some background reading before engaging in an analysis. Your description does not match the practice of PP as it is performed.

http://pairprogramming.com/ is one place to start, but there are others including recently published books listed on Amazon.com.Dr. Williams is currently a resource of much of the research on PP in the academic community.

I'd be interested in hearing how the practices of XP, SCRUM, and its derivatives are naive in the way you suggest, especially from your direct experience. How does "imposing certain configurations" create this naive understanding? I'd especially be interested in how your direct experiences with methods like XP or SCRUM have brought about this opinion.

Footnote:

Since Max seems to be addressing some issues with Agile PM and Agile Development, maybe a link to some reliable sources of information are needed.

Here's a starting point for comparing various methods
http://www.agiledata.org/essays/differentStrategies.html#ComparingMethodologies
Glen B. Alleman
Director, Program Management Office
Kaiser-Hill LLC
Rocky Flats Environmental Technology Site
Golden, Colorado
glen.alleman@rfets.gov+1.303.966.5865 Office
+1.303.994.0874 NexTel

Max Wideman writes on the October 02 Viewpoints Column - "Agile Project Management and Earned Value "...

The introduction of the label "Agile Project Management" appears to be a distraction from the real debate in the technical literature which concerns "Agile Software Development". It does nothing to enhance the image of project management. Unfortunately, the name itself is not inspirational.

According to my thesaurus, the meaning of "Agile" is: Synonyms: Active, Brisk, Brisky, Catty, Lively, Nimble, Sprightly, Spry, Violant, Zippy Near Synonyms: Adroit, Deft, Dexterous, Fleet, Quick, Speedy, Limber, Lissome, Lithe, Supple, Light-foot, Tripping

The Synonyms are not exactly complementary, which is perhaps why I don't like the label. However, the Near-Synonyms are more favorable, so perhaps they should rename it to "Adroit (whatever)". But I am intrigued by the technical discussion going on (elsewhere) about this "agility" thing, so I asked my colleague: "What is your take on 'agile' (software development) process techniques - A serious methodology, or a "flavor-of-the-month" spectacular (a device to circumvent management constraints)?" Here is the response I got:

Hard to sum up in a nutshell. And also of note: "Agile" is very much overlapping with XP: eXtreme Programming, so hard to separate features of one from the other.

I think my basic take is this: These encompass some fairly agreeable ideas, which the industry needs to pay attention to... but I'm discomfited by:

a) the need to present them as "special" because they seem so obvious and basic.

b) attempts to present the ideas as a formula that participants are to be shoehorned into to automatically obtain X% return on investment.

For example, one idea from Agile is "pair programming". That is, instead of each programmer working away in their own little box, and coordinating with others only periodically, and then only relatively superficially, instead programmers work in pairs, "joined at the mind", so to speak -- creating a design or code through a continuous interaction, one or other doing the typing (or sketching) while the ideas flow and the responsibility to stay focused is shared.

Yes, that's a mode of working that *can* be productive, I've done that myself -- for a portion of the work.

But to me this insight is too simplistic. The point is that in developing a system, developers would be involved in a whole range of discovery, interview, analysis, design and construction activities, and these call for a whole range of thinking scenarios, from boisterous exchanging of ideas to quieter but more in-tune exchange between two people, to solitary reflection and deep puzzling.

Certainly if you have a process where people are *only* shut in their boxes, then adding permission for two people to work together vastly increases the variety of thinking opportunities applied to the effort. But that doesn't mean that the pair configuration should thus *replace* all other configurations.

So, though this is just one of a number of interesting recommendations, I describe this at length because it is representative of recommendations that are illuminating, but which to me seem naive.

The basic shortcoming in software management is a ridiculous level of naivet� regarding how to accommodate the "engine" that's going to do the work: the probably several minds that you are going to engage on the task, and the full spectrum of psychology which that entails.

No one contradicts that computers need clean power and cleanly operating networks. Yet few seem to understand the requirements of the far more complicated human "computers" which are ultimately going to produce the intellectual output. These are requirements for facilitating and motivating thinking (of individuals and groups). That's what it should be all about, not about *imposing* configurations that *look like* certain kinds of thinking.

Or to put it more cynically, a lot of the continuing controversy (in which Agile and XP are merely recent symptoms) is to do with management trying to select a process in which to cultivate extended, deep, focused (and sometimes broad) thinking, when they themselves are unaccustomed to that sort of intellectual activity and living within a business milieu that is, if unmoderated, highly disruptive of such thinking.

So, I somewhat admire Agile and related stuff for what it overturns in previous stuffier configurations, but still think that it's not there yet. Maybe a necessary evil to give better cover to people who are capable of organizing themselves in psychologically more healthy and productive ways.

Clearly a lot of people still have a lot to learn, not just about software development but about project management as well.

R. Max Wideman
Vancouver, BC, Canada
max_wideman@sfu.caTel & FAX: 604-736-7025
Web http://www.maxwideman.com

Max Wideman comments on Ken Ganshirt's Dialogue on Scope Verification published in the December 02 Viewpoints Column.

Ken Ganshirt raises some interesting discussion on the matter of scope, choosing to identify three different kinds of scope, namely, project scope, product scope and process scope.

Project scope, it appears, refers to the extent of the project management effort applied to the project. Surely, all projects should be managed in their entirety so that such project scope should not be in question. To reduce project scope to say "We'll have a project manager to keep an eye on the budget" (as in some instances I've seen) can hardly be described as project management.

The project that Ken cites is a "business process change" that is enabled by new hardware and software, quite a common situation. Since "scope" is defined as "product deliverables" and that both the "change" and the hardware/software are deliverables, then it follows that the project's (entire) scope, i.e. project scope, is the combination of the two (or more) elements. True, they are different animals, and need to be managed somewhat differently, but they both need to be managed. Failure to manage effectively either the one or the other is a failure of the project's management.

Thus what we have are (at least) two major WBS work packages, or maybe sub-projects, that should be managed accordingly. I don't see that labeling one as "process" and the other as "product" contributes anything other than perhaps to highlight a deficiency in the original
project management.

M
"R. Max Wideman" max_wideman@sfu.caWeb http://www.maxwideman.com