Kent Beck gave a great 'story-driven' talk at RailsConf 2008 regarding Patterns, Test Driven Development, and XP/Agile/Responsible development. Go see it now at Blip.tv along with all the other big presentations from RailsConf.

Yeah, yeah. This was posted ages ago, but I just made it around to watching it tonight.

Two great quotes. First, re: TDD

Testing really isn't the point. The point here is about responsibility. When you say it's done, is it done. Can you go to sleep at night, do you know that the software you finished today . . . works. And will help. And isn't going to take anything away from people.

Second, more generally about ideas:

Smart ideas are useless. Nobody else is going to be dumb enough not to try them - or rather, Everybody's going to try them if it's a smart idea. Ideas with punch are the ones that are really ridiculous...until you try them.

Like Mole. Mole sauce. Chocolate? Chicken? Phbbblblltt! HahahaHA!

I posted a few weeks ago gathering small tips from you regarding how you get and/or stay more Agile.

The goal is a list of short, pithy, sticky aphorisms to help both newbies get Agile and us stay that way. Think Agile Andy's Almanack (or something).

I've thrown everything I got (a lot in person & email) together and categorized a bit. Please comment, add, delete, etc. As I said, I'm working on a presentation around this data and welcome your feedback.

Here goes:

Stick to Conventions

• Follow the local ground rules (indenting, naming, structure, etc.)
• Always take the next story (don't let 'fun' or 'hard' get in the way of business priority)

Use the right tools

• Keep your hand on the manual (Keep browser tabs open for your language & API doc sites)
• Make mini actionable task lists for your story (Get inspired by GTD)
• Index cards are mini whiteboards
• Hardware, hardware, hardware (Big and/or dual monitors, 2 keyboards & 2 mice is better than 1 & 1)

Pair Programming Works

• Expect to Pair
• Pair appropriately
  • When you're not sure how to implement a story, pair with someone more senior
  • When a task feels obvious, pair with someone more junior or new to the project
• Let the rookie type, give the wookie a toy (so he doesn't)
• Rotate your pairs as often as practical
• 2 pairs are better than 1 on a project
• Always pair interview

Take a test drive

• Writers' block? BEWS (Blank Editor Window Syndrome)? Write a test
• Find some untested code? Write a test.
• Find something you don't understand? Write a test.
• Keep your tests as fast as is practical, or you'll wait for CI to run them
• Write enough tests so that you can sleep at night

Code simply

• Do the simplest thing that could possibly work - no architecture astronauts
• Check-in multiple times before a story is done (try for every hour or so)
• Kill dead code, commented out code, or write tests to cover it
• Make it green, then make it clean
• Tackle code debt with extreme prejudice
• Leave the code cleaner than when you got there (think o2 canisters on Everest)

CI

• Every failing test is sacred
• Red builds are project cancer - fix first, figure out why, then blame (when appropriate)

Stay in sync

• Don't stop talking - to your pair, your team or your customer
• Go to lunch together

Comment away...