[PLUG-Devel] Scrum anyone?

[Darrin Chandler]

On Sat, Dec 30, 2006 at 04:13:27PM -0700, Alan Dayley wrote:
> In my current work environment there is very little chance of
> implementing XP.  I'm not a proponent of XP.  However, Scrum != XP.  I
> think Scrum would be good for our work and I would have a chance of
> getting permission to implement it.  In fact, I could implement a lot of
> it without telling anyone it is part of an overall system, if needed.

XP is a buzzword, as is Agile, et al. In a very real sense, all the
problems of software development were identified decades ago. Various
approaches are tried, modified, and tried again in ever differing forms
in the hopes that *this* time it'll work out. Over time some things have
become clear to me...

 * Rock star managers, analysts, designers, and programmers have
   succeeded brilliantly with various techniques over the years.

 * Mediocre or poor people using the same techniques fail miserably.

 * This week's super cool methodology contains things that you can
   point to and say "I've been doing that for years." Well, if you
   understand the underlying concepts, that is.

There are more things I could list, but I think it's more important to
see the common things the various methodologies have had in common...

 * You MUST reduce complexity somehow.

 * Try to use models that are as close as possible to isomorphic with
   the real world.

 * Get feedback as soon as possible to find errors and extract hidden
   requirements.

The problems every methodology has run into are very similar, as well...

 * Turn it into a recipe made for loser developers and it will FAIL.

 * Try it without good involvment from the user community and it will
   FAIL.

So, without having tried Scrum, I'd say that it seems to have a lot of
good ideas. Scrum teams seem good. Scrum Masters running interference
for the team is a great idea and has a lot of precedence in other
methdologies and studies done by IBM and others. Scrum's "Sprints" seems
similar to "inch pebbles" (as opposed to milestones).

I could go on about how these are good ideas, and how they solve various
problems. But the truth is that Scrum won't work for you unless you
understand it, and it fits for YOU and your team. Scrum was developed by
bright, successful people to address the issues they faced, and
shortcomings of existing methodologies for *their* situation.

You can go to the bookstore and find a lot of books on successful sales
techniques, written by salespeople who are/were at the top of their
fields. Those books are read by countless drones who can't make it work
for them. What's more, each has a different technique! All are valid!
All have worked wonders! Software development is no different in this
regard. There is NO MAGIC RECIPE for success!

In order for Scrum or any other methodology to help you, you must
understand why you are currently failing (or less good than desired),
and how and why another methodology will make things better. To *really*
succeed, you will probably need to ADAPT the methodology. You just can't
do that without grokking the "why" part. You might not even use a whole
methodology, rather using bits and pieces to create a buffet-style
methodology of your own.

This seems something like a rant. That's probably because it is. Alan,
I'm not ranting at you. I wouldn't bother saying any of this if I
thought you weren't capable of dealing with what I'm talking about. But
what I'm saying isn't said often (that I'm aware of), and I thought it
might be worthwhile.

> Our situation is a little different.  We produce and sell hardware.  So
> the product has embedded code that is highly dependent on the hardware
> design.  Even testing code, etc. is dependent on hardware (product, test
> fixtures, etc.)  I'm not sure how doing software with Scrum will
> integrate with hardware development.  All the documentation talks about
> Scrum as a purely software methodology.
> 
> But, several of the presentations discuss the principles have been
> applied at Toyota for many years.  Toyota obviously designs hardware.
> So, I have hope that it can work in our environment.

So, hardware drives requirements and introduces some unique constraints?
Hmm. Sounds familiar. Your company is unique, as are all others. ;) This
is what I'm talking about above. If you're looking for a methodology to
fit your company, you will fail to find one. They will ALL fall short
somewhere. Even if the methodology was developed by someone working in
the "embedded" market.

Methodologies and buzzwords come and go, and there are, were, and will be
organizations that can crank out winning software on time (or close) and
within budget (or close), and many, many more that can't. The real
difference is understanding the problems and applying the solutions
rather than trying to follow someone else's recipe.

-- 
Darrin Chandler            |  Phoenix BSD Users Group
dwchandler at stilyagin.com   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |