RE: Managing Extreme Programming

George,

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

[>] The traditional EV S-curve is viewed as an analog (continuous)
accumulation of value as a function of time. XP projects provide a means
of "digitizing" this in the form of fine grained iterations. Emerging in
the EV world is the concept of "testable requirements." This could be
considered identical to UT's or FT's. Like these, TR's are booked at 0%
or 100%. By increasing the granularity "digital" versus "analog"
measures can be created - thus merging EV with Agile.

The business and PM folks I support have no clue about the terms used in
XP. They live and breathe EV. For adoption to take place we have to (and
have) moved to their vocabulary NOT had them understand the vocabulary
of XP. At least that's how we've made progress.

> > (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.

[>] reduce the "progress to plan" measurements to a daily or 3 day
level. A typical "big" project might run for 3 years and be 10's of
millions in software alone. In the past this was managed using EV on
large grained boundaries (say 3 to 5 month milestones). We're reducing
these to 3 day milestones with "testable requirements," as the exit
criteria for the milestone, that when it passes accrues the "earned
value" - BCWP booked as value.

> > (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.

[>] Yep and that the "gap" for XP, since velocity describes a "level of
effort" (in terms of EV) in which effort expended is the same as
"value." 

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

[>] Maybe, we're still working out the description details for a DOE CIO
conference paper and then a "handbook" for the SLC Agile Conference. But
we'll need lots of feedback from others so when this comes together in
the next two weeks, I ask for reviews. But in the end the EV method has
three metrics (estimated cost, actual cost, the cost of the value). From
those schedule and cost variances are directly computed for the period
and for the cumulative project. From there estimates at completion are
derived using a variety of statistical methods depending on the needs of
the PM and the context of the project.

Here's some "light reading" ;>)
http://www.niwotridge.com/Resources/DomainLinks/EarnedValue.htm

> > (4) How to use "yesterday's weather" to forecast the Estimate
> > at Completion.
> 
> Estimate of what?

[>] Cost and schedule. EV has a formal definition of EAC, see the
materials above.

> > (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?

[>] Dollars for both cost and schedule. We use the terms $X.00 ahead or
behind of schedule.

> > (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.

[>] See links above.

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

[>] In the majority of our work (to date) the customer is in the form of
a three ring binder, called the Functional Specification.

> > (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.

[>] Except this calculation I a level of effort and does not describe
the "value" in dollars of the delivered code. It described the dollars
spent but not the dollarized value delivered. Again see some of the
intro materials in the link above.

> > (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.

[>] Traditional = CMM level 3 waterfall-like == spiral, cascading
iterations on large grain boundaries, methods used today to deliver 10's
of millions of dollars of software on a single project.

> > (8) How to define these interfaces so that both sides concur
> > they understand the vocabulary, outcomes, and constraints.
> 
> What interfaces are "these?"

[>] Between the "room" developers, "rooms" of developers, "buildings" of
developers, "campus'" of developer, "states" of developers. Half or
projects are joint ventures with subcontractors, COTS suppliers and
other partner firms. Software in a room has great merit - but we have
multiple rooms.

> > (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.

[>] XP has trackers that look at the next iterations production
estimate. EV has a PMO (me office) that looks at the EAC. BOTH are
needed. BOTH are invaluable to the "customer."

> > (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.

[>] See above...

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

[>]George I take this as a request for learning. I have no interest in
dazzling you. I have great interest in advancing the EV based processes
using agile development methods

I'm here
> for communication, not for playing power games.

[>] In what way George is discussing the domain aerospace and government
contracting a "power game?" Is this not the forum to discussion the
adoption of XP and new and valuable environments?

The terms may be new, but catch up with the bulk of the PM's on the
planet who work in these domains. Expand your mind a bit, it'll pay off
in the end I'm sure ;>)

>  - George 

[>] Glen


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