I just got a copy of Managing Agile Projects, edited by Kevin Aguanno and with chapters contributed from a number of people including Kevin himself, Scott Ambler, Alistair Cockburn, Larry Constantine, David Hussman, Ron Jeffries, Linda Rising, and others.

I'll post a review when I'm done with it but you really shouldn't wait for it because all author royalties go to charity!

Managing Agile Projects
Buy directly from the publisher and support the International Red Cross disaster relief fund.

(Also note that there's two books with the same name at Amazon.com -- the "right" one is this one)

A while back I blogged about Jack Reeves' old code-is-design stuff and quoted Bob Martin as well. Well, it looks like Ted Neward found another somewhat similar quote from James Coplien in Multi-Paradigm Design for C++:

Many contemporary methods view design as a phase intermediate to architecture and coding, instead of viewing architecture and coding as products of design. But from a more practical point of view, we can't separate design fro either architecture or implementation. If design is the activity that gives structure to the solution, and if architecture is about structure, isn't "design" a good term for the activity that produces it? And much of the code is about structure as well. Why shouldn't that be "design" as well? If you look at how real programmers work, you'll find they really don't delineate architecture, design, and implementation in most application domains, regardless of whether the official house method says they should or not. (How many times have you completed the coding before holding the review for your design document?) Object-oriented designers gain insight into the allocation of responsibilities to classes by coding them up. Empirical research on the software design process reveals that most developers have at least partially coded solutions in hand at the time of their design review and thus design decisions continue into the last throes of coding [Cain+1996].