Discussion:
[AM] Another quandry from the field - consistency
s***@aol.com
2004-02-10 19:54:13 UTC
Permalink
The people I was with last week do a fairly good job of developing systems for the state government. It is all COBOL systems run on OS-90s and AS/400s. They clearly cannot pursue an XP approach to development, but were looking at a more process-oriented method to getting their requirements defined better. It’s not that they don’t do good jobs; they are fairly successful across the boards at hitting deadlines, producing quality work and having minimal rework and maintenance problems. What they are after, and sought my help for, was consistency. They wanted to be more confident that, going in to a project, the percentage chance of success would not fall below a certain acceptable level. While, as far as I can see, they have had no spectacular failures or calamities, they still would like to get more consistency in their delivery among all their people.

Is there any other way of doing this except by establishing a process? I worked with them to adopt a “light” process, but one that would establish a floor of confidence below which project quality is not likely to fall.

Here is the real question, and it stems back to the agile dependence on “good” people, and one I hadn’t considered before. Perhaps you’ve discussed it in previous threads. Even the most high-quality of us – the Ron Jeffries and the Scott Amblers and the Paul Oldfields, etc. – are only as good as they feel at the time. We all have down times, allow overwork to mar our judgment and performance, get distracted by personal issues and so on. We are after all, human. We are not consistent.

Business wants consistent performance and may be willing to sacrifice excellence to get it, if getting excellence means there is an equal chance of failure. Business would rather have a steady stream of mediocrity that they can depend on, plan on and predict than even 80% excellence when they are never sure of when the 20% failure will occur, and the excellence as predictable as whether the star agile developer’s team won the big game the night before.

We are all professionals, particularly on this forum, but we also suffer from ups and downs and greater and lesser interest, and occasional burn-out.

Say what you will about process stifling creativity, it does promote constancy, at least in the eyes of the Upper Level Management. Mediocrity is something you can depend on, take to the bank. Everything else is a risk.

So, first question is what kind of Agile process do you suggest to a group who is already quite successful, works in non-agile technologies (COBOL, mainframe) for a highly visible state agency (Child Welfare) with high risk in the area of safety and legality? This is the challenge question.

The bigger question I have is the philosophical one of what agile methods, and especially agile modeling which I classify as more dependent on the daily capacity and attitude of the individual modeler guarantee and maintain a semblance of consistency in the face of exhaustion, hangover, burn-out, strife on the home front, the auto accident on the way to work, death in the family, etc. etc.?

As has been pointed out many times in this forum of “good people”, getting good people is one of the primary tenets of agility, and we’ve discussed it, probably not exhaustively as yet. But how about keeping the “good people” in good health mentally and physically so they can do the miracles that agility promises?

As you know from my sporadic postings from the field (although my field is mostly covered with deep carpets) I am in favor of agility, but trying desperately to close a lot of holes in the approach, so that it can be promulgated faster and farther. What say you?
-steve

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
p***@aol.com
2004-02-10 22:32:22 UTC
Permalink
In a message dated 2/10/2004 11:55:39 AM Pacific Standard Time,
Post by s***@aol.com
As you know from my sporadic postings from the field (although my field is
mostly covered with deep carpets) I am in favor of agility, but trying
desperately to close a lot of holes in the approach, so that it can be promulgated
faster and farther. What say you?
Steve:

You have hit upon one of my original concerns regarding agility: "what does
'aglity' mean in the context of software development?", and further, "How does
agility relate to what I have been doing pretty succssfully for a number of
years?".

Regarding he first question, it seems clear to me that, to many, agility is
in somewhat he same category a pornography: few can define it, but they know
it when they see it. For the record, the approach I took when I started
programming seems to have fulfilled what we now describe as agility in this forum;
certainly, it was in keeping with the spirit of the Agile Manifesto.

Regarding the second question, since agility is a process, it would seem to
me that it is entirely independent of programming languages. In fact, I have
applied successfully the principles of the Agile Manifesto in development
projects using a variety of programming languages.

So, if my asumptions regarding agility are incorrect, I would welcome and
appreciate a KITA from someone in this group.

