RE: Managing Extreme Programming

George,

I think your response to Glen is a good indicator of why a good Managing XP book might be in order.  Two things occur to me while reading your response:

1.  There are very definite terminology gaps between "professional managers" and "professional programmers" and we need to find ways to bridge them.

2.  There is a definite hostility towards those who use a different terminology.  

I thought Glen's posting was an excellent one to feed the discussion of how to manage an XP group.  I would also like to turn your last paragraph back at you.  I know quite a few "traditional" managers who would say "What do you mean by Continuous Integration, Common Code Ownership, Refactoring?  Is this just another case of you trying to impress me with your 'techno-babble'?  If so, I'll just have to add you to my twit-list."  

Surely Glen wasn't playing power-games.  I really think the points he raises are good ones for further discussion.

> -----Original Message-----
> From: Dinwiddie, George [mailto:[email protected]]
> Sent: Thursday, January 09, 2003 3:58 PM
> To: '[email protected]'
> Subject: RE: [xpAdoption] 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/ 



------------------------ 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/