Agile Development Tips, by David W. Frank

I watched the talk from David W. Frank (from Pivotal Labs) at RailsConf. It was interesting to listen to advice on agile software development, although on some I would disagree. Here are my highlights and some thoughts afterwards.

Stick to conventions

  • follow the ground rules
  • be a lord of discipline
  • pop goes the story stack (pick the very first task on top)

Stay in sync

  • cubicules kill
  • go to lunch as a team
  • keep up the jibber jabber (talking while working)

Tools Matter

  • rtfw (or be quick to google it)
  • get stories done
  • this is a whiteboard
  • don’t forget the hardware


  • live together, die alone
  • let the rookie type
  • pairs stink after 2 days
  • two pairs are better than one

Test Drive

  • beat the blews
  • tests, not comments
  • ping pong isn’t just table tennis

Check Your Dashboard

  • every failing test is sacred
  • fix first, ask questions later
  • slow suites are project heart disease

Work Simply

  • architecture is a 4-letter word (‘test’)
  • make it green, then clean it
  • check-in early and often
  • kill dead code dead

My thoughts

  • pop goes the story stack

Code ownership is generally a bad idea, but in reality you have deadlines, i.e. time is a constraint. If you need to be effective, some tasks will be done much quickly if done by certain team members (it might not be yourself). You shouldn’t refuse a task because it’s a boring chore (pleonasm intended), you should refuse a task if you feel it would take you substantially more time than if it would be done by another team member.

  • go to lunch as a team

But not all the time. Maybe 25% of the time? Lunch is a very important break during the day, and it can be relaxing (sometimes needed) to have lunch with some people outside of your team.

  • keep up the jibber-jabber

Nah. Totally not. Go for open spaces, but no to the jibber-jabber. You need to interrupt another team member when you really can’t deal with the issue yourself. That’s why a chatting channel (e.g. campfire) is useful. People will go read it whenever they feel like it, instead of being interrupted in the middle of something.

  • tests, not comments

Absolutely, yeah. Comments are code pollution, very often. If you feel you need to write a comment, it probably means you need to extract that code into a new method or rename a method/class names.



  1. All of my points were mean to be guidelines, not rules. I don’t do the lunch thing all of the time.

    The “jibber-jabber” meme is mostly meant for intra-pair communication. Don’t stop talking to your pair. As for cross-team or inter-pair communication, I find IM/Campfire/Skype chat more distracting than useful.

  2. ps: unless you’re dealing with cross-site teams, in which case it’s invaluable, but it has a cost to your flow.

Got a comment?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: