Practices Of An Agile Developer Review

At my boss' request, I read a book on Agile developer practices over the weekend. I then sent him a 'book review' of it, some of which I figured I'd post here for a wider audience. The book is Practices of an Agile Developer by Subramaniam and Hunt. It's written such that it's easy to read, has some good real-world anecdotes in it, and reflects reality for the most part, as I've experienced the Agile part of it so far. Much of what it had to say, I already knew; however, I'm not sure how much of it is understood - or followed - by the general masses at work, nor how much we're allowing them time to engage in presently.

Here's a part of what I sent the VP:

One of the best parts of each section is called Keeping Your Balance as it reflects on some of the ways you can go too far, or not far enough, in implementing each practice. You could almost read the book by just reading the first few sentences of each section and then the KYB notes at the end of it, although I read the whole thing.. ;-)

1) Beginning Agility:
Work For Outcome (focus on the goal, not blame, when things go wrong)
Quick Fixes Become Quicksand (the perils of implementing fixes when you don't understand what the code does)
Criticize Ideas, Not People (self-explanatory)
Damn The Torpedoes, Go Ahead! (have the courage to admit to mistakes and even start over)

2) Feeding Agility:
Keep Up With Change (learn enough about emerging technology and patterns to stay current, look for opportunities to use what you learn but don't shoehorn it in)
Invest In Your Team (the value of sharing knowledge through collaboration and Lunch 'n' Learns)
Know When To Unlearn (break out of old habits if they don't apply anymore)
Question Until You Understand (keep asking "Why?" until you get to the root of the problem rather than just assuming it's too complicated to get)
Feel The Rhythm (get into a rhythm as far as checking code in each day; figure out the Iteration length that works for you; find the right time for the Stand Up Mtg)

3) Delivering What The User Wants:
Let Customers Make Decisions (great advice that we're not in a good position to follow right now)
Let Design Guide, Not Dictate (have an upfront Strategic Design that provides a direction to follow, and then Tactical Designs along the way that are shorter-viewed but more specific, in keeping with taking many steps and learning at each one)
Justify Technology Use (don't pick a framework just because it's fashionable, don't be tied to an irreversible model)
Keep It Releasable (self-explanatory)
Integrate Early, Integrate Often (self-explanatory)
Automate Deployment Early (self-explanatory)
Get Frequent Feedback Using Demos (self-explanatory)
Use Short Iterations, Release In Increments (self-explanatory)
Fixed Prices Are Broken Promises (some good ideas on how to handle cases where the customers expect Waterfall, laminated plans months ahead of time.. nothing revelatory to me but still worth reading because of our situation; basically it advocates releasing something of high quality quickly so your customer sees the value of Iteration releases and eventually they'll stop expecting fixed price models)

4) Agile Feedback:
Put Angels On Your Shoulders (unit tests provide immediate feedback on the code you just wrote, keeping you honest)
Use It Before You Build It ("eat your own dog food"; use Test Driven Development so that you'll find the bugs before you're even done with the code; TDD will also lead you to cleaner design because you're now a user of your APIs, not just a provider)
Different Makes A Difference (test on all applicable platforms, machines, etc.)
Automate Acceptance Testing (assuming your customer somehow provided Acceptance Tests, automate them and run them all the time)
Measure Real Progress (monitor your estimates against reality so that you can get better at it)
Listen To Users (view what users tell you as input/feedback, not as distractions or noise)

5) Agile Coding:
Program Intently And Expressively (make sure your code is easy to understand)
Communicate In Code (comment whatever isn't obvious in the code itself; spend time on Javadocs)
Actively Evaluate Trade-Offs (keep the trade-off matrix in mind when making decisions, rather than blindly focusing on performance where it's not required, or saving $5000 on a piece of hardware while costing ten times that amount in coder productivity)
Code In Increments (chunking)
Keep It Simple (the value of simplicity over simplistic; reductionism)
Write Cohesive Code (don't have hybrid classes as the cost of maintaining them is the product of each feature's cost)
Tell, Don't Ask (use your OO language correctly: let objects modify themselves based on what you tell them, rather than being modified by other objects that use them)
Substitute By Contract (ensure any derived class can be substituted for its base class without the calling code knowing the difference; "require no more and promise no less" when extending classes, and understand the difference between is-a for inheritence and has-a or use-a for delegation.. hopefully they teach that in school??)

6) Agile Debugging:
Keep A Solutions Log (great but impractical idea where each coder keeps notes on problems as they fix them so they'll have the solution the next time)
Warnings Are Really Errors (self-explanatory)
Attack Problems In Isolation (divide and conquer/process of elimination approach; create prototypes outside your code to isolate where the problem's occuring)
Report All Exceptions, and Provide Useful Error Messages (don't hide exceptions; provide the right level of detail to the user when reporting errors; differentitate between unrecoverable errors, administrative errors, and user errors)

7) Agile Collaboration
Schedule Regular Face Time (stand ups, etc)
Architects Must Write Code (self-explanatory)
Practice Collective Ownership (self-explanatory)
Be A Mentor (self-explanatory)
Allow People To Figure It Out (know when to teach them to fish)
Share Code Only When Ready (don't check in code that you're not done with)
Review Code (self-explanatory, though some interesting historical stats on how helpful reviews are, when you consider how much improvement we've started making in this area)
Keep Others Informed (use Info Radiators, admit failure while there's still time to do something about it)