Extreme Programming - Charts and Progress across the Agile/Classical Spectrum

Author

Charts and Progress 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: Charts and progress reports
>
>Both Agile and Classical methodologies generate
>reports and use charts to track progress. One key
>difference, IMHO, is that Agile methodologies track
>progress with an eye toward finding areas where the
>-plan- deviates from reality, while in Classical
>methodologies, as applied in most organizations,
>these reports and charts are used to track areas
>where -developers- deviate from the plan, and the
>plan is assumed to be reflective of reality.

A bit cynical, but I tend to agree. There are organizations where the
plan is assumed to be correct and deviations from it are assumed to be
mistakes. There are organizations where the plan is understood to be
an estimate, and where deviations are looked at to see what they mean.
The latter is more healthy.
>
>As Scott Kinney pointed out, there is no reason we
>can't use these same metrics in Classical methodologies
>to find defects in the plan. It just isn't done that way
>in most organizations.

This is not quite the case. If a methodology doesn't ship running
tested software from the very beginning, that metric can't be used to
find defects in the plan. The plan calls for zero software for the
first third of the project, and we inevitably accomplish that. Then
the plan would call for software to be written, which we could track,
but it wouldn't be tested. Finally we'd get to testing.

Incremental development enables a kind of metric that's not available
at all in a more waterfallish situation.
>
>Summary: It is imperative to validate the plan objectively
>as we progress, regardless or how the plan was created
>or the 'weight' of the plan.

Agreed. I look forward to hearing from others.

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

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

Charts and progress reports are communication tools.

They are used to describe, inform and influence. They are
objects, and cannot validate or invalidate a damn thing.

I've written before that in communication planning, I assess
what information the stakeholders, participants and management
want, in what form, on what schedule, and then build the practice
to develop and deliver them as part of the project's work.

Generally, when management has a number of projects
running at the same time, they require that progress reports
assume a common form, and allow progress to be compared
across projects. What do they get out of that? Answers to
questions like: when will that product go to market? how many
new releases are we putting into our office environment in a
given month? is this or that department overloaded? If this
project continues ahead of plan, will it screw up another project?
Will we have the right resources available at the right time?

That said, I have my own preferences for progress reports
and charts, many of them influenced by my admiration for
Edward Tufte and his work.

I like charts that:
*contain a lot of information in the same picture
*are measured in commonly understood units (like time)
*can be read and understood by interested parties without
too much extraneous effort
*show where we were, where we're going and where we are
now
*show what we thought would happen and what did happen
*that measure deliverables instead of processes

Ron Ruble

2004-07-06, 8:57 pm

"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:qv2dnccgF4Bhf3fdRVn-ig@comcast.com...
>
> Charts and progress reports are communication tools.
>
> They are used to describe, inform and influence. They are
> objects, and cannot validate or invalidate a damn thing.

I get the impression you believe I disagree with you on
this; I don't. I simply stated that some reports contain
relatively absolute measures, and others contain data
that has been calculated from other measures, often
with an eye toward measuing against an objective.

Either one can be deceptive, but I feel the simpler
metrics are generally better at communicating actual
progress, and where improvements need to be
made.

> I've written before that in communication planning, I assess
> what information the stakeholders, participants and management
> want, in what form, on what schedule, and then build the practice
> to develop and deliver them as part of the project's work.

Which is fine.

> Generally, when management has a number of projects
> running at the same time, they require that progress reports
> assume a common form, and allow progress to be compared
> across projects. What do they get out of that? Answers to
> questions like: when will that product go to market? how many
> new releases are we putting into our office environment in a
> given month? is this or that department overloaded? If this
> project continues ahead of plan, will it screw up another project?
> Will we have the right resources available at the right time?

Which is fine, but not a one-for-one replacement for
the agile alternative. It's not that the other is better or
worse, but that they are different, and some organizations
(possibly the majority) require more objective data on
actual progress.

> That said, I have my own preferences for progress reports
> and charts, many of them influenced by my admiration for
> Edward Tufte and his work.
>
> I like charts that:
> *contain a lot of information in the same picture
> *are measured in commonly understood units (like time)
> *can be read and understood by interested parties without
> too much extraneous effort
> *show where we were, where we're going and where we are
> now
> *show what we thought would happen and what did happen
> *that measure deliverables instead of processes

All of which are fine; I am not denying the value
of such things. I am simply stating that your mileage
may vary, and that the two approaches have
different value.

As many people have pointed out, Scott, it sounds
like your organization has a remarkably good handing
on their projects. If I were you, I would not be
anxious to change a thing.

Others are getting different results. That's all. Part
of the reason I posted the thread that started this
is to try to understand better why some people are
doing classical development so poorly that agility
seems to them to be a revelation, and why others
are doing it so well that agility seems to them like
an unbalanced rejection of years of software
process knowledge.

To draw a picture, we say your mileage may vary;
I'm just curious about what differences in driving
habits may cause mileage to vary so much.

