My adaptation of esr's open source approach:

  1. paint a picture of something really cool
  2. deliver the smallest possible subset of that functionality, that runs
  3. be guided by "bug reports" that request features to fill these *gaps*

This only works for a "flat" project - that is, where each additional feature can be added as a module. This requires a concept that is "flat" and an implementation architecture that is "flat" (has places to add each feature.) If the concept is not flat (or unknown), or if the right architecture is not flat (or unknown), this approach doesn't work.

This helps explain the kinds of projects that have popular open source implementations: copies (of concept and implementations) and system software.

Isn't this principle the basis of agile development? Who is this post for?

May be most relevant (possible) for small-to-medium size projects, but the principles of keeping the outcomes in mind and getting feedback* regularly (whether weekly or monthly, etc) are useful for me, at least.

* whether it's feasible to get the feedback from end user or from a tester.

Ugh.

I love agile, but agile writing has a tendency to sound like Zen koans. (And yes, I include my own writings here)

It's just really tough to bridge that gap between "deliver something of value every week" and "what do I do in this team, on this project, right now?"

Every week? That's what they do in enterprises and we all know how fast they move.

Every day? Still not granular enough.

You should deliver something of value every hour, even if it's only to yourself.

Big Value = the sum of(many little values)