TITLE: Agile Moments: The Value of Smaller
AUTHOR: Eugene Wallingford
DATE: November 16, 2010  3:59 PM
DESC: 
-----
BODY:
Yesterday I read two articles that highlight, in
different ways, the value of smaller things.

<EM>Smaller Teams</EM>

<A HREF="http://scobleizer.com/2010/11/12/why-google-cant-build-instagram/">
   Why Google Can't Build Instagram</A>
relates a story about how Larry Ellison coaxed
efficiencies from teams:

<BLOCKQUOTE><EM>
If a team wasn't productive, he'd come every couple
of weeks and say "let me help you out."  What did he
do?  He took away another person until the team started
shipping and stopped having unproductive meetings.
</EM></BLOCKQUOTE>

This turns mythical man-month on its head.  I wonder
if I should try this in my project courses?

<EM>Smaller Scope</EM>

In the same blog entry, Scoble says:

<BLOCKQUOTE><EM>
[Instagram] actually started out as a service that did
a lot more than just photographs.  But, they learned
they couldn't complete such a grand vision and do it
well.  So they kept throwing out features.
</EM></BLOCKQUOTE>

If you can't do all that you dreamed of doing, do less
-- and do it well.  Articles like this one imply that,
as organizations get larger and more visible, they lose
the ability to reduce scope and focus quality on a
smaller project.  I'm not sure they lose their ability
so much as their will.

<EM>Smaller Promises</EM>

Paul Dyson
<A HREF="http://pauldyson.wordpress.com/2010/11/13/im-not-agile-just-a-little-extreme/">
   tells a familiar story</A>
about the conflict between what a name comes to connote
and the actions that are what it should denote:

<BLOCKQUOTE><EM>
I recently sat in front of a customer's project manager
-- a very smart and reasonable person -- and accidentally
used the A-word ["agile"] when describing how we were
going to deliver our product and required customisations
to them, and they sneered.

<B>They actually snorted in disgust</B>.

When I then explained we would get them live and using
the base product quickly, followed by weekly incremental
improvements with regular reviews and plenty of
opportunity for rework they were very happy.

<B>But they didn't see any connection between the two
things</B>.
</EM></BLOCKQUOTE>

The hype that seems inevitably to smother so many great
ideas in the software world has, for many parts of our
world, made "agile" meaningless at best and
<A HREF="http://wordnetweb.princeton.edu/perl/webwn?s=risible">
   risible</A>
at worst.  That's too bad, because when we ruin good
words we lose a useful avenue for communication.

Later in the same piece, Dyson offers his solution:

<BLOCKQUOTE><EM>
... it's not about being agile/Agile or achieving agility,
or being lean/Lean and efficient.  It's about delivering
software.  And I figure the best way to champion that is
actually just to get better at doing it.
</EM></BLOCKQUOTE>

I love those last two sentences.  The best way to show
people the value of patterns or TDD or refactoring or
almost any practice is to <EM>do it</EM>.  It's about
delivering software.
-----