[ale] Save the FED your Money / I need Advice / The Zero Defect Methodo logy

[Michael D. Hirsch]

On Thu, 2004-04-15 at 13:02, Hogg, Russell E. wrote:
> 
> Perhaps it's obvious from my email address, but I'm currently employed
> as Contractor for the Federal Government.
> I'm doing my piece here trying to get the way the Fed Gov does
> software systems to have some rhyme or reason.
> 
> Basically most of the horror stories you've all heard about the way
> things are done within the G is true.
> 
> There are a lot of folks working hard to change it though. ?
> I've been here long enough now that people are starting to listen to
> me. ?So I intend to use my influence.
> The release I'm currently working on is going to go live May 8th
> (https://www.mypay.dfas.mil). ?
> Yes it's presently .NET and IIS but that's really not the issue. ?
> The issue is how the projects are organized and run.
> 
> Shortly after go-live there will be a kick off meeting for our August
> release, I intend to go to that meeting armed. ?
> Armed with DOC and ideas and suggestions for what ails us.
> 
> I'm hoping for some advice on selling concepts to non-technical
> people. ?
> In particular the ZERO DEFECT METHODOLOGY.

I'm not familiar with that methodology.  Do you have any good links?  What I 
found after a quick google search tels me that it is a Microsoft term.  One 
article explained it this way:
    "zero defects" meant that at any given time, the highest priority is to  
    eliminate bugs before writing any new code.
This sounds a lot like the "fix all broken windows" idea I read about in "The 
Pragmatic Programmer", and it is a great idea.  If you leave nasty bits in 
the code, then they start to accumulate until there are too many to fix.  If 
you always fix them when they appear your code won't get the usual bit rot 
that just seems to set in.

I recommend that you take a look at Scrum <http://www.controlchaos.com/>.  
Scrum is a very nice agile management methodology as conctrasting to XP which 
is an agile development methodology.  It is really good at cutting to the 
chase and getting results from teams that aren't being productive.  I think 
it would be a great tool to insist that contractors use.

The basic idea is that each month the customer and the team agree on what will 
be produced that month.  You ONLY measure stuff that brings actual business 
value to the customer.  The customer prioritizes and the team says how long 
each item will take.  They together they select 1 month of work.  The team 
commits to producing that much *production ready* code.  At the end of the 
month they demo what they did.

One really great thing is that the iterations are fixed length and fixed 
scope.  If they don't have anything to show then they failed--you never 
extend an iteration.  If the customer wants to add a new requirement they 
need to wait for the end of the interation.  If it is crucial to add it now 
you cancel the iteration admitting failure (in this case, on the part of the 
customer) and define new goals for a new iteration.  During an iteration 
scope is fixed unless the team comes to the customer and says that they 
either underestimated the difficulty, in which case the customer is consulted 
as to which items they should not do, or over estimated the difficulty, in 
which case the customer is consulted as to what additional work should be 
done.

I'd be happy to talk to you off list about this.  I've been using it for about 
a year now with good success.  It brings about a nice accountability both on 
the part of the customer and the development team.

You can also hire people to come in and implement Scrum, if you have money for 
consultants.

With Scrum you can use XP development practices, but it is not necessary.   I 
find that management is much more resistant to XP than Scrum which is one of 
the reasons I like Scrum.  I like XP, too, but find it is a lot of trouble to 
sell to management.

Michael