RE: Managing Extreme Programming

Alleman, Glen B. said
> 
> [The hypothetical "Managing XP for managers" book] should tell them:
> 
> (1) How to embed XP "in a room" and isolate the internal 
> aspects of XP from the larger corporate activities. Since 
> most real would project have multiple suppliers, producing 
> components outside the room (the curse of COTS), and are 
> focused beyond the next iteration (say 3 years down the 
> road), the mixing of these two paradigms is needed for 
> anything involving integration and subcontractors.

What does it mean to "embed XP 'in a room'?"  I don't understand your
terminology.
 
> (2) How to "digitize" the overall schedule (say 3 years and 
> $100M of radar systems development of hardware, software a 
> flight platforms) down to daily builds, and bi-weekly 
> iterations and monthly releases of software for the project.

What does it mean to "'digitize' the overall schedule?"  Again, I don't know
what this means.
 
> (3) How to map the "velocity" metrics in unit-less measures 
> to Earned Value in dollarized measures.

Hmmm...  Velocity has to do with work expended, not value created.  However
if the stories are given value estimates, it would certainly be easy to
calculate value produced, and estimated to be produced, over time.  Is that
what you mean?
 
> (4) How to use "yesterday's weather" to forecast the Estimate 
> at Completion.

Estimate of what?
 
> (5) How to project schedule variance for the software 
> component in the same units of measure as the iron and flight 
> equipment.

What units of measure might these be?
 
> (6) How to interact with the XP development team in terms 
> they know and understand (velocity, stories, etc.) while also 
> interacting with customer in terms they know and understand 
> (SV/CV, SPI/CPI, CDRLS, etc.)(Our chose your own customer 
> vocabulary).

More terms you need to define.  I do not know these.

> In our domain it is a complete myth that the 
> customer will be in the same room as the developers. The 
> customer is in Reston VA, and wears blue starched uniform to work.

This aside has nothing to do with anything.  You know full well that when
the end customer is not available, someone has to play the Customer role.
Someone has to understand the business issues and make decisions.  The
technique I've seen in some non-XP development, of leaving things fuzzy and
then blaming the development team at delivery or project cancellation time,
is not an acceptable behaviour.
 
> (6.1) How to dollarize the velocity units in terms the 
> project accounting folks will accept.

Lets see...  If x developers average y units per iteration, and the
fully-loaded cost of those x developers is $z per iteration, then the cost
per velocity unit is $z/y.  Not so difficult.
 
> (7) How to layer the various XP and Traditional practices so 
> that they can all work together:
> | XP hourly
> | XP daily
> | XP Iterations
> | XP Releases
> | Project Recognized value
> | Project Delivered Value
> | Project EAC
> V Project Completion

I do not understand what you mean by this chart.  I also don't know what
"traditional practices" you mean.
 
> (8) How to define these interfaces so that both sides concur 
> they understand the vocabulary, outcomes, and constraints.

What interfaces are "these?"
 
> (9) How to scale XP from a "tracker" based project management 
> process to a Earned Value Program Management process (our 
> your favorite way of managing to portfolio of project 
> components making up the system).

You'll need to explain this, also.
 
> (10) How to merge quick turn around, adaptive requirements 
> fulfillment and iterative value "tracking" with the big 
> picture view of the integrated project, EAC prediction, and 
> end-to-end value tracking (not just iteration level). 

Here, again, I don't understand what you mean by "integrated project, EAC
prediction, and end-to-end value tracking," but it seems easy enough to roll
up any measurements made at the iteration level to longer-term values.

Glen, the definitions I ask are serious.  If your message was intended to be
honest communication, then you'll have to educate me on what these terms
mean.

If your message was intended to dazzle me with "management speak" that I'm
not supposed to understand (I've certainly know plenty of people who
intentionally spoke in an obfuscated fashion to demonstrate that they were
the alpha dog and others didn't know what they purported to know.), then
don't bother to explain and I'll just add you to my twit filter.  I'm here
for communication, not for playing power games.

 - George
   "Eschew Obfuscation" -- Norman Cousins, editor of the Saturday Review

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Turn flat surfaces into speakers with the Soundbug.
http://us.click.yahoo.com/QWAVSC/onCFAA/xGHJAA/nhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/