Tips for being more Agile (continued)

September 3, 2008 Davis W. Frank

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…

About the Author

Biography

More Content by Davis W. Frank
Previous
Enabling the Postfix Mail Daemon on Leopard
Enabling the Postfix Mail Daemon on Leopard

If you want to send SMTP mail via localhost on Mac OSX Leopard (for example, from ActiveRecord/Rails/Cruise...

Next
NYC Ruby Happy Hour at Outside.In
NYC Ruby Happy Hour at Outside.In

Pivotal Labs is teaming up with Outside.In in New York City to co-host the monthly Ruby Happy Hour, on the ...

Enter curious. Exit smarter.

Register Now