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

[John Mills]

John -

On Thu, 3 Jun 2004, John Wells wrote:

> 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

Oh yeah - about 0dB for the business?

> I'd like to establish proper, repeatable processes and bring some order to
> it all.  I've been a fan in the past of monthly development iterations,
> where all interested parties meet at the beginning of each month, promote
> their projects, and then as a group decide which have the highest
> priority.  I'd like to take similar approach here and additionally
> establish a SCCB that would provide the final word on software changes.

 <SOAPBOX>
 My simple dogma is, "People will use the tools they think help them, and
almost always subvert the tools they think impede them." It's a corrolary
of the principle, "Most people, most of the time, try to do what the think
is a good job of whatever they're trying to do," which has generally been 
my experience.

Introduce tools in a way that makes life easier for the staff and you have 
a better chance they'll be used and made to work.

Tools and controls do have to match the operation they're going into: one 
of my employers dropped a fair number of $$ and "live" employee traning 
for a "problem management" system that was a total mismatch to the makeup 
and style of the engineering group, and to the development state of our 
software. Fortunately they had the sense to listen to the staff and can 
the tool!

I was (fairly) successful merging Wintel and Linux development streams of
a client by ensuring that both groups worked from a common source base and
were provided with simple tools to build all the target versions,
regardless which was their primary environment. A new source-code
mangement tool (CVS) helped, but primarily because it added function for
us (more seats and much improved off-site access). I spent time to make it
smooth to use, I wrote some user info, and I trained people into doing
their jobs slightly differently without causing problems to their
colleagues.

The best result was that Linux developers moved from the Twilight Zone
into the mainstream, and code added by one group was immediately plowed
into the full development setting for all to try, fix, and use.

Summary: if you can sell the approach to the users, they'll make efforts
to help it succeed. Otherwise, it'll probably be fought (not necessarily
for reactionary reasons).

There is another whole set of issues in selling new approaches 'upwards' 
to get [non-intrusive] management support and give them reasonable 
expectations. This we'll leave as "an exercise to the reader."

This will be a great opportunity to improve your diplomatic skills, no 
matter how good they are!
 </SOAPBOX>

 - John Mills
   john.m.mills at alum.mit.edu