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. Smaller Teams Why Google Can't Build Instagram relates a story about how Larry Ellison coaxed efficiencies from teams:
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.
This turns mythical man-month on its head. I wonder if I should try this in my project courses? Smaller Scope In the same blog entry, Scoble says:
[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.
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. Smaller Promises Paul Dyson tells a familiar story about the conflict between what a name comes to connote and the actions that are what it should denote:
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. They actually snorted in disgust. 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. But they didn't see any connection between the two things.
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 risible 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:
... 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.
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 do it. It's about delivering software. -----