Scott Kinney

2004-07-06, 8:57 pm

"Ron Ruble" <raffles2@att.net> wrote in message
news:tiEGc.66733$OB3.26319@bgtnsc05-news.ops.worldnet.att.net...
>
>
> I get the impression you believe I disagree with you on
> this; I don't. I simply stated that some reports contain
> relatively absolute measures, and others contain data
> that has been calculated from other measures, often
> with an eye toward measuing against an objective.
>
> Either one can be deceptive, but I feel the simpler
> metrics are generally better at communicating actual
> progress, and where improvements need to be
> made.
>
Frankly, I'm so baffled that I don't know if you're
agreeing with me or not. I think we're talking about
two entirely different things.

First off, I'm drawing a distinction between plans (and
the content of plans) and the creation/publication
of reports to communicate information about the project.
I'll be writing about planning in more detail shortly.

That said, I'm having with certain concepts and language
being said. If you would, please help me out a little.
For example:
there are value-laden phrases like
"track where developers deviate from the plan"
"plan is assumed to be reflective of reality"
"plan deviates from reality"
"identifying and correcting defects in the plan"
"validating the plan"

I don't talk about plans in these terms, so I'm having
trouble relating.

I'm also unclear on what you consider an objective measure,
a subjective measure, and so on.

One other thing that puzzles me is the intense resistance
to publishing estimated vs. actual data. (I am developing
a working theory, though.)

>
> Which is fine, but not a one-for-one replacement for
> the agile alternative. It's not that the other is better or
> worse, but that they are different, and some organizations
> (possibly the majority) require more objective data on
> actual progress.

Is there an agile approach to comparing projects?
And again, give an example of what you mean by
objective data.

>
>
> Others are getting different results. That's all. Part
> of the reason I posted the thread that started this
> is to try to understand better why some people are
> doing classical development so poorly that agility
> seems to them to be a revelation, and why others
> are doing it so well that agility seems to them like
> an unbalanced rejection of years of software
> process knowledge.
>
Part of the reason that I'm spouting off about
the classical project management approaches is that
I've become convinced that many of the people
on the NG don't seem to recognize that it's bad performance
they're seeing, not a bad methodology.

> To draw a picture, we say your mileage may vary;
> I'm just curious about what differences in driving
> habits may cause mileage to vary so much.

Isaac Gouy

2004-07-07, 3:57 am

"Ron Ruble" <raffles2@att.net> wrote in message news:<tiEGc.66733$OB3.26319@bgtnsc05-news.ops.worldnet.att.net>...

-snip-
> Others are getting different results. That's all. Part
> of the reason I posted the thread that started this
> is to try to understand better why some people are
> doing classical development so poorly that agility
> seems to them to be a revelation, and why others
> are doing it so well that agility seems to them like
> an unbalanced rejection of years of software
> process knowledge.

And why some consider formal-methods and static-analysis basic tools of the trade.
http://www.mail-archive.com/sc-l@se...g/msg00331.html

Are they just smarter? More professional? Working in a different domain?

Ilja Preuß

2004-07-07, 3:57 am

Isaac Gouy wrote:

Well, there is no doubt that having seen classical development done poorly
helps in accepting to try new ways.
[color=darkred]

Perhaps - and only perhaps - it's less because they do classical development
so well (though it's probably part of the equation), but more because they
never have seen Agile development done well?
[color=darkred]
> And why some consider formal-methods and static-analysis basic tools
> of the trade.
> http://www.mail-archive.com/sc-l@se...g/msg00331.html
>
> Are they just smarter? More professional? Working in a different
> domain?

Interesting bias, again.

Cheers, Ilja

Ron Ruble

2004-07-07, 3:57 am

"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:ob-dnY0c6rWavXbdRVn-hQ@comcast.com...
>
> "Ron Ruble" <raffles2@att.net> wrote in message
> news:tiEGc.66733$OB3.26319@bgtnsc05-news.ops.worldnet.att.net...
<snip>
> Frankly, I'm so baffled that I don't know if you're
> agreeing with me or not. I think we're talking about
> two entirely different things.
>
> First off, I'm drawing a distinction between plans (and
> the content of plans) and the creation/publication
> of reports to communicate information about the project.
> I'll be writing about planning in more detail shortly.
>
> That said, I'm having with certain concepts and language
> being said. If you would, please help me out a little.

Point by point:

> For example:
> there are value-laden phrases like
> "track where developers deviate from the plan"

See which coders screwed up and how.
In many organizations, the assumption is
that if we are not achieving the results the
project plan calls for (most often speed),
then the coders screwed up.

> "plan is assumed to be reflective of reality"

Managers assume that if the plan calls for
module ABC to be completed in 5 days, then
if module ABC is not completed for 25 days,
then the coder had to screw up badly.
Reviewing the technical difficulties and
considering the possibility that the 5 day
estimate was based on extremely optimistic
projections is never considered.*

