Home > Archive > Extreme Programming > August 2004 > Agility and classical software project management
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Agility and classical software project management
|
|
| Ron Ruble 2004-07-04, 10:00 am |
|
A number of interesting points came up in the "Plan-Directed
vs. Agile" thread that I wanted to ask opinions on.
One that came up repeatedly is that proponents of Classical
Big-Up-Front-Planning and Agile proponents continued to
converge on the same points, reaching agreement on
goals and problems, while acknowledging that their
different experiences resulted in selecting different
solutions.
A few points on which agreement occurs, and a summary
of each. Please point out defects.
=========================
Point: Planning
Agile methodologies plan, to a great extent, -as we code-.
Classical methodologies attempt to plan up front, and
code after.
Agile methodologies acknowledge up front that planning is
never perfect, and so advocates a system with minimal
up-front overhead and frequent, code-based reality checks.
The user can see a working application in which all features
that have been implemented are complete, updated often.
Classical methodologies do not provide this same -form-
of feedback, although iterative and evolutionary methodologies
provide a few working applications at longer intervals than
agile methodologies.
In either case, it is imperative to adjust the plan when
defects or omissions in the plan are discovered. Classical
methodologies, as I learned them, are limited to formal
QA testing or semi-formal developer unit testing to
determine if assumptions in the plan are valid, and
-possibly- (but not at most organizations) accurate
metrics collection on progress.
In many organizations, these parts of the process are
delayed, skipped, or compressed enough to prevent
effective validation of the plan, at least in time to
make corrections.
Summary: Planning is always imperfect, and the probability
that we will need to make corrections after coding begins
must be acknowledged by all participants, regardless of
methodology. A good system supports detection of,
and correction of, defects in the plan.
=========================
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.
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.
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.
=========================
Point: Estimation of time/cost/units of work
This was a source of some fairly large disagreement. Scott
felt that failing too provide a (reasonably accurate) estimate
prior to beginning was a significant omission. Others felt
that as long as feedback is coming often, completely
usable applications are being produced, and the customer
can say 'stop' at any time, then estimates are unnecessary.
I suspect the truth lies somewhere between. In PeopleWare,
DeMarco and Lister pointed out that superior results can
be achieved by -not- estimating time frames.
Some fans of Agility pointed out that most estimates in
our industry are like contractor's estimates or the cable
company's estimate of when they'll be at your house;
somewhere between fantasy and fraud.
In addition, I think most of us have experienced the sort
of screwing with estimates referred to in this article,
"Estimation Games":
http://www.thomsett.com.au/main/articles/hot/games.htm
Summary (critique, please): Estimates have business value
for planning, but estimates may have greater or lesser
accuracy based on a number of factors. Some, but not
all, of these factors are under the control of the development
team. Others, depending on the organization, may be under
the control of the PM, the project sponsor, or none of the
above. Estimates may be requested and given in good
faith or under duress.
Addendum 1: Estimates given in good faith should be
reasonably reliable, but imperfect, and corrections may
be made as with other defects and omissions in the
project plan.
Addendum 2: Estimates given under duress are almost
invariably unreliable, and attempts at corrections to
estimate or project plan may be reasonably expected
to be met with additional pressure, ranging from the
subtle ("Are you going to be a team player?" to the
direct "Make it work or you're fired").
=========================
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.
=========================
Point: Commitment (and pressure)
This was a sticky point; it seemed that every respondent
had a different idea of what commitment means, and key
differences dealt with confidence levels and pressure.
One thought that came to me is that commitments can be
viewed as:
1: Good faith agreements, subject to change due to external
factors.
2: Personal statements of confidence in the viability of
estimates.
3: An agreement to own personal responsibility for
the quality of the data that went into the estimate.
4: Admission of liability for any and all failures.
Scott seemed to think of commitments as being more like
one or two. Others (myself included) were concerned
that management often views 'commitments' as 3 or
4 (probably due to personal experience in both Scott's
and other cases).
Commitments may be of different types, and involve
many factors:
1: Committing to follow the plan
2: Committing to complete specific tasks within
a certain time frame
3: Committing to results
4: Commitment in good faith vs. bad faith.
5: Pressure to commit to a plan
6: Pressure to make false statements
7: Pressure to estimate without accurate data
8: Pressure to overvalue success probability
9: Pressure to devalue risk
I do not think we gathered enough opinion or consensus
for a really decent summary, but here goes.
Summary: In good faith, all members of the team must
commit to their best; best estimates, best analysis,
best effort, best judgment, best awareness of risks,
defects, and deviations from plans and assumptions.
In a healthy organization, a commitment to stand
behind ones judgments is reasonable, and may be
reasonably requested by the customer. Currently
there is no specific consensus as far as what level
of commitment is reasonable, or what is reasonably
in an unhealthy organization where pressure to
conform to defective plans may be extreme.
With good faith or bad faith, commitments
beyond 'best effort' require a certain minimum
quality of project plan and estimate. The likelihood
of achieving this minimum drops significantly as
pressure increases.
| |
| Ronald E Jeffries 2004-07-04, 8:56 pm |
| On Sun, 04 Jul 2004 12:28:33 GMT, "Ron Ruble" <raffles2@att.net>
wrote:
>A number of interesting points came up in the "Plan-Directed
>vs. Agile" thread that I wanted to ask opinions on.
>
>One that came up repeatedly is that proponents of Classical
>Big-Up-Front-Planning and Agile proponents continued to
>converge on the same points, reaching agreement on
>goals and problems, while acknowledging that their
>different experiences resulted in selecting different
>solutions.
>
>A few points on which agreement occurs, and a summary
>of each. Please point out defects.
Nice summary. I'm going to make some new threads to see if we can get
the size back down, and perhaps have a few of them converge. (A man
has to have a dream.)
Thanks!
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| John Roth 2004-07-05, 8:56 am |
| Nice summary! I just want to address one
of the issues.
"Ron Ruble" <raffles2@att.net> wrote in message
news:RJSFc.189638$Gx4.59494@bgtnsc04-news.ops.worldnet.att.net...
>
> A number of interesting points came up in the "Plan-Directed
> vs. Agile" thread that I wanted to ask opinions on.
>
> =========================
> 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.
I don't parse the distinction that way. What I see is that
there are issues that XP does not directly address.
What XP addresses is software development: that is,
the production of an executable program. It does not
address, for example, documentation, user interface
design, data base design or a dozen other aspects of
getting a complete product out the door in good working
order.
On another dimension, it does not address practices
that may be needed in other than the simplest environments.
An example of the first is documentation production.
Documentation is usually produced by a specialist who
frequently has the title of tech writer. To see what XP
has to say about documentation, all we have to do is
apply one principle: we have a shippable product at the
end of each and every iteration. That includes the necessary
documentation, training plans and so forth (always assuming
that the customer has asked us to produce them.)
A moment's thought will show that we can't do that if
the tech writer is sitting in another department and waiting
for us to produce a system before he starts writing. So
we've discovered that the tech writer had better be in the
same room with the developers, working to the same
schedule.
There's nothing difficult about coming to this conclusion,
although it would probably make some people happier
if it was in the basic material.
I suspect Ron's objection is to the second dimension.
A good example of this is project status tracking and
reporting. Basic XP says that all you need is index
cards and Big Visible Charts. That's only true if all
the stakeholders come to the team room regularly to
look at the BVCs. If they can't or won't, you need
more, and I think that the more has settled down to
a fairly standard answer.
John Roth
| |
| Ron Ruble 2004-07-05, 3:56 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:10eie7toajn9q45@news.supernews.com...
> Nice summary!
Thanks!
> I just want to address one
> of the issues.
>
> "Ron Ruble" <raffles2@att.net> wrote in message
> news:RJSFc.189638$Gx4.59494@bgtnsc04-news.ops.worldnet.att.net...
<snip>[color=darkred]
>
> I don't parse the distinction that way. What I see is that
> there are issues that XP does not directly address.
>
> What XP addresses is software development: that is,
> the production of an executable program. It does not
> address, for example, documentation, user interface
> design, data base design or a dozen other aspects of
> getting a complete product out the door in good working
> order.
Fair enough. However, I would suggest that every one
of those things is dependent on the program we are
producing.
The program is the one unchanging part; we have to
produce one for any of these other things to be of
value; but depending on the program, these things
may be more or less valuable, and in some cases
unnecessary (database, for instance; many programs
don't use one).
Oh, one other thing: I purposely referred to these two
positions as the 'extremes'. I realize that there is a lot
in the middle, probably a majority of opinions, that
I wasn't addressing.
> On another dimension, it does not address practices
> that may be needed in other than the simplest environments.
True. But many environments are more complex
than they should be, to the detriment of performing
the core function, producing the program.
> An example of the first is documentation production.
> Documentation is usually produced by a specialist who
> frequently has the title of tech writer.
I'd have to push back on that. While documentation
is usually produced by a specialist -for commercial
applications-, and often for -large corporate applications-,
only on a tiny minority of the projects I've been involved
in is the documentation produced by a specialist.
Comments from others? Ron, your experience?
On one of the largest of those projects, this
was given to a specialist only because one of the
other developers and I suggested that that was
the best way to go. Otherwise, management was
going to have one of the developers write it.
We were under a very tight time crunch on this
project, and we both agreed that we were much
to 'head down' in the code to produce good
documentation. Shifting back into 'user thinking
mode' was just to difficult and time-consuming
while coding.
I'd need to have more in the way of numbers of
applications produced for different environments
before agreeing to what is 'usually' done. Not
arguing with your statement as much as uncertain
if it represents the -general- case.
> To see what XP
> has to say about documentation, all we have to do is
> apply one principle: we have a shippable product at the
> end of each and every iteration. That includes the necessary
> documentation, training plans and so forth (always assuming
> that the customer has asked us to produce them.)
>
> A moment's thought will show that we can't do that if
> the tech writer is sitting in another department and waiting
> for us to produce a system before he starts writing. So
> we've discovered that the tech writer had better be in the
> same room with the developers, working to the same
> schedule.
Fully agreed. I've always had best results when tech
writers and others have been in the same room, or
at least the same area.
> There's nothing difficult about coming to this conclusion,
> although it would probably make some people happier
> if it was in the basic material.
But, as I said, it may not be the -majority- of cases, in
which case leaving it out is the more 'agile' approach.
> I suspect Ron's objection is to the second dimension.
> A good example of this is project status tracking and
> reporting. Basic XP says that all you need is index
> cards and Big Visible Charts.
Not exactly, as far as I see it. Basic XP says to do
the simplest thing that works. If index cards and
hand-written charts work for you, then they are
probably the simplest thing that works.
If they don't work for you, then XP principles say
you should use something else. In other words,
XP says you -may- not need more than index
cards and hand-written charts, not that you
-will- not need more. Ron, does that sound
right to you?
One reason I suggested that one's preference in
these matters is based mostly on past experience is
that this is how it worked for me.
On many, many projects, I spent a large amount of
time stripping away things that weren't necessary*,
or automating tedious tasks that were necessary.
Hence my bias in favor of the 'add what you need'
approach.
Thanks for your comments. This summary is not
the best, I agree. I don't think we found enough
consensus so far to improve it much.
----------------------
*In one company, they had a standard technical
documentation template. Pages and pages of
placeholders for information on COBOL pictures
and other obsolete items, no place at all to put
information on classes, stored procedures, security
requirements, etc.
First step we did was redo the template. As I recall,
the single sticking point I had was a manager who
wanted me to add lots of documentation explaining
'what is a class/what is an object'. I eventually said
that anyone who didn't understand OO had no business
trying to modify the app in the first place. I ended up
with a 2 paragraph summary of OOP, references to
books, and a warning that, "if you need to read this
part, you aren't qualified to change the app; get
someone who is qualified to change it."
| |
| Ronald E Jeffries 2004-07-06, 3:56 am |
| On Mon, 05 Jul 2004 13:19:12 GMT, "Ron Ruble" <raffles2@att.net>
wrote:
>
>I'd have to push back on that. While documentation
>is usually produced by a specialist -for commercial
>applications-, and often for -large corporate applications-,
>only on a tiny minority of the projects I've been involved
>in is the documentation produced by a specialist.
>Comments from others? Ron, your experience?
>
>On one of the largest of those projects, this
>was given to a specialist only because one of the
>other developers and I suggested that that was
>the best way to go. Otherwise, management was
>going to have one of the developers write it.
>
>We were under a very tight time crunch on this
>project, and we both agreed that we were much
>to 'head down' in the code to produce good
>documentation. Shifting back into 'user thinking
>mode' was just to difficult and time-consuming
>while coding.
>
>I'd need to have more in the way of numbers of
>applications produced for different environments
>before agreeing to what is 'usually' done. Not
>arguing with your statement as much as uncertain
>if it represents the -general- case.
Product development companies, in my experience, usually have real
tech writers. IT departments usually do not. But in my opinion, the
important thing is that if you're going to do XP, you need to ship
your product every iteration, and if you need documentation as part of
your product, you need to ship that as well. So someone has to write
it. Who, I'm not so concerned about, nor, I suspect, was John. What's
important is that they are inside the team, not outside.
See also:, http://www.xprogramming.com/xpmag/manualsInXp.htm .
Is that to your point?
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Edward Berard 2004-07-28, 8:59 pm |
| In article <RJSFc.189638$Gx4.59494@bgtnsc04-news.ops.worldnet.att.net>,
Ron Ruble <raffles2@att.net> wrote:
> A number of interesting points came up in the "Plan-Directed
> vs. Agile" thread that I wanted to ask opinions on.
"Plan-directed" is probably not the best name, e.g., someone might
incorrectly infer that Agile projects are not planned, have no
direction, and/or pay little attention to planning (short term
and/or long term).
> One that came up repeatedly is that proponents of Classical
> Big-Up-Front-Planning and Agile proponents continued to
> converge on the same points, reaching agreement on
> goals and problems, while acknowledging that their
> different experiences resulted in selecting different
> solutions.
One of the problems with discussing Agile versus anything-else is the
terminology and its associated connotations, for example:
* Consider the terms "plan-directed," "classical planning," and
"big-up-front-planning." Can these terms be used interchangeably?
If not, what differentiates them from each other?
* The Agile community apparently considers "big-up-front" anything
to be gosh awful. How much up front planning (if any) is tolerable?
> A few points on which agreement occurs, and a summary
> of each. Please point out defects.
We can define a plan as a scheme for making, doing, or arranging
something, or, an outline or sketch of a method of proceeding. Plans can
exist entirely in one¹s mind, or they can be put into some viewable
form, e.g., on paper or on a computer. Examples of plans include:
* budgets
* schedules
* personnel assignments
In software engineering, we often devise plans for each separate
software engineering activity, e.g., development, testing, software
quality assurance, maintenance, and domain analysis (reusability).
We note that, in at least some Agile scenarios, there may be only
a single, central planning effort, and, hence, only a single plan,
or a reduced number of plans (when compared to the more traditional
engineering efforts).
There are three main categories of plans:
* Mission Plans: These plans tell "why," as in "why does
the functional area exist?" There is usually only one mission plan
per functional area, e.g., one mission plan for the entire testing
function.
* Strategic Plans: These plans tell "what" and "when," as in
"what will we be doing for each project, and when (during each
project) will we be doing it?" Depending on the complexity of the
functional area, there may be several strategic plans.
* Tactical Plans: These plans tell "how," "who," and
"where," as in "how are we going to accomplish our work for this
specific project, who specifically will be accomplishing the work,
and where will they actually accomplish the work?" There is usually
one tactical plan per project. Further, depending on how the work
is divided for a specific project, each different functional area
will have their own tactical plan for the project.
Mission plans are typically five to seven pages in length. An
organization
or functional area may choose to update its mission plan once every six
months, or only once a year. Mission plans are non-project-specific, and
are meant to cover all projects for the organization or functional area
while they are in effect.
Strategic plans describe the (in-house, customer-imposed, or otherwise)
standards, policies, procedures, and guidelines used by the
developing/enhancing organization. Strategic plans are intended to be
(re)used across multiple projects. Depending on the software
development/enhancement approaches and philosophies for a specific
organizations, strategic plans are typically seventy to one hundred
pages in length, although they may be much shorter.
Tactical plans are "living documents," i.e., they are intended to grow
and be modified as the project progresses. Some of the more common
connotations associated with tactical plans are:
* Each tactical plan may start out as a simple table of contents. As
the project progresses, we usually add to and modify the tactical
plan.
* As additions and changes are mode to the product, corresponding
changes must be made to the tactical plan, and the whole effort
needs to be re-estimated and re-evaluated.
> =========================
> Point: Planning
>
> Agile methodologies plan, to a great extent, -as we code-.
> Classical methodologies attempt to plan up front, and
> code after.
Does your definition of "classical methodologies" include:
* Methodologies that might be used with sequential waterfall
models (circa 1956)?
* Methodologies that might be used with iterative waterfall
models (circa 1970)?
* Methodologies that might be used with spiral models (circa 1984)?
* Methodologies that might be used with evolutionary models (circa
1981)?
* Methodologies that might be used with iterative and incremental
models (circa 1968)?
Many development/enhancement methodologies can be used with multiple
lifecycle approaches. Do you define "classical methodologies" strictly
on the basis of the lifecycle approach used?
Do you make any attempt to separate planning from the choice of
methodologies and lifecycle approaches, or do you believe that once a
methodology or lifecycle approach is chosen, the manner of planning is
then fixed?
To what degree do you believe, for example, that testing can be planned?
At the beginning of a project is it possible to know all the details
about all the testing that will be required? Could someone using a
"classical methodology," for example do enough planning up front so that
the risks were low enough to proceed, and then accomplish the rest of
the planning where it was most appropriate?
(Surely, you are not saying that people using a "classical methodology"
possess a "second sight" and can somehow anticipate all of the myriad of
items that will come up during the project, and, thus plan accordingly?)
> Agile methodologies acknowledge up front that planning is
> never perfect, and so advocates a system with minimal
> up-front overhead and frequent, code-based reality checks.
> The user can see a working application in which all features
> that have been implemented are complete, updated often.
Have you ever read "Software Engineering Economics" by Barry Boehm?
The first section of chapter 21, starting on page 310, contains the
following quote:
"When we first begin to evaluate alternative concepts for a new
software application, the relative range of our software cost
estimates is roughly a factor of four on either the high or
low side. This range stems from the wide range of uncertainty
we have at this time about the actual nature of the product."
Obviously, it is not just the "agile methodologies" that acknowledge
up front that planning is never perfect.
Turning to the matter of "reality checks:" We could say that a team
using an iterative-incremental development approach could deliver
"frequent code-based reality checks" -- even if this team was not
using an "agile methodology."
Two major engineering sins are commission and omission. With commission,
we supply too much detail too soon, and thus, unnecessarily restrict
our future options. With omission, we do not supply enough detail, and
end up with decisions being made later that will have undesirable
side effects.
A good software engineer knows how to balance commission versus
omission throughout the development/enhancement effort.
This balancing act applies to planning as well. Certain planning can
and should be accomplished up front, while other planning can be
justifiably delayed until a more appropriate time.
> Classical methodologies do not provide this same -form-
> of feedback, although iterative and evolutionary methodologies
> provide a few working applications at longer intervals than
> agile methodologies.
Suppose that a team is using a "classical methodology" and
provides the customer with prototypes. (This approach has been
in use for decades.)
Suppose that a team is using a "classical methodology" and
iterative-incremental lifecycle approach.
Suppose that a team is using a "classical methodology" and
an evolutionary lifecycle approach.
How do you know that such approaches will "provide a few working
applications at longer intervals than agile methodologies?" Do
you have the results of someone's research on the topic? Is it
impossible, or highly impractical to modify a non-Agile
approach so that customers could be provided with "executable
feedback" on a timely basis?
> In either case, it is imperative to adjust the plan when
> defects or omissions in the plan are discovered.
Agreed, and this is the case with many "classical methodologies."
> Classical
> methodologies, as I learned them, are limited to formal
> QA testing or semi-formal developer unit testing to
> determine if assumptions in the plan are valid, and
> -possibly- (but not at most organizations) accurate
> metrics collection on progress.
I know of no such limitations with regard to testing plans.
It is absolutely imperative to adjust a plan whenever defects and
omissions are discovered. It is equally imperative to continually
re-test the plan throughout the effort.
Thank goodness one can purchase off-the-shelf automated management
tools that:
* Allow managers to capture plans in an automated manner
* Allow managers to quickly propagate the effects of changes
through a plan in ana automated manner
* Provide managers with warnings when certain assertions become
untrue
> In many organizations, these parts of the process are
> delayed, skipped, or compressed enough to prevent
> effective validation of the plan, at least in time to
> make corrections.
I agree that projects can be badly managed, and/or have inadequately
trained management and staff. However, I know of no methodology that
requires that this be the case.
> Summary: Planning is always imperfect, and the probability
> that we will need to make corrections after coding begins
> must be acknowledged by all participants, regardless of
> methodology. A good system supports detection of,
> and correction of, defects in the plan.
Agreed.
[Boehm, 1981]. B. Boehm, Software Engineering Economics, Prentice Hall,
Englewood Cliffs, New Jersey, 1981.
[Gunther, 1978]. R.C. Gunther, Management Methodology for Software
Product Engineering, John Wiley and Sons, New York, New York, 1978.
-- Ed
--
Edward V. Berard | Voice: (901) 309-1912
The Object Agency, L.L.C. | Fax: (901) 755-5622
2965 Cane Cr Drive | E-Mail: ed@toa.com
Germantown, Tennessee 38138 | WWW: http://www.toa.com
| |
| Ronald E Jeffries 2004-07-28, 8:59 pm |
| On Mon, 26 Jul 2004 15:01:55 -0500, Edward Berard <ed@toa.com> wrote:
> * The Agile community apparently considers "big-up-front" anything
> to be gosh awful. How much up front planning (if any) is tolerable?
What kind of planning? What units is that kind of planning measured
in?
XP includes a thing called Release Plan, which lays every known and
customer-selected feature down on a calendar. How much more planning
might one want?
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 wrote:
> Edward Berard wrote:
>
>
> What kind of planning? What units is that kind of planning measured
> in?
>
> XP includes a thing called Release Plan, which lays every known and
> customer-selected feature down on a calendar. How much more planning
> might one want?
[So long has he refuses to respond to my polite & attentive posts...]
Life is getting rather  when your replies to the founder of
news:comp.object start sounding like your replies to Universe...
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Vladimir Levin 2004-07-28, 8:59 pm |
| Edward Berard <ed@toa.com> wrote in message news:<260720041501556277%ed@toa.com>...
This is somewhat off-topic... But I sometimes wonder if so-called
plan-driven projects actually exist. I suppose they must. In my own
experience, all the methodologies that required plans in the form of
documents have been largely a waste of time *in practice*. The great
advantage of agile approaches (I am not sure what the difference
between "agile" and "Agile" is purported to be) is that they allow
reasonable people to select what degree of planning is appropriate for
their project. It's just that simple. In general, I think most
documents tend to be of value for short periods of time, and can be
safely thrown away when it outlives its usefulness. If a document is
not alive, if it does not represent an active consensus of its
stakeholders, then it has no meaning. My feeling is that is the flaw
in the heavier methodologies; they lend an importance to documents
that is extraneous to its actual use.
| |
|
| Vladimir Levin wrote:
> This is somewhat off-topic... But I sometimes wonder if so-called
> plan-driven projects actually exist. I suppose they must. In my own
> experience, all the methodologies that required plans in the form of
> documents have been largely a waste of time *in practice*. The great
> advantage of agile approaches (I am not sure what the difference
> between "agile" and "Agile" is purported to be) is that they allow
> reasonable people to select what degree of planning is appropriate for
> their project.
Without Agile practices, software engineering projects occupy a spectrum,
with excessive planning at one end, and undisciplined hacking at the other.
GUI implementation trends towards the hacking end, lead by vendors' tools
that make GUI programming appear as easy as painting. Their tools
irresistibly link painting and coding to full-featured debuggers, and
neglect hooks to enable testing. These biases resemble old-fashioned
manufacturing methodologies that planned to over-produce hardware parts,
then measured them all and threw away the defects. Both speculative planning
and endless hacking risk extra rework and endless debugging.
Agile projects rise above that spectrum. We apply discipline to the good
parts of planning and hacking. We carefully plan to write many tests, until
new features are as easy as hacking-without the low design quality and high
bug rate. Projects become useful early, and then add value incrementally.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Ronald E Jeffries 2004-07-28, 8:59 pm |
| On 26 Jul 2004 22:08:37 -0700, vladimir_levin@yahoo.ca (Vladimir
Levin) wrote:
>This is somewhat off-topic... But I sometimes wonder if so-called
>plan-driven projects actually exist. I suppose they must.
When I use the term "plan-driven", I'm imagining projects where
there's a detailed plan, breaking everything down, saying when
everything is going to be done, AND where when some task isn't done on
that date, the management assumption is that whoever was supposed to
do that has somehow screwed up.
Now the truth is that something is wrong. The plan might have guessed
wrong; the person might even have screwed up. But the most important
thing that's wrong is that whoever is supposed to be tracking the plan
(the "Project Manager"?) was supposed to know that the task wasn't
going to be done, was supposed to cause it to get done if possible,
and to adjust the plan if not. Too often, those important PM things
don't happen. Some worker somewhere is just deemed to be "WRONG", and
at the end of the project, the entire software development community
is indicted for not being able to meet their dates.
Usually, it's "not able to meet their dates the way other
projects do". That would be construction projects, which are
notoriously over time and over budget; marketing and sales projects,
which never meet projections; government projects, don't make me laugh
or cry; ...
Why are those other projects somehow seen as more successful than
software projects, even though in fact they probably aren't? I believe
that there are two very important reasons:
First, the truly tangible results of a software project often
start after the project is 2/3 to 3/4 "done". It's only when the
stuff hits the testing fan that management can really discover how
things are going.
Second, the software project offers no handles or dials for
adjustment. In construction-style projects, management can add more
shovels, or decide not to. They own the decision of how to adjust the
project, and as such, they buy into it. In software, there's generally
nothing they can do, and since they can't act, they feel that it can't
be their fault. And they might be right.
Agile methods differ from [other] in that they ship running tested
features from day one to day N. As such, they offer more information,
and management can at least adjust scope to meet the date or date to
meet the scope, in the presence of information. I'm coming to believe
that repeatedly shipping software is the key difference between agile
and [other].
>In my own
>experience, all the methodologies that required plans in the form of
>documents have been largely a waste of time *in practice*. The great
>advantage of agile approaches (I am not sure what the difference
>between "agile" and "Agile" is purported to be) is that they allow
>reasonable people to select what degree of planning is appropriate for
>their project. It's just that simple. In general, I think most
>documents tend to be of value for short periods of time, and can be
>safely thrown away when it outlives its usefulness. If a document is
>not alive, if it does not represent an active consensus of its
>stakeholders, then it has no meaning. My feeling is that is the flaw
>in the heavier methodologies; they lend an importance to documents
>that is extraneous to its actual use.
I agree that an over-emphasis on documents is unfortunate, but I
believe that when we as developers present no other useful information
to mangement, documents are the likely thing to fall back on: they are
at least something.
In a construction-style project, the documents are important only
toward the beginning. At that point, costs are low and commitments are
loose. When the thing starts being built, we can rely on much more
tangible results: how much dirt is moved, how many stories of iron are
up, and so on. The documents then take on a different and appropriate
flavor: they summarize real progress.
If software documents truly summarized real progress, they'd be of
value and we wouldn't be complaining about them. Unfortunately,
there's only one way of knowing real progress with accuracy, and
that's to know what's really working. Fortunately, there's a way of
doing software development that makes that possible.
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-28, 8:59 pm |
| On Tue, 27 Jul 2004 02:41:06 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
>Ronald E Jeffries wrote:
>
>
>[So long has he refuses to respond to my polite & attentive posts...]
I don't understand. Do I owe you a reply, or does Ed?
>
>Life is getting rather when your replies to the founder of
>news:comp.object start sounding like your replies to Universe...
My lot in life is to describe what agile software development is, and
is not, to the best of my ability. When Ed, my esteemed and honored
colleague, lays out a blanket indictment, I feel the need to get down
to cases. Sometimes agile may be guilty. But mentioning every crime
ever committed in the indictment doesn't make us guilty of each. We
need to explore them, and try them, separately.
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 wrote:
> I don't understand. Do I owe you a reply, or does Ed?
You owe me fewer ;-)
>
> My lot in life is to describe what agile software development is, and
> is not, to the best of my ability. When Ed, my esteemed and honored
> colleague, lays out a blanket indictment, I feel the need to get down
> to cases. Sometimes agile may be guilty. But mentioning every crime
> ever committed in the indictment doesn't make us guilty of each. We
> need to explore them, and try them, separately.
Nonono "agile" cannot be guilty. Only "Agile", with the caps A, can be
guilty.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Ron Ruble 2004-07-28, 8:59 pm |
|
"Edward Berard" <ed@toa.com> wrote in message
news:260720041501556277%ed@toa.com...
> In article <RJSFc.189638$Gx4.59494@bgtnsc04-news.ops.worldnet.att.net>,
> Ron Ruble <raffles2@att.net> wrote:
>
>
> "Plan-directed" is probably not the best name, e.g., someone might
> incorrectly infer that Agile projects are not planned, have no
> direction, and/or pay little attention to planning (short term
> and/or long term).
I din't name that thread, I just referred to it ;>
> One of the problems with discussing Agile versus anything-else is the
> terminology and its associated connotations, for example:
Good points all. Terminology is always going to be
problematic because it's part of the living language
and changes so rapidly.
>
> Does your definition of "classical methodologies" include:
My definition of classical methodologies is not precise.
I was not shooting for precision or creating a "pure" and
accurate definition. From my POV, the most heavily
stressed words in the quoted paragraph are "to a great
extent" and "attempt".
I specifically tried to avoid the kind of judgements you
are trying to pin down right now.
<extensive comments snipped>
I can't help but get the impression you saw something in
my post I never intended. I don't feel I can reply to these
questions because I really don't know where you are
going with this. I was attempting to articulate some
things we discussed in the prior thread, in an attempt
to find the common ground. I don't see how any of your
comments relates to common ground.
<snip>
> Obviously, it is not just the "agile methodologies" that acknowledge
> up front that planning is never perfect.
I never stated otherwise. The difference lies, in my opinion,
in focus and degree.
> Turning to the matter of "reality checks:" We could say that a team
> using an iterative-incremental development approach could deliver
> "frequent code-based reality checks" -- even if this team was not
> using an "agile methodology."
True. The differences are in degree and focus.
> Two major engineering sins are commission and omission. With commission,
> we supply too much detail too soon, and thus, unnecessarily restrict
> our future options. With omission, we do not supply enough detail, and
> end up with decisions being made later that will have undesirable
> side effects.
Which is why I am more interested in examining the needs
of any organization specifically, and trying to determine
what is best for them, rather than finding the "best"
methodology for everyone.
> A good software engineer knows how to balance commission versus
> omission throughout the development/enhancement effort.
True. My concern relates primarily to those situations
(all too frequent, in my experience) where developers
-know- what needs to be done, but are not able to
do so due to ill-considered policies or habits.
Far too many projects fail due to problems that the
development staff is aware of from w one, but
cannot get authority to do anything about.
> This balancing act applies to planning as well. Certain planning can
> and should be accomplished up front, while other planning can be
> justifiably delayed until a more appropriate time.
Yes. How much is required is partly driven by cost-benefit
analyses that are never done, in my experience.
<snip>
[color=darkred]
> How do you know that such approaches will "provide a few working
> applications at longer intervals than agile methodologies?" Do
> you have the results of someone's research on the topic? Is it
> impossible, or highly impractical to modify a non-Agile
> approach so that customers could be provided with "executable
> feedback" on a timely basis?
I am basing this not on what -might- be, but on what most
people have reported. Without the intention of being "agile',
most organizations ostensibly using classical methodologies
which produce prototypes or interim releases:
1: provide these versions at much greater intervals than
organizations using agile methodologies
2: do not provide feature completeness for a subset of
features. The versions provided tend to have dummy
menues and incomplete functions. Agile practices
recommend releasing the feature completed or
not at all, which simplifies testing and change control.
>
> Agreed, and this is the case with many "classical methodologies."
Academically, but not so much in practice. As I stated,
my focus is current practice, not ideal state.
>
> I know of no such limitations with regard to testing plans.
I do not refer to a recommendation to limit to these
types of tests, but rather a failure to teach other
testing methods.
> It is absolutely imperative to adjust a plan whenever defects and
> omissions are discovered. It is equally imperative to continually
> re-test the plan throughout the effort.
>
> Thank goodness one can purchase off-the-shelf automated management
> tools that:
>
> * Allow managers to capture plans in an automated manner
>
> * Allow managers to quickly propagate the effects of changes
> through a plan in ana automated manner
>
> * Provide managers with warnings when certain assertions become
> untrue
True; but most organizations don't use them. This too I
see as an advantage for agile methods; the simple methods
recommended don't require purchasing such tools and
integrating them into the organization. I freely admit this
is partly personal bias.
>
> I agree that projects can be badly managed, and/or have inadequately
> trained management and staff. However, I know of no methodology that
> requires that this be the case.
Nor do I; I also no of nothing in classical methodologies
that provides simple feedback to detect these problems.
Such feedback is recommended, but generally through
management control systems that are not properly used
in most organizations.
I don't feel we disagree about much, if anything. Our
focuses are somewhat different, and that is fine. My
focus is directed to meeting my objectives, and I
expect yours is directed to meeting yours.
| |
| Scott Kinney 2004-07-28, 8:59 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:f6dcg0hu93vlvr9ee6l56bp1l7066h39gb@
4ax.com...
> On 26 Jul 2004 22:08:37 -0700, vladimir_levin@yahoo.ca (Vladimir
> Levin) wrote:
>
Slowly, I'm coming to understand Ron's antipathy for 'plan-driven'.
Using what he's posted here, and in related threads, this seems
to be Ron's picture:
>
> "plan-driven",
>projects where there's a detailed plan, breaking everything down, saying
when
> everything is going to be done,
In a previous post, Ron said that the dates or estimates for this
plan were 'given' to the developers.
Further, under various forms of duress they 'agreed' to the dates
just to make the bad man go away.
>The plan might have guessed
> wrong; the person might even have screwed up. But the most important
> thing that's wrong is that whoever is supposed to be tracking the plan
> (the "Project Manager"?) was supposed to know that the task wasn't
> going to be done, was supposed to cause it to get done if possible,
> and to adjust the plan if not.
I'm a little fuzzy on this part. Why the project team doesn't
'do the simplest thing that could possibly work' and *tell*
the project manager, I don't know. What I do know is that
Ron doesn't consider the project manager to be part of the
project team, and he consistently words this phrase to put the
onus on the project manager to 'know' or 'find out'.
>AND where when some task isn't done on
> that date, the management assumption is that whoever was supposed to
> do that has somehow screwed up.
So, it's pretty vivid and horrible and understandable why
plan-driven in Ron's world is a bad thing.
You don't contribute to the plan in any real way,
the person who's supposed to monitor and fix it
doesn't do it. And the developer gets blamed.
It doesn't match my experience, but I just want to
make sure I've caught the full horror of it from
Ron's point of view.
| |
| Ronald E Jeffries 2004-07-28, 8:59 pm |
| On Tue, 27 Jul 2004 17:38:40 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>So, it's pretty vivid and horrible and understandable why
>plan-driven in Ron's world is a bad thing.
>You don't contribute to the plan in any real way,
>the person who's supposed to monitor and fix it
>doesn't do it. And the developer gets blamed.
>
>It doesn't match my experience, but I just want to
>make sure I've caught the full horror of it from
>Ron's point of view.
I do know that it /can/ be otherwise. I've seen it be as I describe,
all too often.
I met with a very highly placed executive the other day. He told me
that he believes that it's possible for programming projects to have a
plan and execute to that plan. He believes that other kinds of
projects, like construction projects, have plans and execute to them.
I'm guessing that he has never built a house. ;->
But seriously, I do believe that it is possible for programming
projects to have a plan, to throw off concrete information about how
they're doing on that plan. I also believe that it is rare, once a
programming project's plan turns out not to be coming true, to get the
plan back on track. That's because more programmers don't make a
project go faster, overtime doesn't make a project go much if at all
faster, and so on. What does work is to change scope, and that is
almost always outside the control of the project and its manager.
I believe that because constructions projects have hard data like
number of miles of road laid, and because they are amenable to getting
more concrete trucks on the job, management feels that the plans have
"come true". What has really happened is that management has been able
to balance the tension between what they want, and what was possible,
because they had their hands on the controls.
Software projects don't have the same kinds of controls, and worse
yet, too often management doesn't have hard data or access to the
controls that exist.
The Standish Report would have it that 70 percent of all software
projects "failed" to meet their original plans. I believe that. I also
believe it's possible to do better. Those statistics suggest that it's
rare, and that my view of the world is statistically more likely than
yours. I mean that in the kindest possible way.
I think we want the same things. I t hink we agree on some of the
means to get them. But darn it Scott, I have no idea what planet
you're from. It can't be from around here. Stuff doesn't seem to
happen around here the way it does where you are. I think I'd like
your planet better.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ron Ruble 2004-07-28, 8:59 pm |
|
"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:coWdnYaJp_H_VpvcRVn-hg@comcast.com...
>
> "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:f6dcg0hu93vlvr9ee6l56bp1l7066h39gb@
4ax.com...
<snip>
>
> I'm a little fuzzy on this part. Why the project team doesn't
> 'do the simplest thing that could possibly work' and *tell*
> the project manager, I don't know.
There are a couple of problems with that.
1: In many organizations, identifying a problem is strongly
discouraged. It can even get you fired.*
2: Even if you identify a problem, and inform the PM, he
often has very strong incentive to ignore it. He often
doesn't have the authority to change the plan, and
feels pressure to 'be a team player'. More than a
few times I have identified such problems and taken
it to the PM, only to be told it's not a problem, in
spite of the evidence. I have twice escalated serious
issues (as in the project will fail, not just be late or
over budget) up as many as 4 levels of management.
And -still- the decision is to ignore it.**
I agree the development team should inform the PM
of problems. But I've seen too many people destroy
their careers by doing so to believe that there is not
a real problem in how many orgs handle problem
reporting and project planning feedback.
> What I do know is that
> Ron doesn't consider the project manager to be part of the
> project team, and he consistently words this phrase to put the
> onus on the project manager to 'know' or 'find out'.
Part of that may be organizational culture. In some orgs
the PM may be actively discouraged from being "part
of the team". I've seen a little of that kind of thing; some
firms expect you to adopt a dictatorial management
style to prove you aren't one of "them" (the development
team).
<snip>
> It doesn't match my experience, but I just want to
> make sure I've caught the full horror of it from
> Ron's point of view.
Can't say how well your description meets Ron's experience,
but it's a fair description of mine.
-------------------
* Someone mentioned the difficulty of firing people
these days. It's not always a case of "you're fired";
it's often a case of "you are -never- getting another
favorable review. You're being moved to garbage
maintenance work on old systems, which are going
to be phased out, and we will phase you out with
the COBOL developers we no longer need."
** I have also, in these situations, received very
heartfelt expressions of gratitude from developers
for doing what they didn't dare to do. It's important
to note that these weren't cases where I was the
only one who saw the problem, and I might be
wrong. These were cases where almost -everyone-
saw the problem, and for other reasons felt compelled
to keep quiet.
| |
| Scott Kinney 2004-07-28, 8:59 pm |
|
"Ron Ruble" <raffles2@att.net> wrote in message
news:AaONc.341149$Gx4.110713@bgtnsc04-news.ops.worldnet.att.net...
>
> "Scott Kinney" <sakinney@ix.netcom.com> wrote in message
> news:coWdnYaJp_H_VpvcRVn-hg@comcast.com...
> <snip>
>
> There are a couple of problems with that.
>
> 2: Even if you identify a problem, and inform the PM, he
> often has very strong incentive to ignore it. He often
> doesn't have the authority to change the plan, and
> feels pressure to 'be a team player'.>
>
> Part of that may be organizational culture. In some orgs
> the PM may be actively discouraged from being "part
> of the team". I've seen a little of that kind of thing; some
> firms expect you to adopt a dictatorial management
> style to prove you aren't one of "them" (the development
> team).
'(The PM) doesn't have the authority to change the plan.'
Huh? If anyone can change the project plan, it's the project manager.
Look, I've seen project managers that I'd really classify as
'project bookkeepers'. (One person I know calls them 'project
caretakers'. Neither of us means it as a compliment.) So, I'm
not as mystified by your statement as I let on. I just think you should
expect more 'ownership' from a project manager.
Over the course of a number of projects I've taken crap for
'siding with the customer', 'siding with the developers',
'siding with the parent company', 'siding with the subsidiary
company', and so on. Project managers are going to take
crap from people. In one of Ed Yourdon's books, he
gave a quote from another source to the effect that
"If you're not pissing off at least 3 vice presidents, your
project isn't that important."
Knowing that someone will always have a criticism, you
just do what you think is best for the customer and the project
team.
I have noticed over time that people I've fought for in the past,
and in some cases that I've fought with, welcome me on their
projects. There are, of course, some that think I'm just some
kind of thug.
| |
| Scott Kinney 2004-07-28, 8:59 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:8rsdg0tgiultp790av9hfedmga3qpb53do@
4ax.com...
> I met with a very highly placed executive the other day. He told me
> that he believes that it's possible for programming projects to have a
> plan and execute to that plan. He believes that other kinds of
> projects, like construction projects, have plans and execute to them.
>
> I'm guessing that he has never built a house. ;->
>
> But seriously, I do believe that it is possible for programming
> projects to have a plan, to throw off concrete information about how
> they're doing on that plan. I also believe that it is rare, once a
> programming project's plan turns out not to be coming true, to get the
> plan back on track. That's because more programmers don't make a
> project go faster, overtime doesn't make a project go much if at all
> faster, and so on. What does work is to change scope, and that is
> almost always outside the control of the project and its manager.
>
> I believe that because constructions projects have hard data like
> number of miles of road laid, and because they are amenable to getting
> more concrete trucks on the job, management feels that the plans have
> "come true". What has really happened is that management has been able
> to balance the tension between what they want, and what was possible,
> because they had their hands on the controls.
>
> Software projects don't have the same kinds of controls, and worse
> yet, too often management doesn't have hard data or access to the
> controls that exist.
Ron,
Seriously, put down the construction project management metaphor
and back away slowly before someone gets hurt.
Construction project management is a pretty complex subject
within the study of project management. For someone, and I say
this will all due respect, who can't distinguish between software
development methodology and project management methodology,
attempting to draw lessons from construction project management
is a pretty dicey proposition.
People who do that kind of work, and other dramatic kinds of
project planning (transporting a nuclear reactor, hostage rescue,
and so on) have particular knowledge, skills, and attitudes about
planning that you don't have any experience with. It will be
very difficult for you to draw meaningful conclusions on your own.
> I think we want the same things. I t hink we agree on some of the
> means to get them. But darn it Scott, I have no idea what planet
> you're from. It can't be from around here. Stuff doesn't seem to
> happen around here the way it does where you are. I think I'd like
> your planet better.
>
I just have different challenges, that's all.
| |
| Isaac Gouy 2004-07-28, 8:59 pm |
| "Ron Ruble" <raffles2@att.net> wrote in message news:<AaONc.341149$Gx4.110713@bgtnsc04-news.ops.worldnet.att.net>...
imo We're back talking about dysfunctional organisations rather than
the pros/cons of various approaches to software development.
> "Scott Kinney" <sakinney@ix.netcom.com> wrote in message
> news:coWdnYaJp_H_VpvcRVn-hg@comcast.com...
> <snip>
>
> There are a couple of problems with that.
>
> 1: In many organizations, identifying a problem is strongly
> discouraged. It can even get you fired.*
> 2: Even if you identify a problem, and inform the PM, he
> often has very strong incentive to ignore it. He often
> doesn't have the authority to change the plan, and
> feels pressure to 'be a team player'. More than a
> few times I have identified such problems and taken
> it to the PM, only to be told it's not a problem, in
> spite of the evidence. I have twice escalated serious
> issues (as in the project will fail, not just be late or
> over budget) up as many as 4 levels of management.
> And -still- the decision is to ignore it.**
>
> I agree the development team should inform the PM
> of problems. But I've seen too many people destroy
> their careers by doing so to believe that there is not
> a real problem in how many orgs handle problem
> reporting and project planning feedback.
>
>
> Part of that may be organizational culture. In some orgs
> the PM may be actively discouraged from being "part
> of the team". I've seen a little of that kind of thing; some
> firms expect you to adopt a dictatorial management
> style to prove you aren't one of "them" (the development
> team).
>
> <snip>
>
>
> Can't say how well your description meets Ron's experience,
> but it's a fair description of mine.
>
> -------------------
>
> * Someone mentioned the difficulty of firing people
> these days. It's not always a case of "you're fired";
> it's often a case of "you are -never- getting another
> favorable review. You're being moved to garbage
> maintenance work on old systems, which are going
> to be phased out, and we will phase you out with
> the COBOL developers we no longer need."
>
> ** I have also, in these situations, received very
> heartfelt expressions of gratitude from developers
> for doing what they didn't dare to do. It's important
> to note that these weren't cases where I was the
> only one who saw the problem, and I might be
> wrong. These were cases where almost -everyone-
> saw the problem, and for other reasons felt compelled
> to keep quiet.
| |
| Isaac Gouy 2004-07-28, 8:59 pm |
| Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<8rsdg0tgiultp790av9hfedmga3qpb53do@4ax.com>...
-snip-
> I met with a very highly placed executive the other day. He told me
> that he believes that it's possible for programming projects to have a
> plan and execute to that plan. He believes that other kinds of
> projects, like construction projects, have plans and execute to them.
>
> I'm guessing that he has never built a house. ;->
Isn't it about continual improvement?
http://www.constructingexcellence.o...4027&track=Lean
-snip-
> The Standish Report would have it that 70 percent of all software
> projects "failed" to meet their original plans. I believe that. I also
> believe it's possible to do better. Those statistics suggest that it's
> rare, and that my view of the world is statistically more likely than
> yours. I mean that in the kindest possible way.
"Just having a project manager is not all that is needed. Forty-eight
percent of the successful projects had a formal project methodology,
64% had used requirement tools and 61% used project management tools
and suites. Therefore, a project manager with the right tools and
methodology can increase the success of a project." p6 Extreme Chaos
2001
> I think we want the same things. I think we agree on some of the
> means to get them. But darn it Scott, I have no idea what planet
> you're from. It can't be from around here. Stuff doesn't seem to
> happen around here the way it does where you are. I think I'd like
> your planet better.
Sampling error? Maybe the successful organizations aren't sing your
help?
| |
| Ron Ruble 2004-07-28, 8:59 pm |
|
"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:xN6dneLdWprAc5rcRVn-sA@comcast.com...
>
> "Ron Ruble" <raffles2@att.net> wrote in message
> news:AaONc.341149$Gx4.110713@bgtnsc04-news.ops.worldnet.att.net...
<snip>
>
> '(The PM) doesn't have the authority to change the plan.'
> Huh? If anyone can change the project plan, it's the project manager.
>
> Look, I've seen project managers that I'd really classify as
> 'project bookkeepers'. (One person I know calls them 'project
> caretakers'. Neither of us means it as a compliment.) So, I'm
> not as mystified by your statement as I let on. I just think you should
> expect more 'ownership' from a project manager.
I have been in many situations such as that, where the
PM is nothing but a bookkeeper. But even in projects
with a fully trained, qualified, and experienced PM,
I have seen many cases where the PM is not permitted
to change the project plan -in the way necessary to
correct the actual defect-.
It's not that he has -no- authority to change the plan;
merely that management has committed to one or more
impossible goals or constraints, and those -particular-
constraints can't be changed by the PM. He can
adjust a number of things, but not the ones causing
the biggest problems.
> Over the course of a number of projects I've taken crap for
> 'siding with the customer', 'siding with the developers',
> 'siding with the parent company', 'siding with the subsidiary
> company', and so on. Project managers are going to take
> crap from people. In one of Ed Yourdon's books, he
> gave a quote from another source to the effect that
> "If you're not pissing off at least 3 vice presidents, your
> project isn't that important."
Very true. I think part of what I have seen is driven
by too many layers of management at times. On
one project there was a laundry list of critical
problems I identified and took to the PM, in a
meeting with a few other managers. After an hour
of dicussion, they had assured themselves that,
while these were -problems-, they were nothing
we couldn't handle by playing through the pain.
Once again, these were problems all the developers
could see, not just me.*
Immediately after this meeting we had a phone
conference with one of the senior partners of
the firm, who was the project sponsor, which
I attended. He ripped the PM and the other
managers a new one, citing their failure to deal
effectively with a number of problems and relying
on the emplyees heroics to cope with them. Every
item he mentioned was on the list I had just
presented to the PM.
It still ended badly, but it was -very- hard for
the PM and other managers to downplay
my issues list after that. This was not
completely atypical, although it was the most
interesting timing I've experienced. ;>
> I have noticed over time that people I've fought for in the past,
> and in some cases that I've fought with, welcome me on their
> projects. There are, of course, some that think I'm just some
> kind of thug.
;>
Same here.
---------------------
* No PCs or desks for 15% of the staff, -at all-,
for upwards of 12 ws; that was about 20% of
total schedule. No network ids for another 10%,
and what PCs were available were running Win95,
when the application mandated Windows NT 4.0.
Some stuff just would not run in Win 95.
Key parts of the application depended on -very-
brand new features added to 2 vendor tools. All
inadequately documented, and we were unable to
get anyone to train the developers in these features.
Many staff members were reduced to learning these
features by trial and error. Several -major- defects
were discovered with these tools that had not been
caught previously.
Schedule was compressed to les than -half- what
realistic estimates indicated based on the workload.
I lucked out, and got off the project early. Some
friends of mine had to stay till the bitter end.
| |
| Ron Ruble 2004-07-28, 8:59 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0407281124.472dc1f2@posting.google.com...
> "Ron Ruble" <raffles2@att.net> wrote in message
news:<AaONc.341149$Gx4.110713@bgtnsc04-news.ops.worldnet.att.net>...
>
> imo We're back talking about dysfunctional organisations rather than
> the pros/cons of various approaches to software development.
Yes, but... the value of an approach is how well it works
in practice. There are a lot of dysfunctional organizations
out there. Part of the problem in the discussion, I feel, is
that various people want to treat these orgs as statistical
outliers. I feel these kinds of problems exist in too much
of the realistic sample population to be dismissed as
outside the discussion. If one approach can help to
improve the chances of success in a (reasonably mildly)
dysfunctional organization, I want to be aware of that.
| |
| Jeff Grigg 2004-07-28, 8:59 pm |
| --- "Scott Kinney" <sakinney@ix.netcom.com> wrote...
> Ron,
> Seriously, put down the construction project management metaphor
> and back away slowly before someone gets hurt.
>
> Construction project management is a pretty complex subject
> within the study of project management. [...]
When I visit the site where they're building my new house, and find
that they haven't laid the foundation, I know that they haven't made
much progress.
On the other hand, if I'm running a software development project, and
the team has produced a great many documents and diagrams, are they
10% done? 0% done? ...going down a hole from which they will never
escape? Well, it's hard to tell.
Some things that are relatively easy to manage in a construction
project are very hard in a software development project. And the
reverse. But our concern, in software development is the things
people *think* should be easy in software because they're "easy" in
construction. (Things that are easy in software, but hard in
construction don't bother us.)
So the construction metaphor can do us a great disservice. A great
many disservices. ;->
| |
| Scott Kinney 2004-07-28, 8:59 pm |
|
"Jeff Grigg" <jgrigg@mo.net> wrote in message
news:c794c0fd.0407281617.10ba993b@posting.google.com...
> --- "Scott Kinney" <sakinney@ix.netcom.com> wrote...
>
> When I visit the site where they're building my new house, and find
> that they haven't laid the foundation, I know that they haven't made
> much progress.
>
Not necessarily, Jeff. They may be practicing 'emergent construction'
and letting the ground speak to them so they'll know how to do the
foundation.
(Well, it's better than some architect saying up-front what the foundation
is
supposed to be, isn't it?)
| |
| Ronald E Jeffries 2004-07-29, 3:56 am |
| On Wed, 28 Jul 2004 20:49:35 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>Not necessarily, Jeff. They may be practicing 'emergent construction'
>and letting the ground speak to them so they'll know how to do the
>foundation.
>(Well, it's better than some architect saying up-front what the foundation
>is
>supposed to be, isn't it?)
Very funny. But here's a suggestion. Let's lay some concrete for a
day, and write some code for a day. Then I'll refactor the code, and
you refactor the concrete. We'll find out a little something about
emergence in various media. :)
--
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-29, 3:56 am |
| On Wed, 28 Jul 2004 14:33:53 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>Construction project management is a pretty complex subject
>within the study of project management. For someone, and I say
>this will all due respect, who can't distinguish between software
>development methodology and project management methodology,
>attempting to draw lessons from construction project management
>is a pretty dicey proposition.
Perhaps I, and the rest of the readers, would benefit from more
instruction and fewer insults.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Isaac Gouy 2004-07-29, 3:56 am |
| "Ron Ruble" <raffles2@att.net> wrote in message news:<1RUNc.343083$Gx4.236799@bgtnsc04-news.ops.worldnet.att.net>...
>
> Yes, but... the value of an approach is how well it works
> in practice. There are a lot of dysfunctional organizations
> out there. Part of the problem in the discussion, I feel, is
> that various people want to treat these orgs as statistical
> outliers. I feel these kinds of problems exist in too much
> of the realistic sample population to be dismissed as
> outside the discussion. If one approach can help to
> improve the chances of success in a (reasonably mildly)
> dysfunctional organization, I want to be aware of that.
Fair enough - the previous posting seemed to lament dysfunctions
rather than propose any particular way of working within those
organizational limitations.
| |
| Ilja Preuß 2004-07-29, 3:56 am |
| Ron Ruble wrote:
> If one approach can help to
> improve the chances of success in a (reasonably mildly)
> dysfunctional organization, I want to be aware of that.
I am not even convinced that the two are fully orthogonal. Might well be
that sensibly implementing a different software development approach can
help an organization to become less dysfunctional?
Cheers, Ilja
| |
| Scott Kinney 2004-07-29, 8:56 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:s3kgg0114kffc46i05t5drqbh484odpfo1@
4ax.com...
> On Wed, 28 Jul 2004 14:33:53 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Perhaps I, and the rest of the readers, would benefit from more
> instruction and fewer insults.
>
Perhaps I would find more sincerity in that sentiment if, on the occasion
of the 8th or 9th time I posted a listing of project management methodology
domains, you hadn't dismissed it as 'a god-blasted list of items that have
to
be checked off'.
| |
| Scott Kinney 2004-07-29, 8:56 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:s3kgg0114kffc46i05t5drqbh484odpfo1@
4ax.com...
> On Wed, 28 Jul 2004 14:33:53 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Perhaps I, and the rest of the readers, would benefit from more
> instruction and fewer insults.
>
No insult was intended. You've never made a distinction between
software development methodology and project management
methodology. Not once.
So, perhaps the more correct statement would be that you
don't distinguish between the two. Even so, my point
still stands.
| |
| Isaac Gouy 2004-07-29, 3:56 pm |
| "Ilja Preuß" <preuss@disy.net> wrote in message news:<ceaa0p$913$1@stu1id2.ip.tesion.net>...
> Ron Ruble wrote:
>
>
> I am not even convinced that the two are fully orthogonal. Might well be
> that sensibly implementing a different software development approach can
> help an organization to become less dysfunctional?
When the people start behaving in wierd ways and no one else delivers
the bad news then ...
http://groups.google.com/groups?q=g...br />
404ax.com
| |
| Ronald E Jeffries 2004-07-29, 3:56 pm |
| On Thu, 29 Jul 2004 05:05:28 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>Perhaps I would find more sincerity in that sentiment if, on the occasion
>of the 8th or 9th time I posted a listing of project management methodology
>domains, you hadn't dismissed it as 'a god-blasted list of items that have
>to
>be checked off'.
Did I really say that, in that context? My group-searching abilities
are too weak to be sure.
Was it really the 8th or 9th time for the same list?
Some people are slow to learn. Sometimes I'm one of them. Usually it's
my fault, not that of the teacher.
--
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-29, 3:56 pm |
| On Thu, 29 Jul 2004 05:05:28 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>Perhaps I would find more sincerity in that sentiment if, on the occasion
>of the 8th or 9th time I posted a listing of project management methodology
>domains, you hadn't dismissed it as 'a god-blasted list of items that have
>to
>be checked off'.
Ah. Found it. And I quote myself:
========
In projects where those things are thought to be important, the people
do more work to deal with them. In projects where they are thought to
be less important, they do less. When things emerge that weren't
thought of, people do their best to figure them out.
It's not magic, it's people working together. And a better alternative
isn't to have some god-like project manager who knows all and sees
all. Nor is it to have some god-blasted list of items that have to be
checked off. Both of those, an expert, or an expert's list, are nice
to have. But my experience says that any ten experienced people could
create the project domain item risk list for their project in a
morning's brainstorming, and that it would work just fine.
The question is, I think, to what extent are we going to trust our
people to come together with all their skills and control the project,
and to what extent are we going to try to embody the control of the
project in external documents and expert "project managers".
Agile projects work toward the "come together with skills" side of
that space, and less agile projects work toward the "external
documentation and experts" side of the space.
No one is recommending magic. Agile projects are recommending relying
more on the abilities and creativity of the available people.
========
Now unless you are recommending a list of items that have to be
checked off, I don't see your problem. I'm saying that agile projects
work on the side of the balance where the team is trusted to come up
with the issues that need addressing. I'm suggesting that less agile
projects work more on the side where the comprehensive lists are
considered important.
What part of that sounds like I don't know the difference between
project management methodology and software development methodology,
or that the difference was even being discussed?
To be clear: I certainly don't know everything about project
management methodology, but I could probably pass a quiz on it at the
201 level. I just don't find it as valuable in managing actual
software projects as some people do.
I'm more interested in what the team knows and does than in the
details of the methodology behind what they do, whether that's
software development methodology or project management methodology.
Naturally I'd like them to know everything about both. But I wouldn't
want them to /do everything/ from both, or anywhere near it.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Vladimir Levin 2004-07-29, 8:55 pm |
| "Emergent construction" would certainly not involve staring at the
ground. It would likely involve digging a foundation, building part of
a house on top of it, and then starting over again once it becomes
clear that the current "design" is inadequate. This would be pretty
silly. That's why home construction is not a great metaphor for
software.
"Scott Kinney" <sakinney@ix.netcom.com> wrote in message news:<jv2dnTG3f_4_1JXcRVn-iQ@comcast.com>...
> Not necessarily, Jeff. They may be practicing 'emergent construction'
> and letting the ground speak to them so they'll know how to do the
> foundation.
> (Well, it's better than some architect saying up-front what the foundation
> is
> supposed to be, isn't it?)
| |
| Ken Boucher 2004-07-29, 8:55 pm |
| Vladimir Levin wrote:
>
> "Emergent construction" would certainly not involve staring at the
> ground. It would likely involve digging a foundation, building part of
> a house on top of it, and then starting over again once it becomes
> clear that the current "design" is inadequate. This would be pretty
> silly. That's why home construction is not a great metaphor for
> software.
What is the foundation for a software project?
Is it the code or is it how the people agree to work together?
Perhaps "Emergent Construction" involves the building of a sound foundation so
that the structure can support multiple uses.
I notice for example that the office I work in used to be a Richman-Gordman
store. The same building still houses a supermarket. We have an ideal large room
for use with nice office space. Earlier in our lives, when we clung to old forms
we had a nice set of cubicles in an area that is now much more open and
conductive to how we do business.
In this respect there was a good solid foundation for us to build something that
became something much more than we thought it could be. What was amazing is that
we didn't dream of how we would rebuild it until after we had already started
inhabiting it.
That, in my opinion, is what "Emergent Construction" would be like. And it
certainly involved starting at the ground and building a solid foundation. One
we've had no need to change.
| |
| Scott Kinney 2004-08-03, 9:04 am |
| Leaving the issue of software development methodology vs.
project management methodology for another time, your
requoting and elaboration brings up a couple of other questions.
When discussing the values of 'working together', 'collaboration',
and 'coming together with skills'; you made it an either/or question.
I'd ask that you imagine the benefit to your customer and the project
overall, if collaboration included the project manager. Or if the
skills being brought together included project management
skills.
I'd also ask what you result you hope to obtain from
discussion construction project management issues? What
do you want to get from that?
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:8riig05l1mr1r6m1sofc93i3dq38433oos@
4ax.com...
> On Thu, 29 Jul 2004 05:05:28 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
methodology[color=darkred]
have[color=darkred]
>
> Ah. Found it. And I quote myself:
> ========
> In projects where those things are thought to be important, the people
> do more work to deal with them. In projects where they are thought to
> be less important, they do less. When things emerge that weren't
> thought of, people do their best to figure them out.
>
> It's not magic, it's people working together. And a better alternative
> isn't to have some god-like project manager who knows all and sees
> all. Nor is it to have some god-blasted list of items that have to be
> checked off. Both of those, an expert, or an expert's list, are nice
> to have. But my experience says that any ten experienced people could
> create the project domain item risk list for their project in a
> morning's brainstorming, and that it would work just fine.
>
> The question is, I think, to what extent are we going to trust our
> people to come together with all their skills and control the project,
> and to what extent are we going to try to embody the control of the
> project in external documents and expert "project managers".
>
> Agile projects work toward the "come together with skills" side of
> that space, and less agile projects work toward the "external
> documentation and experts" side of the space.
>
> No one is recommending magic. Agile projects are recommending relying
> more on the abilities and creativity of the available people.
> ========
>
> Now unless you are recommending a list of items that have to be
> checked off, I don't see your problem. I'm saying that agile projects
> work on the side of the balance where the team is trusted to come up
> with the issues that need addressing. I'm suggesting that less agile
> projects work more on the side where the comprehensive lists are
> considered important.
>
> What part of that sounds like I don't know the difference between
> project management methodology and software development methodology,
> or that the difference was even being discussed?
>
> To be clear: I certainly don't know everything about project
> management methodology, but I could probably pass a quiz on it at the
> 201 level. I just don't find it as valuable in managing actual
> software projects as some people do.
>
> I'm more interested in what the team knows and does than in the
> details of the methodology behind what they do, whether that's
> software development methodology or project management methodology.
> Naturally I'd like them to know everything about both. But I wouldn't
> want them to /do everything/ from both, or anywhere near it.
>
> 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-08-03, 9:04 am |
| On Mon, 2 Aug 2004 08:35:19 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>Leaving the issue of software development methodology vs.
>project management methodology for another time, your
>requoting and elaboration brings up a couple of other questions.
>
>When discussing the values of 'working together', 'collaboration',
>and 'coming together with skills'; you made it an either/or question.
>I'd ask that you imagine the benefit to your customer and the project
>overall, if collaboration included the project manager. Or if the
>skills being brought together included project management
>skills.
I would always have the whole team together if possible. Therefore if
the team has a project manager, I'd like her to be there.
Having skills is always better than not having them. Therefore I'd
prefer having project management skills as part of the team's skill
set.
>
>I'd also ask what you result you hope to obtain from
>discussion construction project management issues? What
>do you want to get from that?
I am hatching this notion that many conventional projects actually
deliver no more )on time on budget fit for purpose) than do software
projects, but that their poor performance is more acceptable. My
thinking is that among the reasons for this are:
1. It is easier to tell when such a project is off track;
2. Managers can intervene and help with money, people, scope, or date
changes;
3. If intervention is insufficient or inappropriate, managers were
part of the decision process;
.... and the same are not so true for software projects:
1. More of the deliverables are intangible and therefore harder to
track;
2. There's less to do even when things are tangible and less time to
do it in because so much of the project is intangible;
3. managers who cannot intervene or decide not to are less satisfied
with results than those who got involved and therefore "know" that
everyone did their best.
I'm not sure what the right description of what I'm calling
"conventional" or "construction-style" projects might be. And of
course the whole notion might be wide of the mark.
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-08-03, 9:04 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:d4vtg0pp5r5k47ni538btull0o2ru6td91@
4ax.com...
> I am hatching this notion that many conventional projects actually
> deliver no more )on time on budget fit for purpose) than do software
> projects, but that their poor performance is more acceptable. My
> thinking is that among the reasons for this are:
>
My gut reaction is "Argue for your limitations, and they'll let you keep
them."
Anyhow, I'll play....
> 1. It is easier to tell when such a project is off track;
Do you mean this from a standpoint of schedule and tangible
results?
> 2. Managers can intervene and help with money, people, scope, or date
> changes;
You might be a)idealizing other managers or b)catastrophizing software
managers, or c)confusing "can't", "won't", "I can't seem to convince them
to."
Where this does happen (software, construction, and other kinds of projects)
there seem to be the following ingredients; rapport with managers,
decision-grade
information (costs, alternatives, critical path analysis, evidence.), shared
sense of
urgency.
> 3. If intervention is insufficient or inappropriate, managers were
> part of the decision process;
>
> ... and the same are not so true for software projects:
>
> 1. More of the deliverables are intangible and therefore harder to
> track;
And yet you work so hard to supply evidence of completion <grin>
One of the tricks/challenges to software projects is providing
the evidence along the way. XP has 'running tested features', for
example. When I train people in how to develop project requirements,
3 of the most important words are "As shown by...", in other words
an evidence procedure.
> 2. There's less to do even when things are tangible and less time to
> do it in because so much of the project is intangible;
I think you might be begging the question here.
> 3. managers who cannot intervene or decide not to are less satisfied
> with results than those who got involved and therefore "know" that
> everyone did their best.
That's true, but not limited to the software industry.
>
> I'm not sure what the right description of what I'm calling
> "conventional" or "construction-style" projects might be. And of
> course the whole notion might be wide of the mark.
>
If you were to look at other kinds of projects with even tighter
timeframes, taking place in highly dynamic environments, where the
ability to supply additional resources may be constrained physically;
you might pick up on other attributes that could be adapted within
IT projects to great benefit.
For example; 1)shutting down a nuclear reactor, 2)hostage rescue, 3)surgery.
Project plan times frames are denominated in minutes and
seconds respectively. Additional project resources are somewhat problematic
And, you'd admit, I think, that the operational environment is dynamic and
highly
volatile.
I have more experience with S.W.A.T. type projects, but my conversations
with
PMs in the nuclear industry support at least some of my observations:
Success attributes include:
1. Intact teams. Teams that have trained together, and worked together will
tend to do better than those just thrown together.
2. Tools appropriate to the job. (in IT's case, automated testing tools,
estimating
tools, requriements management tools, etc.)
3. Practice. Even though a given project may be unique, certain processes or
operations are common to all of them. These kinds of teams practice those
operations;
drill them, as it were, against a continuum of resistance*, and problem
solving within the
operation. One law enforcement training center I know of goes so far as to
point out where in the operation you're likely to have to improvise, and the
boundaries
of the improvisation.
The attribute of practice and drilling common operations offers the biggest
area for
improvement. Very few people do it. When I've done it (in the form of
scenario
walkthroughs, rehearsals, etc.), the results of actual operations are much
satisfying.
I've gotten similar feedback from other PMs that do this.
*The funniest 'continuum of resistance' story comes from director Garry
Marshall.
He took a 'practical writing' class in college. In every session, they'd be
given a topic,
and a certain number of words to be turned in at the end of class. What was
'practical'
about it? During the class, TA's swarmed the room, talking to students,
asking them
questions, making noise, taking their papers away, etc.
| |
| Ken Boucher 2004-08-03, 9:04 am |
| > For example; 1)shutting down a nuclear reactor, 2)hostage rescue, 3)surgery.
It occurs to me that as a society we've found all three groups are
cost-effective to spend very large amounts money of training. The volume of
successful delivery isn't particularly high in the first two cases and the cost
of failure is much higher in all three. In the third group, with high cost of
failure and high demand, you see the sort of financial reward that programmers
only dream of getting in an IPO.
While there are things to be learned from a SWAT team, I have a hard time
picturing a company that makes money by organizing their software developers
into teams and then has them practice and drilling common operations instead of
simply executing common operations by working. The primary difference being that
the SWAT team's failure in an exercise don't have any customer impact (it's
simply a learning experience) but the programming team always has a customer
that has to live with the results.
| |
| Scott Kinney 2004-08-03, 4:04 pm |
|
"Ken Boucher" <bons@cox.net> wrote in message
news:410F7A76.860C17C0@cox.net...
3)surgery.[color=darkred]
>
> It occurs to me that as a society we've found all three groups are
> cost-effective to spend very large amounts money of training. The volume
of
> successful delivery isn't particularly high in the first two cases and the
cost
> of failure is much higher in all three. In the third group, with high cost
of
> failure and high demand, you see the sort of financial reward that
programmers
> only dream of getting in an IPO.
>
I'm not sure what your point is here. I would like to 'adjust' some of your
reasoning here and below to be a little more accurate.
'Society' is a little too grand a concept here. Whether you
are talking about NRC, Miami-Dade SWAT, or, Delta units in the
Army, all of these groups wrestle through budgetary exercises to
balance staffing, equipment, facilities and training. No one has a
blank checkbook, or even a particularly large one. They get what
they can negotiate. In the case of surgeons, practitioners take on
large amounts of personal debt to acquire their training.
In the case of SWAT or special operations units (where I'm a little
more comfortable), there's a colorful history of the 'creativity' with
which they find training environments. One unit I know of has
reached out to demolition companies in their area. When a building
of any kind is going to be demolished, they get the option to 'train' in
it for a day before it's taken down.
Also, metropolitan SWAT teams can deploy over 300 times a year.
Typically, they serve 'high risk' arrest warrants and search warrants,
and are sometimes deployed with narcotics units. They still train.
> While there are things to be learned from a SWAT team, I have a hard time
> picturing a company that makes money by organizing their software
developers
> into teams and then has them practice and drilling common operations
instead of
> simply executing common operations by working.
Why 'instead of'? Why not 'dividing time between working and training'?
| | |