Extreme Programming - Process Completeness across the Agile/Classical Spectrum

Author

Process Completeness across the Agile/Classical Spectrum

Ronald E Jeffries

2004-07-04, 8:56 pm

On Sun, 04 Jul 2004 12:28:33 GMT, "Ron Ruble" <raffles2@att.net>
wrote:

>Point: Completeness
>
>There are things that XP does not address. This can be viewed
>as a feature: you don't pay for what you don't need, or it can
>be viewed as a liability: you need to take practices from other
>methodologies.
>
>Ron Jeffries referred to methodologies that attempt to
>address everything as 'encyclopedic', and stated a preference
>for lighter weight methodologies, as human nature often leads
>people to try to use unneeded features out of a misguided
>sense of economy, rather than discarding them.
>
>Scott stated a preference for encyclopedic methodologies.
>Scott, I don't see a reason given other than a possible
>implication that 'one-stop shopping' is preferable.
>Comments?
>
>Summary: There are two opposite extremes of preference
>when selecting methodologies. Proponents of the first extreme
>prefer an encyclopedic methodology, from which unneeded
>practices can be discarded. Others prefer a light methodology
>to which additional practices can be added if needed, on
>an organizational or personal basis. View one is in line with
>classical BUFP, and view two is consistent with agile
>methodologies.
>
>Personal note: I suspect the perceived value of one versus the
>other is largely driven by the experiences an individual has
>had with prior and current employers and clients.

Doubtless. My experience, long and hard, is that comprehensive methods
like CMM or RUP (both of which are intended by their authors to be
method GENERATORS, not methods) are almost inevitably applied to
heavily.

I am not in the least concerned about adding in a practice from
"another methodology" when it's called for. Setting up the process in
advance of measured need is quite analogous to setting up the design
in advance of need. It's error-prone, overly heavy, and a waste of
resources.

The above is, of course, just an opinion, though it is stated as if it
were a fact. (Of course my opinion is that it is a fact. :) )

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Scott Kinney

2004-07-05, 3:56 pm

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:gt2he0p0gl2mjqsquc5a1ld7kif3991ltg@
4ax.com...[color=darkred]
> On Sun, 04 Jul 2004 12:28:33 GMT, "Ron Ruble" <raffles2@att.net>
> wrote:
>

There are three basic points I'd make here:

1. The key verb phrases in the varying domains of
project management are "Assess", "Determine" and the
like. Rather than walking into the room with 18,000
predefined forms and processes, the real practice
is find out what is needed on a particular project.
By explicity checking each domain, which I refer to
as walking all the way around a project, I'm not
tempted to take very much for granted.

2. All that said, my experience leads me to expect
that certain practices are probably going to be
needed. For example, it's much more reasonable
to assume that communications about and regarding
the project will be needed outside the direct project
team, than it is to assume they won't.

Another example would be risk management.
In agile methodologies, the chief (and usually
only risk) being addressed is the risk of requirements
instability. In fact, it's the only risk discussed in the
book "Agile Project Management". To be sure,
that risk is adequately covered by the structure of
the methodology itself. However, if pressed to
document a risk management strategy it would
be something like "The project will assume all
other risks, and will address them when and if
they arise. Few if any resources will be allocated
to cataloging potential risks, determining strategies,
and monitoring them." That will be appropriate
for some projects, and some customers, but not
all. Actually, in my experience, very, very few.

3. There are lots of kinds of projects, lots of
kinds of customers. I prefer to have a broad
skill set, and the training to address all of those
needs as they turn up. My great fear in agile
methodologies' "We'll do it if we need to." is
that there's no real bench strength or core
competency to back that up. When I read
statements like "Refactoring isn't an expense
because it's easy to do.....", I shudder.

Ron Ruble

2004-07-05, 3:57 pm

"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:d66dncqAwrvv9nTdRVn-hA@comcast.com...
>
<snip>
>
> There are three basic points I'd make here:
>
> 1. The key verb phrases in the varying domains of
> project management are "Assess", "Determine" and the
> like. Rather than walking into the room with 18,000
> predefined forms and processes, the real practice
> is find out what is needed on a particular project.
> By explicity checking each domain, which I refer to
> as walking all the way around a project, I'm not
> tempted to take very much for granted.

Excellent point. At least looking at all potential
areas can help the decision making process.

> 2. All that said, my experience leads me to expect
> that certain practices are probably going to be
> needed. For example, it's much more reasonable
> to assume that communications about and regarding
> the project will be needed outside the direct project
> team, than it is to assume they won't.

Quite reasonable. I'm not sure that there is a
reasonable standard choice for an agile communication
method for groups larger than the team (including
user reps and such), but I can see where this is
a common need.