This is also true of other measures than time;
data throughput, response times, size of
data sets, anything.

The plan is assumed to have been realistic,
even when objective measures (time, etc)
open up the possibility that elements of the
plan were unrealistic, and should be re-evaluated.

> "plan deviates from reality"

Plan says we will do something that we later
determine can not work. Using a database that
can't handle the amount of data we need to store,
or use new vendor feature XYZ, which we find
is far too buggy to use, etc.

> "identifying and correcting defects in the plan"

Finding the same, revising to bring the plan in
line with reality. Often when the plan is revised,
Managers are trying to preserve the work that's
already been done. Rather than replacing DEF
company's crappy database with Oracle,
management tries to replace ith with GHI
company's database, which boasts DEF
compatibility (and still sucks, just a little less).

Patch the plan rather than redo the plan.

It's not always software. Sometimes we discover
that a upgrade of 10,000 user machines scheduled
for 2 months before release is going to be postponed
for a year, and we have to change the architecture
to handle the older hardware.

It's not that someone screwed up the plan, although
that happens. It's that the constraints in the plan just
don't reflect the real-world constraints; the assumptions
in the plan aren't valid.

> "validating the plan"

We know that 80% of the defects in software
are in 20% of the code. This is true for project
plans and application designs as well. If you find
a few defects in the plan or the design, my
assumption is that there are more defects waiting,
and we should reexamine the rest of the plan
for defects. Managers revising project plans
typically asssume after each defect is corrected
that "we got all the defects out of the plan; now
we can catch up." This is usually untrue, in my
experience.

> I don't talk about plans in these terms, so I'm having
> trouble relating.
>
> I'm also unclear on what you consider an objective measure,
> a subjective measure, and so on.

An objective measure would be "this w

there
were 53 defects. 27 of them were in module ABC.
Module ABC has 42 functions this w

, and
had 36 last w

. 64 lines of code in ABC were
changed this w

for a total of 2185 lines. Last
w

55 were changed, and the toal was 2376."

This is what I would consider an objective measure
of the quality and completeness of module ABC.
If we track this w

ly, for all modules, we have
a largely objective measure of the completeness
and quality of the code in each module.

Typically, module completeness is measured by the
PM walking over to the desk of the coder working
on ABC and having this conversation:

PM: "Last w

you said you were 60% done
with module ABC, how about this w

?"
C: "70%"
PM: "Is that 70% tested?
C: "Yes
PM: "OK" **

For defects in the plan, I would measure velocity of
results (how many features complete, how long, and
what did we estimate). How many stories/requirements
needed to be changed or revisited for clarification?
How many delivered features in an interim release
were subsequently found to be unacceptable by
the customer?

Typically, velocity is tracked in conversations similar
to the above, and requirements defects are dealt with
in negotiations which muddy up the waters. Customers
try to treat these as errors by development staff, and
the PM or his boss tries to classify them as "change
requests." Without all features in an interim release
being complete [some usually put up a message box
or do nothing], flaws in defining the features aren't
found early.

When we are not achieving the velocity the plan
expects, the first reaction of most PMs is add
more overtime, which usually doesn't correct the
problem. Also, in most organizations, when
corrections like "more overtime" are made, the
PM throws out the objective measures of velocity.
The assumption is that we will catch up; we're
working overtime, aren't we? If you just continue
to track the velocity objectively, you can see day
if we are getting back on track or not.

If we are running 10% over schedule, the PM recalculates
based on 10% more hours, and we're back on track.
The assumption is that the one balances the other.

10% late is not an even trade for 10% more
hours per coder. That's one of the thinngs I mean
by subjective.

If you continue to track the velocity, you see
very quickly if we are making up for lost time
or not.

The typical PM has a mandate to deliver on time,
and hasn't got the discretion to reduce the feature
set. He tries juggling the numbers till he gets the
result he needs, and doesn't see why this isn't
valid.

With the measures I recommended for defects per
module and rework of features/stories (just a couple
of examples), we can see potential defects in the design
and the plan more clearly. Maybe module ABC, above,
has so many defects because what the module is supposed
to do wasn't thought through as well as expected. Maybe
code from another project that went into that module
isn't as solid as everyone assumed ***. These measures
help identify that.

The key thing, in my mind, is that -if- the organization
often has flaws in the project plan (and many do),
simple measures can tell us quickly if something is
wrong. Then we can stop and correct.

> One other thing that puzzles me is the intense resistance
> to publishing estimated vs. actual data. (I am developing
> a working theory, though.)

I personally have no objection to doing so, and I
don't think other respondents are resisting the idea
of publishing estimated vs actual. I think the resistance
is to the idea that it is, and always must be, absolutely
necessary to publish that data.

In "PeopleWare", Tom DeMarco refers to a study
by Michael Lawrence and Ross Jefferey, measuring
productivity across different projects, broken down
by who did the estimate. "Projects on which the boss
applied no schedule pressure whatsoever ('Just wake
me when you're done.') had the highest productivity
of all."