Regarding the problem of your best developers having bad days, my appoach to
my own bad days is to minimize their effect by taking the good work I've done
on my best days, package it where possible, and re-use it wherever applicable.
For my money, anyone who is not leveraging their knowledge and experience in
this way is missing the boat: I'm trying to build better software faster, and
this approach presents an effective way to do it. (One thing I've noticed over
the years is that, while many developers can cite "chapter and verse" about
new or different development methodologies that have proven to be "safe and
effective", few actually take the time and make the effort required to learn
enough about them to apply them intelligently).

Jut some random observations...

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
s***@aol.com
2004-02-11 15:25:11 UTC
Permalink
In a message dated 2/10/2004 5:33:54 PM Eastern Standard Time,
***@aol.com writes:
You have hit upon one of my original concerns regarding agility: "what does
'aglity' mean in the context of software development?", and further, "How does
agility relate to what I have been doing pretty succssfully for a number of
years?".
In the end its all the same. I find this particular ML to provide thoughts,
philosophies, tips & techniques, approaches and ideas that are not limited to
the Agile Community. Most are directly applicable to any s/w development from
old mainframe one-COBOL-compile-a-day to
get-it-running-any-way-we'll-pick-up-the-chips-later. The Agile Books are written, with many more to come I'm
sure, so the cottage industry must be supported. But the themes and questions
and answers herein can be used by anyone seriously interested in getting a
business problem solved using information technology, and that is a wonderful place
to be. Whether you call it Agile Modeling, Business Problem Solving, or some
other phrase which will sell books and put you on the lecture circuit, it
still means getting the business what they need to be successful, and having a
relatively good time doing it.
I don't want to demean the earnest agilists out there. In fact I am saying
the opposite: your theories are more universally applicable than you might
think. And, Pete, your commentaries are a perfect example of that universality -
you and I have been agile so long our bodies are limp from the stretching. Its
too bad we didn't know we were agile. I'm not sure it would have made any
difference, but if we claimed agility as old-timers, the young-uns would have to
come up with some other phrase to sell their books. :-)
Just some thoughts from sun-addled Key West.
-steve

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
p***@aol.com
2004-02-11 18:41:07 UTC
Permalink
Post by s***@aol.com
In the end its all the same. I find this particular ML to provide
thoughts, philosophies, tips &techniques, approaches and ideas that are not limited
to the Agile Community.
Exactamundo, at least from my perspective. As I have posted on several
previous occasions, when I discovered the Agile Modeling forum, it was like
discovering a family I didn't know I had. At the time, I was interested in finding
others who shared my philosophy of regarding "building better software, faster".
This philosophy paralleled the principles of the Agile Manifesto so closely
that I felt that I could have written them myself. Nonetheless, I was somewhat
put off by the same thing that several visitors to this forum have reported:
the lack of hard and fast "bullet points" that could be applied as part of a
relatively well-defined process. It was only after a couple of months of
participation, and a face-to-face visit with Scott Ambler and Mike Visdos at SD Expo
West last year that I realized what "being Agile" really meant. It was in many
ways a confirmation of what I have believed to be a very effective approach to
the process of software development. Happily, as it turns out, despite my
somewhat "unorthodox" approach to software development, the manner in which I
have been applying agile principles over the years has worked for me, and those
of my clients (the desperate or daring ones that I've frequently mentioned) who
have "taken the plunge". (A bit of clarifation might be in order here: I
specialize in (1), the rapid development of custom business application systems or
"one off" proof-of-concept prototype application systems (including data
warehouse systems), (2) the rehosting of application systems to multiple
platforms and data access methods (for example: VSAM files on a mainframe to a DBMS or
other file system on the target platform), adding functionality (GUI front
end, new features, etc.) while retaining, if necessary, the "look and feel" of
the original (to minimize the cost of new documentation and retraining), and
(3) just about anything else that no one else seems to want to do for "the
desperate or daring", and (3), partnering with clients to develop vertical-market
application solutions for them that are "evolved" into program products for the
industries in which they compete. (This may sound far grander thn it is, and
I'm not trying to "gild the lily"; most of the projects I ork on are pretty
small, judging from what I'm deducing from the posts of others, and I often work
as a "team of one"). I believe that what successes I have achieved in these
endeavors is largely due to the unrelenting application of agile principles, as
many of my clients are "resource constrained" (i.e., money, time, personnel,
experience, etc.) and can't afford o tolerate long drawn-out development
projects.

What continues to surprise me about the agile approach to software
development is the sort of "Woodstock phenomenon" it has engendered: like the
famous/infamous concert, substantially more people report having "been there" than could
have been physically contained by the site, many developers purport to agile
principles than actually might. Of coure, there's no harm in that, except that
many project tht fail are often purported to have been "agile" when in fact
they were not, which contributes to its reportedly slow rate of acceptance. One
developer actually told me straight out that he found that the agile approach
works best for him after all of the requirements are gathered, analyzed and
the system architecture pretty much completely defined.
Go figure.

Regards,

Pete






For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
Ashley McNeile
2004-02-11 20:27:58 UTC
Permalink
Post by p***@aol.com
Exactamundo
This is an English list.

Thanks.

Ashley :-)

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
maomaostevencao
2004-02-12 02:14:43 UTC
Permalink
I am sorry.
^_^

stevencao

-----ÓÊŒþÔ­Œþ-----
·¢ŒþÈË: Ashley McNeile [mailto:***@metamaxim.com]
·¢ËÍʱŒä: 2004Äê2ÔÂ12ÈÕ 4:28
ÊÕŒþÈË: ***@topica.com
Ö÷Ìâ: Re: [AM] Another quandry from the field - consistency
Post by p***@aol.com
Exactamundo
This is an English list.

Thanks.

Ashley :-)
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
p***@aol.com
2004-02-11 21:12:46 UTC
Permalink
Ashley:

