

Deliver something of value every week - rasmus4200
http://agilewarrior.wordpress.com/2009/06/03/deliver-something-of-value-every-week/

======
10ren
_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.

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

------
CalmQuiet
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.

------
DanielBMarkham
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?"

------
edw519
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)