> Another example would be risk management.
> In agile methodologies, the chief (and usually
> only risk) being addressed is the risk of requirements
> instability. In fact, it's the only risk discussed in the
> book "Agile Project Management". To be sure,
> that risk is adequately covered by the structure of
> the methodology itself. However, if pressed to
> document a risk management strategy it would
> be something like "The project will assume all
> other risks, and will address them when and if
> they arise. Few if any resources will be allocated
> to cataloging potential risks, determining strategies,
> and monitoring them." That will be appropriate
> for some projects, and some customers, but not
> all. Actually, in my experience, very, very few.

Reasonable; but in my experience, dealing with
these kinds of risks is something that always needs
to be customized for the specific organization, so
off the top of my head I can't imagine what a
standard (reasonably agile) method might be.

> 3. There are lots of kinds of projects, lots of
> kinds of customers. I prefer to have a broad
> skill set, and the training to address all of those
> needs as they turn up. My great fear in agile
> methodologies' "We'll do it if we need to." is
> that there's no real bench strength or core
> competency to back that up. When I read
> statements like "Refactoring isn't an expense
> because it's easy to do.....", I shudder.

You make a good point. I think the shudder
about refactoring not being an expense is a bit
misplaced. It's a statement designed to open
up the minds of individuals who fear change
to the extent that they stay in their homes
on the slopes of Vesuvius long after they should.

It's not universal advice, anymore than 'avoid fats
and eat smaller portions' is universal advice. But
when the most common problem you see is obesity
rather than anorexia, an overstatement like that is
understandable, perhaps even inevitable.

Scott Kinney

2004-07-05, 3:57 pm

"Ron Ruble" <raffles2@att.net> wrote in message
news:AxfGc.62545$OB3.56648@bgtnsc05-news.ops.worldnet.att.net...
>
>
> You make a good point. I think the shudder
> about refactoring not being an expense is a bit
> misplaced. It's a statement designed to open
> up the minds of individuals who fear change
> to the extent that they stay in their homes
> on the slopes of Vesuvius long after they should.
>
Sadly, no. I was asking a specific question about
cost benefit calculations at the time, and asked how
the expenses for refactoring were accounted for in
the model.

To be fair, I got 1 workable answer, that it
was included in the overall expenses for coding
(ie, 'coding costs' covered coding, testing and refactoring.)
The other answers included;
It's not an expense because it's easy,
It's not an expense because we'd do it anyway
It's not an expense because it's cheap
It's not an expense at all, it's really a benefit.

But, don't read more into it than necessary. I was
raised by an accountant, have spent a lot of time
in finance, and am easily shocked at people who
don't grasp the most basic concepts of income and
expense....It's a personal failing, I'm sure.

Ronald E Jeffries

2004-07-06, 3:56 am

On Mon, 5 Jul 2004 10:53:37 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>3. There are lots of kinds of projects, lots of
>kinds of customers. I prefer to have a broad
>skill set, and the training to address all of those
>needs as they turn up. My great fear in agile
>methodologies' "We'll do it if we need to." is
>that there's no real bench strength or core
>competency to back that up. When I read
>statements like "Refactoring isn't an expense
>because it's easy to do.....", I shudder.

Here is an example of Classical Done Well versus Agile Done Poorly.

No one in the agile community is saying that great and broad skills
are not required. We are saying that by putting the team together and
focusing on delivery of software, the additional practicesneeding to
be applied will become clear to sufficiently skilled team members.
That being true, those practices need not be checked off from your
list at the beginning of the project, they can be put in place as and
when needed.

I do not recognize the quotation about refactoring. I would argue that
refactoring is not a NET expense, but not that it's easy to do. But I
suspect that the statement was not something offered for discussion,
merely as a rhetorical device. If I'm mistaken, please start a new
thread.

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Scott Kinney

2004-07-06, 4:06 pm

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:b71ke0dc9lac9fdqtp1lvti64ufduala4q@
4ax.com...
> Refactoring, done well, is such an example. A good developer switches
> between refactoring and, well, not refactoring, several times an hour,
> often for just a few seconds at a time. Now, difficulty of measurement
> might not be an excuse not to measure, but it's worth considering.
>
> I would suggest that the question about the "expense" of refactoring
> is itself assuming something about refactoring which might not be
> true. Do we ask about the expense of coding, or the expense of design,
> or the expense of typing the character "{"? I suppose someone raised
> by accountants might, but I think there are larger questions to
> consider.
>

Well, you would ask about those expenses if you intended to
measure the return on investment for a project. You need to measure
the expenses in the present, and compare them with direct returns collected
after completion. You would measure those if you wished to
substantiate a claim of greater return on investment, or lower
cost to deliver a project, for example.

> To address the /impact/ of refactoring, we need to recognize that it
> is more like a capital investment than an expense. Refactoring has as
> its purpose to improve the software in such a way as to make software
> development less costly. So we need to assess it as an investment, not
> as an expense.