Touche that!

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
Paul Oldfield
2004-02-12 12:32:34 UTC
Permalink
(responding to Steve)
Post by s***@aol.com
The people I was with last week do a fairly good job of
developing systems for the state government. It is all
COBOL systems run on OS-90s and AS/400s. They
clearly cannot pursue an XP approach to development,
but were looking at a more process-oriented method to
getting their requirements defined better.
Cobol can be a bit of a problem, but one can still apply
techniques to reduce the ripple effect, to reduce the cost
of change, etc. I'm not an expert in applying these techniques
to Cobol, though. I'm sure it would be harder to apply XP,
but I'm not yet convinced it would not be possible.
Post by s***@aol.com
It's not that they don't do good jobs; they are fairly
successful across the boards at hitting deadlines, producing
quality work and having minimal rework and maintenance
problems. What they are after, and sought my help for, was
consistency. They wanted to be more confident that, going
in to a project, the percentage chance of success would not
fall below a certain acceptable level. While, as far as I can
see, they have had no spectacular failures or calamities,
they still would like to get more consistency in their delivery
among all their people.
Sounds like they want better feedback and better ways of
responding to the feedback - that's a first guess.
Post by s***@aol.com
Is there any other way of doing this except by establishing a
process? I worked with them to adopt a 'light' process, but
one that would establish a floor of confidence below which
project quality is not likely to fall.
Start by looking at the risks, their likelihood, their impact and
potential approaches to dealing with them. Where there's
no reasonable alternative to adding weight to the process,
I think that's the way you have to go. Beware of relying on
rules of thumb that might be out of date, but take into account
that your starting point has got to be the process that the
team is familiar with; one cannot expect to outline an ideal
process and get a team migrated to it immediately. One
rule of thumb - increase their ability to make sensible local
decisions on process, then empower them to make those
decisions. As the team gets better at being able to make
sensible decisions for itself, the process has less need of
making those decisions up front, so keep reviewing the
process to see if there are any bits you can take out.
Post by s***@aol.com
Here is the real question, and it stems back to the agile
dependence on 'good' people, and one I hadn't considered
before. Perhaps you've discussed it in previous threads.
Even the most high-quality of us - the Ron Jeffries and the
Scott Amblers and the Paul Oldfields, etc. - are only as
good as they feel at the time. We all have down times,
allow overwork to mar our judgment and performance,
get distracted by personal issues and so on. We are after
all, human. We are not consistent.
Agreed. We make bad decisions, think better of them later,
or perhaps get feedback telling us they were bad. So we
re-visit the decisions. Change happens. If we're afraid of
the risk of bad decisions and their consequences, we risk
having to put up with heavyweight processes. There's a
universal problem with design decisions anyway. The
earlier we make the decisions, the sooner we can get feedback
as to whether or not they were right. The later we make
decisions, the more information we will have to make the
decision right first time. But if we don't make *some* early
decisions, there won't be any information generated to
support the decisions we're deferring. This means we can
be sure of making some bad decisions - unless we're
exceptionally lucky. By deferring *all* decisions until as late
as possible, waterfall was setting itself up to make more
bad decisions - a risk that could be ameliorated by building
prototypes to gain feedback.
Post by s***@aol.com
Business wants consistent performance and may be willing
to sacrifice excellence to get it, if getting excellence means
there is an equal chance of failure. Business would rather
have a steady stream of mediocrity that they can depend on,
plan on and predict than even 80% excellence when they
are never sure of when the 20% failure will occur, and the
excellence as predictable as whether the star agile developer's
team won the big game the night before.
I would have thought it would be better just to hit the lower
bound of mediocrity occasionally rather than all the time,
then work on pushing up that lower bound over time by
folding in the lessons learned from the excellent results
when they happened.
Post by s***@aol.com
We are all professionals, particularly on this forum, but we
also suffer from ups and downs and greater and lesser
interest, and occasional burn-out.
...and despite the peer review from pair programming and
other communication activities, bad decisions occasionally
happen. We need to minimise the cost of re-visiting them,
and maximise the chance of spotting them.
Post by s***@aol.com
Say what you will about process stifling creativity, it does
promote constancy, at least in the eyes of the Upper Level
Management. Mediocrity is something you can depend on,
take to the bank. Everything else is a risk.
Competitor? What competitor?... You can only go so far with
that approach before somebody takes your toys away.
For monopoly work, it may take longer, but it will happen
eventually. I was about to say the taxpayer is not a fool;
well, some of them aren't and if they get too irate, they will
sway the rest.
Post by s***@aol.com
So, first question is what kind of Agile process do you suggest
to a group who is already quite successful, works in non-agile
technologies (COBOL, mainframe) for a highly visible state
agency (Child Welfare) with high risk in the area of safety and
legality? This is the challenge question.
I think I answered this above. Take whatever steps one can to
reduce the cost of change to the system. Tailor the process to
cover the risks in a way that recognises the potential of
modern techniques. Improve the team's abilities, and as they
improve, slim down the process where possible.
Post by s***@aol.com
The bigger question I have is the philosophical one of what
agile methods, and especially agile modeling which I classify
as more dependent on the daily capacity and attitude of the
individual modeler guarantee and maintain a semblance of
consistency in the face of exhaustion, hangover, burn-out, strife
on the home front, the auto accident on the way to work, death
in the family, etc. etc.?
Share the decisions, and be prepared to re-visit them.
Post by s***@aol.com
As has been pointed out many times in this forum of 'good
people', getting good people is one of the primary tenets of
agility, and we've discussed it, probably not exhaustively as yet.
But how about keeping the 'good people' in good health
mentally and physically so they can do the miracles that
agility promises?
IME, and also reported from other sources, teams taking agile
approaches tend to be in better spirits and in better mental
states. I don't know how well that carries over to physical
health.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
s***@aol.com
2004-02-12 22:20:33 UTC
Permalink
In a message dated 2/11/2004 1:41:49 PM Eastern Standard Time,
***@aol.com writes:
One developer actually told me straight out that he found that the agile
approach works best for him after all of the requirements are gathered, analyzed
and the system architecture pretty much completely defined.
Go figure.
Actually that's not as weird as it seems. In my travels over the past
several years I've come across many variations of that theme. The agile approach
(iterative, incremental, user involved, etc.) is used for the development or
build phase of the Waterfall. In many places where the entire concept of Agile
would cause total disruption of the fabric of management, it is a decent way of
getting many of the benefits of agility behind the scenes w/o mgt having to
deal with the newness of it all.
We do upfront architectural stuff first to make sure what we eventually
produce will not cause problems elsewhere in the organization and ensure we are
tackling the right problem. We then do a modicum of requirements definition to
make sure we're pointed in the right direction for each of our prototyping
sessions, then its all iterative team effort with the customer involved heavily.
We do one week deliveries. When the user/customer is satisfied with the
product we move on into integration (integrating the code with other teams' code
being developed at the same time) and then system and acceptance testing which
are basically out of the waterfall or V models, but which make mgt feel a lot
more comfortable. Since we are usually developing large scale systems for whole
enterprises, system and acceptance (of the entire package working together)
testing seems a reasonable thing to do even if it doesn't seem to be
particularly agile. By then we've gotten much of the benefits of agility into the code.
Bastardized approach to be sure. A little of this and a little of that, but
it works.
So sneaking XP into the build phase of a waterfall (particularly in the
government setting) doesn't seem too far fetched, you know?
The goal is to solve the problem, not necessarily solve it a particulal way.
-steve

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
s***@aol.com
2004-02-12 22:45:38 UTC
Permalink
In a message dated 2/12/2004 7:33:46 AM Eastern Standard Time,
***@compuserve.com writes:
(responding to Steve)
Post by s***@aol.com
The people I was with last week do a fairly good job of
developing systems for the state government. It is all
COBOL systems run on OS-90s and AS/400s. They
clearly cannot pursue an XP approach to development,
but were looking at a more process-oriented method to
getting their requirements defined better.
Cobol can be a bit of a problem, but one can still apply
techniques to reduce the ripple effect, to reduce the cost
of change, etc. I'm not an expert in applying these techniques
to Cobol, though. I'm sure it would be harder to apply XP,
but I'm not yet convinced it would not be possible.
Post by s***@aol.com
It's not that they don't do good jobs; they are fairly
successful across the boards at hitting deadlines, producing
quality work and having minimal rework and maintenance
problems. What they are after, and sought my help for, was
consistency. They wanted to be more confident that, going
in to a project, the percentage chance of success would not
fall below a certain acceptable level. While, as far as I can
see, they have had no spectacular failures or calamities,
they still would like to get more consistency in their delivery
among all their people.
Sounds like they want better feedback and better ways of
responding to the feedback - that's a first guess.

