Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Tips for being more Agile (continued)

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)


  • 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…

Share This