Agreed. Money spent now on refactoring will show up later as
reduced development costs on a future project or the next
enhancement to the same application. Again, if you want to
substantiate a claim that refactoring works to reduce software
development costs, you'll have to measure and compare.
It may not be easy to do, that is understood.

> The best way that I know is to pay attention. Some folks might like to
> keep notes on larger refactorings, but since I favor very small ones,
> note taking on those would take longer than the work.
>
> Netting it all out (trying to speak your accounting language there),
> you've asked a good question, but one that is not easy to answer, and
> one that, in my opinion, needs to be answered by the people developing
> the software. We could talk about some ways to do that if it seems
> interesting.

Scott Kinney

2004-07-06, 4:06 pm

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:nu0ke0left95sgibac1nivg1c4b5u62r99@
4ax.com...
> On Mon, 5 Jul 2004 10:53:37 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Here is an example of Classical Done Well versus Agile Done Poorly.
>
> No one in the agile community is saying that great and broad skills
> are not required. We are saying that by putting the team together and
> focusing on delivery of software, the additional practicesneeding to
> be applied will become clear to sufficiently skilled team members.
> That being true, those practices need not be checked off from your
> list at the beginning of the project, they can be put in place as and
> when needed.
>
It would help me understand this better if you'd give an example.
The phrase 'will become clear' strikes me as waiting until, for example,
the customer says, "Hey, I thought you guys were going to be tracking
the time and expense for this project." What happens, how do you get
missing expertise onto the team, etc.?

My bias is that the simplest way to discover if some practice is needed
is to ask.

Ronald E Jeffries

2004-07-06, 4:06 pm

On Tue, 6 Jul 2004 10:51:26 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>
>Well, you would ask about those expenses if you intended to
>measure the return on investment for a project. You need to measure
>the expenses in the present, and compare them with direct returns collected
>after completion. You would measure those if you wished to
>substantiate a claim of greater return on investment, or lower
>cost to deliver a project, for example.

You /might/ do that. You might just measure the overall performance of
the team and compare to past performance. There is always a level of
detail in accounting beneath which one does not go. Since all of
programming, testing, refactoring, and so on are on the expense side
of the ledger, it might not be worthwhile to try to break them out,
especially since individual team differences probably swamp the
detailed figures anyway.

Of course I'd love to have those numbers. I just don't see how to get
them at a reasonable price. I hope someone more creative than I am
accomplishes it.
>
>
>Agreed. Money spent now on refactoring will show up later as
>reduced development costs on a future project or the next
>enhancement to the same application. Again, if you want to
>substantiate a claim that refactoring works to reduce software
>development costs, you'll have to measure and compare.
>It may not be easy to do, that is understood.

I don't feel the need, personally, to produce numbers to substantiate
this observation. Since I develop software all the time, and since I
have sometimes refactored extensively and sometimes not, even on the
same project, the impact is quite clear to me.

I'd love for the numbers to exist, because then we could get to the
real objection behind "show me the numbers". But for my work, I don't
need "no stinkin' numbers".

Some people use anecdotal reports to decide what to try next, to learn
for themselves. Some prefer to wait for hard numbers. Either strategy
is fine by me; my own strategy is to try things that people report as
interesting, and draw my own conclusions.

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Ronald E Jeffries

2004-07-06, 4:06 pm

On Tue, 6 Jul 2004 10:57:40 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>It would help me understand this better if you'd give an example.
>The phrase 'will become clear' strikes me as waiting until, for example,
>the customer says, "Hey, I thought you guys were going to be tracking
>the time and expense for this project." What happens, how do you get
>missing expertise onto the team, etc.?
>
>My bias is that the simplest way to discover if some practice is needed
>is to ask.

I'm all for asking. Although I'd think that if someone wanted to track
time and expense, they would say so. If number of programmers times
number of days was somehow inadequate ...

Here's an example. We have unit tests, customer tests, and releases to
end users. The end users find a problem. We write the customer test
that shows the problem; we write the unit tests that show the problem;
we fix the problem.

Then we think. We think, Hmm, we haven't ever written a test before
that works that way. Let's start doing that.

Or perhaps we can't write an appropriate test -- maybe it's a timing
bug and very hard to test. So we think. We think, Hmm, there are
potential timing bugs in the system. This one was caused by to
separate pieces of code accessing the same shared object, a MegaProng,
without going through a semaphore. Then we added semaphore code to
each location. Hmm, that's duplication. We need an object to handle
that. Let's build a SharedMegaProng class and use it everywhere.

Or perhaps we notice that the same questions keep coming up from some
stakeholder, so we figure out that they can't come into our space, so
we push some of our charts to a web site, or maybe even print them and
send them to the stakeholder, or maybe we even schedule a bi-w

ly
meeting with the stakeholder.

It's certainly OK to ask whether we need X, at any point in the
project. It's just not quite OK, in my opinion, to answer "yes"
without a demonstrated need.

Does that help?

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Sponsored Links