Good guess. That was where we spent most of our time.
Post by s***@aol.com
Is there any other way of doing this except by establishing a
process? I worked with them to adopt a 'light' process, but
one that would establish a floor of confidence below which
project quality is not likely to fall.
Start by looking at the risks, their likelihood, their impact and
potential approaches to dealing with them. Where there's
no reasonable alternative to adding weight to the process,
I think that's the way you have to go. Beware of relying on
rules of thumb that might be out of date, but take into account
that your starting point has got to be the process that the
team is familiar with; one cannot expect to outline an ideal
process and get a team migrated to it immediately. One
rule of thumb - increase their ability to make sensible local
decisions on process, then empower them to make those
decisions. As the team gets better at being able to make
sensible decisions for itself, the process has less need of
making those decisions up front, so keep reviewing the
process to see if there are any bits you can take out.

Sigh. Its basically a state government organization involving lots of money,
federal gov't, state and citizens, and very visible on the political scene,
particularly during election years. State govts live by rules of thumb,
especially those out of date. Fortunately, they are not state government workers
which gives them a better shot at their own process within state-imposed
limitations. And more fortunately, they really want to improve their processes and
products. The fact that the contract is up for another quadrenniel rebid might
have something to do with that as well.
Post by s***@aol.com
Here is the real question, and it stems back to the agile
dependence on 'good' people, and one I hadn't considered
before. Perhaps you've discussed it in previous threads.
Even the most high-quality of us - the Ron Jeffries and the
Scott Amblers and the Paul Oldfields, etc. - are only as
good as they feel at the time. We all have down times,
allow overwork to mar our judgment and performance,
get distracted by personal issues and so on. We are after
all, human. We are not consistent.
Agreed. We make bad decisions, think better of them later,
or perhaps get feedback telling us they were bad. So we
re-visit the decisions. Change happens. If we're afraid of
the risk of bad decisions and their consequences, we risk
having to put up with heavyweight processes. There's a
universal problem with design decisions anyway. The
earlier we make the decisions, the sooner we can get feedback
as to whether or not they were right. The later we make
decisions, the more information we will have to make the
decision right first time. But if we don't make *some* early
decisions, there won't be any information generated to
support the decisions we're deferring. This means we can
be sure of making some bad decisions - unless we're
exceptionally lucky. By deferring *all* decisions until as late
as possible, waterfall was setting itself up to make more
bad decisions - a risk that could be ameliorated by building
prototypes to gain feedback.
Post by s***@aol.com
Business wants consistent performance and may be willing
to sacrifice excellence to get it, if getting excellence means
there is an equal chance of failure. Business would rather
have a steady stream of mediocrity that they can depend on,
plan on and predict than even 80% excellence when they
are never sure of when the 20% failure will occur, and the
excellence as predictable as whether the star agile developer's
team won the big game the night before.
I would have thought it would be better just to hit the lower
bound of mediocrity occasionally rather than all the time,
then work on pushing up that lower bound over time by
folding in the lessons learned from the excellent results
when they happened.
yes. Exactly what they have in mind. Somehow increase the lower limits of
the definition of success so that each project is more successful while still
guaranteeing no projects slip. IOW following the precepts of SEI and process
improvement. But they are looking at adding process to gain consistency, and
that's a concern.
Post by s***@aol.com
We are all professionals, particularly on this forum, but we
also suffer from ups and downs and greater and lesser
interest, and occasional burn-out.
...and despite the peer review from pair programming and
other communication activities, bad decisions occasionally
happen. We need to minimise the cost of re-visiting them,
and maximise the chance of spotting them.
Preferably before they happen so we don't have to revisit them.
Post by s***@aol.com
Say what you will about process stifling creativity, it does
promote constancy, at least in the eyes of the Upper Level
Management. Mediocrity is something you can depend on,
take to the bank. Everything else is a risk.
Competitor? What competitor?... You can only go so far with
that approach before somebody takes your toys away.
For monopoly work, it may take longer, but it will happen
eventually. I was about to say the taxpayer is not a fool;
well, some of them aren't and if they get too irate, they will
sway the rest.
The winds of politics are like the Santa Ana - they come periodically, blow
hot and heavy for a while, start some fires, but then dissipate, the fires are
put out, and all that's left is an ashy taste in everyone's mouth. The
taxpayers can change the govenor and the party, but the mechanisms that run the
government go on forever, and the taxpayer wouldn't want it any other way. They
still want all the services the state provides for their tax money.
Post by s***@aol.com
So, first question is what kind of Agile process do you suggest
to a group who is already quite successful, works in non-agile
technologies (COBOL, mainframe) for a highly visible state
agency (Child Welfare) with high risk in the area of safety and
legality? This is the challenge question.
I think I answered this above. Take whatever steps one can to
reduce the cost of change to the system. Tailor the process to
cover the risks in a way that recognises the potential of
modern techniques. Improve the team's abilities, and as they
improve, slim down the process where possible.
Post by s***@aol.com
The bigger question I have is the philosophical one of what
agile methods, and especially agile modeling which I classify
as more dependent on the daily capacity and attitude of the
individual modeler guarantee and maintain a semblance of
consistency in the face of exhaustion, hangover, burn-out, strife
on the home front, the auto accident on the way to work, death
in the family, etc. etc.?
Share the decisions, and be prepared to re-visit them.
Post by s***@aol.com
As has been pointed out many times in this forum of 'good
people', getting good people is one of the primary tenets of
agility, and we've discussed it, probably not exhaustively as yet.
But how about keeping the 'good people' in good health
mentally and physically so they can do the miracles that
agility promises?
IME, and also reported from other sources, teams taking agile
approaches tend to be in better spirits and in better mental
states. I don't know how well that carries over to physical
health.


Paul Oldfield

Thanks, Paul
-steve



++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
Loading...