DeMarco doesn't claim this definitively proves that
working without estimates gets the best results, but
the possibility exists. If some organizations are willing
to work without schedules, why not? -I'm- certainly
not willing to tell them they have to make an estimate.

I can certainly appreciate that many customers
really want that information. I just don't buy the
argument it is lazy or unprofessional or irresponsible
to -not- publish that information, if the customer
doesn't mind.

>
> Is there an agile approach to comparing projects?
> And again, give an example of what you mean by
> objective data.

You took me out of context there, but I was
responding to this line in your post:

SK> I've written before that in communication planning, I assess
SK> what information the stakeholders, participants and management
SK> want, in what form, on what schedule, and then build the practice
SK> to develop and deliver them as part of the project's work.

My reply was not to indicate that there is an
agile way to compare projects. I was just suggesting
that giving management the reports they -want- doesn't
guarantee that the information they (and the developers)
-need- in order to objectively measure progress is going
to be in the report. I have experienced many cases where
the reports management wants are very nice, but
basically content-free, and useless for planning.

My take is that management can have any report
they want; but I know what -I- want to see reported,
and if management doesn't want that information,
I'm still going to track it. Preferably on a 'big
visible chart' ;>

> Part of the reason that I'm spouting off about
> the classical project management approaches is that
> I've become convinced that many of the people
> on the NG don't seem to recognize that it's bad performance
> they're seeing, not a bad methodology.

I have to disagree. I think most people here agree
that it -is- bad performance. However, that doesn't
necessarily invalidate the agile alternative. It may
not be strictly -necessary- to replace the methodology,
but it does not follow that it is therefore undesirable
to do so, if the methodology is being used badly.

Fixing what you have is certainly an option; but
scrapping it might be as well.

You seem to be interested in comparing ideal
'Classical' software project management against
ideal Agile development. I'm not really interested
in that myself. I'm more interested in comparisons
of one versus the other in the same organization/
same teams or comparisons of average results
of each across different organizations.

-------------------------------------------------

* I have often given estimates for tasks of 3 w

s,
only to have the PM put it on the plan as 3 days
when 3 w

s made it difficult to schedule delivery
when the client wanted it. I have also had the PM
then ask me "why is this task late" when I deliver
in slightly over -2- w

s.

** 3 projects and 3 different PMs in the last few years,
almost the identical words each time.

*** Just had a project last year suffering from that.
The assumption made in the plan was that we could
reuse code from a module without rework. Turns out
that the module had -many- defects that had slipped
through QA, and the application had new requirements
none of the other apps had, which found -lots- of
them. At a cost of many hundreds of man-hours to
fix.

Scott Kinney

2004-07-07, 8:57 am

"Ron Ruble" <raffles2@att.net> wrote in message
news:tiEGc.66733$OB3.26319@bgtnsc05-news.ops.worldnet.att.net...
>
> understand better why some people are
> doing classical development so poorly that agility
> seems to them to be a revelation,

Based on what I've seen, and discussed with others
equally puzzled, here are some thoughts:

* Lack of mastery - many of the techniques of classical
project management are hard. In addition to instruction
they require practice to develop confidence and proficiency.
(Practice is different than performance. Practice is basically
drill repetition across a continuum of complexity, with analysis
and correction. Performance is actually doing the thing for
real under uncontrolled circumstances.)

Example 1: Requirements gathering done well separates
"what" from "how". It takes a certain amount of practice
to do that well. I still see people get themselves wrapped
around an axle working with requirements that are a jumble
of "what" and "how". An Air Force project manager I know of
has a really

checklist for separating the two in written
requirements. But, of course, people would actually have to
use it....

Example 2 (not a software example): Dynamic entry for
SWAT teams is difficult problem. You want to get 8 or 9
heavily armed guys through a standard size doorway in
under 2 seconds. In bad conditions, and without getting
shot to pieces. If they trained the way many project
managers were trained; they'd be given some textbook
references, some stand-up instruction and then be handed
a stack of high-risk warrants to serve.

Instead, they strip it down to utter basics; 8 or 9 guys and
a doorway. They figure out where to stand, how fast to move,
how to coordinate with the other guys. Then they just pretend to
have guns, then they have guns with simulated ammunition, then
they screw around with lighting, smoke and noise, then they
might have someone shooting back, then they might go practice
in real buildings, and so on.

I've been very fortunate to have had training that included
drills, practice projects, simulations, supervised internships and
the like.

* Lack of leadership qualities - this is kind of fuzzy
(and I keep working at it.) I run across a number of
classical project managers who lack a sense of ownership,
responsibility, who don't provide a compelling vision
of their project. They sort of act like project bookkeepers
rather than project leaders. I was in my manager's office
one day for some reason or other when a vice president
stopped in, ignored me and said to my manager, "you know
I don't like the way so-and-so presents himself, you need
to address that." My manager looked at him, paused, and
said, "That's nice. He works for me, not you. You've got nothing
to say about it." That's an attitude I've worked to emulate
for the project teams I work with.

