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

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Open Thread: Which Practices Make You More Agile?

I’ve been passionate about Extreme Programming and Agile Software Development Practices since first hearing Kent Beck speak back in 2002. But it took five years, and finding a job where I was expected by management to be Agile every day (TDD, paring, etc.), before I was able to actually call myself an Agile Engineer.

I’m sure that there are more of you out there who want to be more Agile. And you want more Agile engineers so that you’ll have reasonable people to work with and learn from.

In the past 18 months I’ve picked up a lot of effective small practices that you won’t find in the White Book. Things like making sure you pick the next story no matter your comfort level. Or fixing a red CI build ASAP.

In order to spread the knowledge, I’m working on a presentation about the ‘practices that work’ to share with potential Agile Engineers at a future software conference near you.

So what day-to-day practices make you more Agile?

  • One thing that can’t be said enough is to pick up the phone. I have frequently seen developers, solo or while pairing, wondering out loud about a particular feature. The shortest path between your question and a reliable answer is the telephone. Those few minutes spent on the phone will greatly improve your velocity, and improve the likelihood that the feature is built right. Certainly face-to-face communication would be preferred, but I’ve (unfortunately) never been lucky enough to be in that situation with my business partners.

    I’d also recommend constantly rotating pairings. It’s so easy to get in a comfort zone of pairing with the same people. This leads to a few bad things. Team dynamics are thrown off, pairing becomes less intensive, and cliques emerge. Additionally this can lead to a grouping of developers that are more familiar with a certain area of the app. This is always trouble. Each team member should be able to pick up a story in any part of the application. While you may be less proficient at first with this approach, it will pay off in time.

    Another tip that may pay off more for Java and the like:
    Write code documentation for a human to read, not just for a tool to parse. Javadoc can be very hard to parse if it’s written “correctly”. If you have something quick to say about a method, it is typically better to aim for easy readability vs. formatting for a tool.

  • Chad Woolley


    I totally agree with your first two points, and every team should constantly remind themselves of them (they came up in my team’s last retrospective, as a matter of fact).

    On your third point, I’m just glad I rarely do Java anymore :)

    — Chad

  • dwfrank

    Thanks @Brian & @Chad!

    I especially like rotating pairs. Good one.

    I’m really looking for things that condense well, sort of Poor Richard’s Almanac aphorisms. So how about this: “Pairs and fish stink in 2 days”

    Anyone else?

  • Distilling my points a bit, ala Poor Richard’s:

    – Don’t pull the trigger until you can hear the sound of their voice.
    – Side-out rotate! (volleyball anyone?)
    – Write to be read

    The latter one tends to be said when describing good writing. There are lots of longer anecdotes to this point, like Matz “Treating Code as an Essay”, and other words we used to describe this perspective (terse, clear, concise, descriptive, etc.). These terms however can be very subjective. Writing code to be read means thinking about your audience. Your team or the team that will take over the project, etc.

    If you heard Kent Beck’s talk at RailsConf (not sure if there is a video anywhere), he talked about using the term “Responsible Development” as a more intent-oriented term to describe what we’ve been calling Agile (or XP). I’d love to see that term used a bit more, to remind us all why we strive to be “agile”.

Share This