[ale] (repost from outage) -- Scrum?

[Ronald Chmara]

On Jun 3, 2004, at 9:32 AM, John Wells wrote:
> Guys,
> I took over a small development shop in a big company back in October.
> The development process here is essentially non-existent...if the CMM
> allowed negatives, we'd be around -5
>
> I'd like to establish proper, repeatable processes and bring some 
> order to
> it all.
.....
> However, I'm also sensitive to implementing heavy, obtrusive processes 
> in
> an environment that's quite accustomed to none.  I don't want to chose 
> a
> system that will take me 3 months to learn and my developers even
> longer...

I've done this. It takes much longer than most people might think. 
Short of firing your entire staff and starting over (which is heavy 
brain drain), instilling code and process discipline, without an 
outright revolt, takes some time. Scrum, like most disciplined 
processes, *will* take years to implement properly. Some houses get to 
the breaking point with code-check-in (CVS, etc.), others with hard 
requirements, others with hard goals and targets, and some don't even 
know what offline development means (er... not working on live, active, 
code).

Disclaimer: Of course, some software development houses are actually 
worse off, and more chaotic, with fixed process systems being 
artificially overlaid, if the software development is in an unusual, 
unpredictable, or exploratory field.

As a rule, I find that a slow ramp-up, a slow but steady increase in 
formal processes, tends to be more effective than the shock of 
implementing a new "whole-cloth" system. IOW, if there is no CVS (or 
similar), no requirements papers, no regulated self-accounting, no set 
accomplishment points, no goals systems (etc. etc. etc.), trying to 
change everything overnight just plain doesn't work. The first thing 
that must happen in that situation is for the "process manager", or 
"project manager", to start setting iterative goals to instill the 
process flow itself.

-Bop