Re: [AM] Another quandry from the field - consistency

In a message dated 2/12/2004 7:33:46 AM Eastern Standard Time, 
[email protected] writes:
(responding to Steve)

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

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

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


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

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


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


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


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

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

> 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: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

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