Kiva Engineering: Tools of the Agile Trade
At Kiva, our development process is based on Scrum - with work broken into two week Sprints (we call them "Iterations"). We're good students of Scrum in some regards (we do release every two weeks, without fail), and bad students of Scrum in others (it seems like we still bite off more than we can chew in each iteration). Like most Scrum teams, the center of our universe is our ticket tracking system. We use Redmine - albeit a rather customized version. We've put quite a bit of time and effort into our ticket tracking system - so we thought we'd give you a tour.
Redmine Home Page - Dashboard
One of the biggest lessons I've learned as both a web developer, and an engineering manager is that everybody is fundamentally lazy. Users are lazy, and guess what... engineers are lazy too. If you want somebody to do something many times a day - you have to make it really easy to do. If you want somebody to truly internalize a message - you need to deliver it as often as possible. Hence, each engineer's Redmine home page is a customized one-stop shop. The left hand column shows a list of tasks - divided according to which code branch the task needs to be performed in. We typically have three branches going at a time - one out in real world, one in QA and one in active development. The right hand side shows three burndown charts. One for the entire engineering team, one for each of our sprint teams (we have four), and one for you, individually. The burndown charts show the burndown for the "most relevant" code branch at any particular phase in a Sprint. (Note - the burndown charts are done with High Charts. Try it, it's great. )
For the burndown addicted, we also have a page where you can view the burndown charts for all active branches at once.
To check out what each individual on a particular sprint team is up to, we have some bar charts that show a point distribution. The bars are stacked - purple for points that are assigned, grey for points that have been completed.
One of most recent, and most effective tools is our SVN-Redmine integration. We built a simple SVN post-commit hook that takes information from our SVN commit messages, and then updates the relevant Redmine ticket accordingly. The Redmine ticket is updated with the SVN comment, as well as the list of files changed, and a link to view each diff using webSVN. This feature is particularly handy for reviewing production patches, making it trivial to make sure that everybody knows exactly what was changed to fix Bug #11214.
In a feature-driven engineering environment, everything always feels like a rush. It can be hard to stop and take the time to build a feature for yourself, rather than your customers. (It took us a year of procrastination to build both burndown charts and our SVN integration.) With the advantage of hindsight though, I've never felt that it was time ill spent - in fact, my experience has been quite the opposite - the amount of productivity gained using a new "engineering tool" always seems to outweigh the cost of building it.