Jeff Langr wrote about the importance of pair programming, which I’ve already discussed before.

However, one important issue he raises is what to do on non-paired time. The tasks he outlines are very important for any agile project as they definitely will increase your overall velocity.

His list:

• work on any non-production code: the acceptance test framework, other tools, build scripts, etc. In most shops, these are in dire need of attention.
• work on documentation
• work on spikes for future stories
• learn how to use a new third-party product; learn a new coding technique; and so on
• identify problem spots in the production code that need refactoring
• refactor tests
• improve the existing test coverage if necessary

I would augment “learning to use a new third-party product” to be “learning to use the software development tools at your disposal”. How much extra effort are you expending because you don’t use a document versioning tool in your workflow, or you aren’t using a source-level debugger, or don’t fully know the features and commandset of the debugger or text editor you use? How many possible bugs would you catch if you enabled certain warnings on compiles, or used a test coverage analyzer or performance profiler (e.g., gcov and gprof respectively)?

Here’s a great quote from Mike Ash:

“not knowing how to use the right tool is not a good reason to use the wrong tool”
— mikeash

Tools are probably already available for the things you need to do, so stop reinventing the wheel. After all, others have been writing software for over sixty years. What workflow-related (or even non-workflow) speedbumps could you eliminate if you just took the time to internalize a better mastery of your workflow?

How much more agile can you be if you spend a little effort improving your process?