* Lack of a certain intellectual curiosity/aggressiveness -
If software is thought to be plastic, malleable and
changeable, ideas are even more so. I don't see many
managers who will play with a bunch of different strategies
with their teams before finding the one that suits them.

> and why others
> are doing it so well that agility seems to them like
> an unbalanced rejection of years of software
> process knowledge.
>

Again, just a couple of observations:

1. For whatever reason agile methods and techniques often come
wrapped in a thick blanket of anti-classical rhetoric. Recently,
I read a 4 page article on agile project tracking. 2 of the pages were
about how crappy classical approaches are. OK, I've dealt with
blowhards and demagogues before, and winnowed out the useful
bits, maybe I can deal. But then, you'll have statements that just seem
so mis-informed (one of my favorites is "planning stems from a
desire to control") that you wonder how solid the proposed alternative
really is. [This is just a suggestion; if people have experienced some
success with a methodology, it's easier to motivate them to try
something new by offering to make them more successful, than
it is to suggest that they've never really been successful in the past.]

2. There's a lot of puzzlement about why people will do
amounts and kinds of work under agile methodologies
that they didn't do under a classical methodology. In
another thread, someone wrote about the amount of
personal discipline required in XP. They said something
like; "In XP I write code every day, I test the code
everyday, I work on design every day. Every day
I talk to my co-workers and share ideas. Every day!
What other methodology would let me do that?"
Well, any of them, really. Those behaviors are always
available. Don't get me wrong, if XP gave you some kind
of context or feeling that made that level of personal
practice possible, then good on you, mate. At the same
time, it's reasonable that outsiders might scratch their heads
and ask, "Testing code? You mean you didn't before?
Regular, frequent releases of working
code? Couldn't you have been doing that anyway?"

3. Not to beat a dead horse, but I still think that each methodology
has a 'home ground' or types of projects it's particularly good at.
In my opinion, there are environments, and projects that are better
served by classical methodologies, and vice versa.

4. Synthesis of agile and classical techniques is still in an
experimental stage. Give it time.

Ron (Ruble),
This is a little on the side of this topic. Thank you for taking the time
to summarize points made in other threads, and having the patience
to read through all the different viewpoints.

I learned a lot through this set of threads that helped me understand
why some of the agile practices (and XP practices) are what they are.

Thanks.

Ronald E Jeffries

2004-07-07, 8:57 am

On Wed, 7 Jul 2004 07:57:22 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>2. There's a lot of puzzlement about why people will do
>amounts and kinds of work under agile methodologies
>that they didn't do under a classical methodology. In
>another thread, someone wrote about the amount of
>personal discipline required in XP. They said something
>like; "In XP I write code every day, I test the code
>everyday, I work on design every day. Every day
>I talk to my co-workers and share ideas. Every day!
>What other methodology would let me do that?"
>Well, any of them, really. Those behaviors are always
>available. Don't get me wrong, if XP gave you some kind
>of context or feeling that made that level of personal
>practice possible, then good on you, mate. At the same
>time, it's reasonable that outsiders might scratch their heads
>and ask, "Testing code? You mean you didn't before?
>Regular, frequent releases of working
>code? Couldn't you have been doing that anyway?"

Scott, I'm enjoying the post from which the above is snipped, and
finding it to be quite good. But on this one, not only "no" but "hell
no". On a classical project, you /couldn't/ have been doing that
anyway.

All too often -- and I believe in their fundamental orientation --
classical methods are not about people in a room, they are about
people with separate assignments. They are not about integrated
software, they are about phased analysis design code integrate test.

On a waterfall-style project, you can't write code on the first day,
or even 1/3 of the way through the project. And you can't write code
during the testing phase -- your code is frozen. And while you could,
perhaps, talk to other people, there's no incentive to, since your
assignments and theirs are unrelated, and won't be integrated for
w

s or months to come.

Now again ... it seems to me that your notion of what "classical
methods" are, and my notion and that of your other interlocutors here,
might be quite different. All I know for sure, though, is that XP is
very different from most managed processes that I have seen in over 40
years of software development. Not very different from all processes,
but very different from all /managed/ processes.

What say you?

--
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-07, 3:59 pm

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:7rpne0l5bdo0vnpgprviehe2r8t4k05ao1@
4ax.com...
> On Wed, 7 Jul 2004 07:57:22 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Scott, I'm enjoying the post from which the above is snipped, and
> finding it to be quite good. But on this one, not only "no" but "hell
> no". On a classical project, you /couldn't/ have been doing that
> anyway.
>

First of all, the point is *how the practices look from the
outside*. So, your 'hell no' either means it doesn't look that
way, or that's not really how it is. I think you mean that's not
really how it is.

I will stick to my statement on how it looks from the outside, though.

> All too often -- and I believe in their fundamental orientation --
> classical methods are not about people in a room, they are about
> people with separate assignments. They are not about integrated
> software, they are about phased analysis design code integrate test.
>
If you were to adopt the Personal Software Process, for example,
you'd have a set of personal disciplines and practices that can be
employed within any project management methodology, or
software development methodology. Without making light of
the amount of work required, it really boils down to personal
responsibility for ones' conduct.

> On a waterfall-style project, you can't write code on the first day,
> or even 1/3 of the way through the project. And you can't write code
> during the testing phase -- your code is frozen. And while you could,
> perhaps, talk to other people, there's no incentive to, since your
> assignments and theirs are unrelated, and won't be integrated for
> w

s or months to come.

Well, you and I disagree on the value of writing code before
understanding the objectives and strategy, that's for sure. Developers
on my teams work alongside everyone else to make sure that
we all understand the business objective, how it will be measured,
the specific functional requirements, and how they will be verified. I
expect
them to take a more active role in selecting the strategy (or design) out
of alternatives that promises to be most effective, and certainly they're
directly responsible for implementing the software part of that strategy.
I'd be pretty surprised if they didn't test their own work, and I'd be
unhappy if they spoiled the validity of an independent test by playing
with the code during testing.(unless they're asked, of course)

They're not off in a soundproof booth somewhere waiting to be
called out to write code. This is a project team were talking about,
and I want everyone to be working toward the same objective. If
a developer sits there and says;
"I don't want to talk about requirements, I want to write code,
I don't want to talk about design, I want to write code,"
and so on, then they are the ones who refuse to integrate, who've
kept their work unrelated to others' work.

Scott Kinney

2004-07-07, 3:59 pm

checklist for separating the two in written
> requirements. But, of course, people would actually have to
> use it....
>
> Example 2 (not a software example): Dynamic entry for
> SWAT teams is difficult problem. You want to get 8 or 9
> heavily armed guys through a standard size doorway in
> under 2 seconds. In bad conditions, and without getting
> shot to pieces. If they trained the way many project
> managers were trained; they'd be given some textbook
> references, some stand-up instruction and then be handed
> a stack of high-risk warrants to serve.
>
> Instead, they strip it down to utter basics; 8 or 9 guys and
> a doorway. They figure out where to stand, how fast to move,
> how to coordinate with the other guys. Then they just pretend to
> have guns, then they have guns with simulated ammunition, then
> they screw around with lighting, smoke and noise, then they
> might have someone shooting back, then they might go practice
> in real buildings, and so on.
>
> I've been very fortunate to have had training that included
> drills, practice projects, simulations, supervised internships and
> the like.
>
> * Lack of leadership qualities - this is kind of fuzzy
> (and I keep working at it.) I run across a number of
> classical project managers who lack a sense of ownership,
> responsibility, who don't provide a compelling vision
> of their project. They sort of act like project bookkeepers
> rather than project leaders. I was in my manager's office
> one day for some reason or other when a vice president
> stopped in, ignored me and said to my manager, "you know
> I don't like the way so-and-so presents himself, you need
> to address that." My manager looked at him, paused, and
> said, "That's nice. He works for me, not you. You've got nothing
> to say about it." That's an attitude I've worked to emulate
> for the project teams I work with.
>
> * Lack of a certain intellectual curiosity/aggressiveness -
> If software is thought to be plastic, malleable and
> changeable, ideas are even more so. I don't see many
> managers who will play with a bunch of different strategies
> with their teams before finding the one that suits them.
>
A question from Ron R. reminded me of another point:

* Being too fancy for their own good. Basically what I mean
is getting sooo sophisticated that you forget the basics. A quote
I jotted down the other day says "An expert is someone who does
the basics better than anyone else." [Note, this may not be limited
to classical methodologies.]

Isaac Gouy

2004-07-07, 3:59 pm

"Ilja Preuß" <it@iljapreuss.de> wrote in message news:<40eb9cb3$1@news.totallyobjects.com>...

> Isaac Gouy wrote:
Ron Ruble wrote the first 2 quoted paragraphs.

>
> Well, there is no doubt that having seen classical development done poorly
> helps in accepting to try new ways.

In that situation "classical development done well" would be a new way
;-)

(It's just the 'if you aren't doing XP properly, it isnt XP' theme
applied to "classical development".)

>
> Perhaps - and only perhaps - it's less because they do classical development
> so well (though it's probably part of the equation), but more because they
> never have seen Agile development done well?
>
>
> Interesting bias, again.

What bias?

Is the "bias" in:
what Peter Amey wrote,
my reference to what he wrote,
my questions about what he wrote,
your naming of these things as bias?

Ron Ruble

2004-07-07, 3:59 pm

"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:w4WdnZLtO8O-eHbdRVn-hg@comcast.com...
>
> "Ron Ruble" <raffles2@att.net> wrote in message
> news:tiEGc.66733$OB3.26319@bgtnsc05-news.ops.worldnet.att.net...
>
> Based on what I've seen, and discussed with others
> equally puzzled, here are some thoughts:
>
> * Lack of mastery - many of the techniques of classical
> project management are hard. In addition to instruction
> they require practice to develop confidence and proficiency.
> (Practice is different than performance. Practice is basically
> drill repetition across a continuum of complexity, with analysis
> and correction. Performance is actually doing the thing for
> real under uncontrolled circumstances.)

Reasonable. I would agree with this.

> I've been very fortunate to have had training that included
> drills, practice projects, simulations, supervised internships and
> the like.

Sigh. Must be nice (I've said that before, haven't
I? ;> )

> * Lack of leadership qualities - this is kind of fuzzy
> (and I keep working at it.) I run across a number of
> classical project managers who lack a sense of ownership,
> responsibility, who don't provide a compelling vision
> of their project. They sort of act like project bookkeepers
> rather than project leaders. I was in my manager's office
> one day for some reason or other when a vice president
> stopped in, ignored me and said to my manager, "you know
> I don't like the way so-and-so presents himself, you need
> to address that." My manager looked at him, paused, and
> said, "That's nice. He works for me, not you. You've got nothing
> to say about it." That's an attitude I've worked to emulate
> for the project teams I work with.

;> I think this is a big part of it. I agress with you about
your manager's attitude. Protecting your people from
the petty whims of others not responsible for them
(or to them) is one thing I've always tried to do for
people on my teams. I've often had them comment
on specific incidents years later.

> * Lack of a certain intellectual curiosity/aggressiveness -
> If software is thought to be plastic, malleable and
> changeable, ideas are even more so. I don't see many
> managers who will play with a bunch of different strategies
> with their teams before finding the one that suits them.

In some cases I think this is due to discomfort with being
seen as not in control of the process. It's more important
for some folks to be seen as decisive than to find a
viable strategy.

Other managers see themselves as being the hub of all
strategic thinking, and encouraging the free flow of
ideas seems to threaten that.

And often I've seen cases where a particular strategy
was decided in a closed-door session prior to the meeting
for reasons other than practical ones; one manager
repaying a favor to another, someone wants to save
face, etc. *

>
> Again, just a couple of observations:
>
> 1. For whatever reason agile methods and techniques often come
> wrapped in a thick blanket of anti-classical rhetoric. Recently,
> I read a 4 page article on agile project tracking. 2 of the pages were
> about how crappy classical approaches are. OK, I've dealt with
> blowhards and demagogues before, and winnowed out the useful
> bits, maybe I can deal. But then, you'll have statements that just seem
> so mis-informed (one of my favorites is "planning stems from a
> desire to control")

Ehhh, depends on how you read that, and the
context in which it is stated. It's not strictly true,
but in a certain context I might agree with the
message behind it.

> that you wonder how solid the proposed alternative
> really is. [This is just a suggestion; if people have experienced some
> success with a methodology, it's easier to motivate them to try
> something new by offering to make them more successful, than
> it is to suggest that they've never really been successful in the past.]

True enough.

> 2. There's a lot of puzzlement about why people will do
> amounts and kinds of work under agile methodologies
> that they didn't do under a classical methodology. In
> another thread, someone wrote about the amount of
> personal discipline required in XP. They said something
> like; "In XP I write code every day, I test the code
> everyday, I work on design every day. Every day
> I talk to my co-workers and share ideas. Every day!
> What other methodology would let me do that?"
> Well, any of them, really. Those behaviors are always
> available. Don't get me wrong, if XP gave you some kind
> of context or feeling that made that level of personal
> practice possible, then good on you, mate. At the same
> time, it's reasonable that outsiders might scratch their heads
> and ask, "Testing code? You mean you didn't before?
> Regular, frequent releases of working
> code? Couldn't you have been doing that anyway?"

I'm not going to say much about this; Ron Jeffries already
pointed out some problems in some organizations that
inhibit doing these practices. I agree in the main, there
is no intrinsic reason that these practices can't be done in
a classic project management environment, and I have
often done so, with success.

However, there is one point; if a practice is consuming
time without sufficient return, and there is a lighter practice
that may achieve better results with less overhead, it
can make sense to drop the prior practice.

> 3. Not to beat a dead horse, but I still think that each methodology
> has a 'home ground' or types of projects it's particularly good at.
> In my opinion, there are environments, and projects that are better
> served by classical methodologies, and vice versa.

Reasonable. No argument.

> 4. Synthesis of agile and classical techniques is still in an
> experimental stage. Give it time.

-Very- true.

> Ron (Ruble),
> This is a little on the side of this topic. Thank you for taking the time
> to summarize points made in other threads, and having the patience
> to read through all the different viewpoints.
>
> I learned a lot through this set of threads that helped me understand
> why some of the agile practices (and XP practices) are what they are.
>
> Thanks.

You're very welcome, and thank you for your
kind words.

---------------------------------------

* In one case, my team, internal staff, put up an competing
proposal against a consulting firm for a project. The
manipulations were amazing. We had a clearly superior
proposal, esp. in light of the fact that the prior version,
produced by the consulting firm, was a dog. Ours was
cheaper, faster, more flexible, and integrated with other
applications. And we had a solid prototype.

We still didn't get it. Secret meetings were held, and the
deciding factor was that Mr. X, a Very Important
Person in the company was the one who had picked the
consulting firm in the first place. It was more important
to him and his friends in management to salvage his
image than to produce a good application.

On the up side, they folded about 12 major improvements
we had in the prototype into their version, so the users
got a better application than they would have. Still ran
like a three-legged dog, though.

Scott Kinney

2004-07-07, 3:59 pm

"Ron Ruble" <raffles2@att.net> wrote in message
news:oLTGc.208853$Gx4.43286@bgtnsc04-news.ops.worldnet.att.net...
>
>
> In some cases I think this is due to discomfort with being
> seen as not in control of the process. It's more important
> for some folks to be seen as decisive than to find a
> viable strategy.
>
One book I read took that a step farther and suggested
that such people have so little self-confidence that they
need whatever certainty they can get or manufacture.

> And often I've seen cases where a particular strategy
> was decided in a closed-door session prior to the meeting
> for reasons other than practical ones; one manager
> repaying a favor to another, someone wants to save
> face, etc. *
>
>
> * In one case, my team, internal staff, put up an competing
> proposal against a consulting firm for a project. The
> manipulations were amazing. We had a clearly superior
> proposal, esp. in light of the fact that the prior version,
> produced by the consulting firm, was a dog. Ours was
> cheaper, faster, more flexible, and integrated with other
> applications. And we had a solid prototype.
>
> We still didn't get it. Secret meetings were held, and the
> deciding factor was that Mr. X, a Very Important
> Person in the company was the one who had picked the
> consulting firm in the first place. It was more important
> to him and his friends in management to salvage his
> image than to produce a good application.
>
> On the up side, they folded about 12 major improvements
> we had in the prototype into their version, so the users
> got a better application than they would have. Still ran
> like a three-legged dog, though.

We suffered through a similar 'back-room' deal on some
optical scanning systems that *clearly* didn't meet
the requirements in the RFP. Icky.

On a more humorous note, one project I managed had
an unusual amount of horse-trading going on (I'll help you
with that if you'll help me with this....). I laughed like a
loon when I overheard someone on the team refer to our
meetings as "the Marakesch (sp?) of hidden agendas."

Ilja Preuß

2004-07-07, 3:59 pm

Isaac Gouy wrote:
> "Ilja Preuß" <it@iljapreuss.de> wrote in message
> news:<40eb9cb3$1@news.totallyobjects.com>...
>
> Ron Ruble wrote the first 2 quoted paragraphs.

Yes, I apologize.

>
> In that situation "classical development done well" would be a new way
> ;-)

But probably not a new way one would like to give a try, I suspect.

>
> What bias?

The bias in not considering that they might as well be less smart or less
professional.

Cheers, Ilja

Isaac Gouy

2004-07-08, 3:56 am

"Ilja Preuß" <it@iljapreuss.de> wrote in message news:<40ec4d25@news.totallyobjects.com>...

>
> But probably not a new way one would like to give a try, I suspect.
>
>
> The bias in not considering that they might as well be less smart or less
> professional.

Are you saying there might be other reasons that "some people are
doing classical development so poorly" besides smarter / more
professional / different domain?

Or are you talking about something else?

Ilja Preuß

2004-07-08, 3:56 am

Isaac Gouy wrote:
> "Ilja Preuß" <it@iljapreuss.de> wrote in message
> news:<40ec4d25@news.totallyobjects.com>...
>
>
> Are you saying there might be other reasons that "some people are
> doing classical development so poorly" besides smarter / more
> professional / different domain?
>
> Or are you talking about something else?

Oh, my mistake, sorry. I thought you were comparing them simply to "people
*not* considering formal methods and static analysis basic tools of trade".

But, yes, I think there might be other reasons, such as simple personal
preference in working style.

I also wonder wether some people doing classical development well might
still see something valuable in Agile development.

Cheers, Ilja

Isaac Gouy

2004-07-08, 4:01 pm

"Ilja Preuß" <it@iljapreuss.de> wrote in message news:<40ecef12@news.totallyobjects.com>...

-snip-
> I also wonder wether some people doing classical development well might
> still see something valuable in Agile development.

Depends on what we choose to understand by "Agile development".

Ilja Preuß

2004-07-08, 4:01 pm

Isaac Gouy wrote:
> "Ilja Preuß" <it@iljapreuss.de> wrote in message
> news:<40ecef12@news.totallyobjects.com>...
>
> -snip-
>
> Depends on what we choose to understand by "Agile development".

http://agilemanifesto.org/

Cheers, Ilja

Sponsored Links