If you search the web for "Agile tools," you'll get plenty of hits. If you search the agile discussion groups, you'll get plenty of people telling you agile is not about tools. The very first item in The Agile Manifesto is "Individuals and interactions over processes and tools."
So keep a proper perspective on tools. Tools, processes, techniques, etc., are potential solutions to potential problems. To be agile, you should be really good at detecting common problems, and have a variety of options you can suggest for dealing with those problems. But never confuse using agile tools with being agile.
"Individuals and interactions" says that the most critical element of any project is lots of clear interaction between client and developers, manager and developers, and developers with developers.
One of the most important tools for this communication is the backlog. The backlog enables the client to say what needs to be done and what's most important. The backlog enables the developers to see what they need to do next and to tell the client when something has been done.
A backlog should be a list of user stories, not coding tasks. But that's for another discussion.
There are a number of common ways teams in this class have implemented their backlogs. I list them below and some non-obvious observations. I leave the obvious advantages and disadvantages of each method as exercises for the reader.
- A list passed around in email
- Team members send an email when they start working on the top story on a list, another email when they finish it and remove it from the list, another when they add a story to the list.
- This works surprisingly often, no doubt because teams are the right size (three to five) and projects have a short duration.
- A Google spreadsheet
- Client and developers add and order user stories on a shared spreadsheet.
- Simple and usually the first option teams turn to.
- This fails surprisingly often in the following ways:
- Clients add a ton of items, with many labeled top priority
- Clients change the backlog without any conversation with the developers
- Clients ask the developers about the state of backlog rather than looking at the backlog
- Developers let the backlog go stale, so that it no longer reflects the current state of development
- These failures are perhaps because a spreadsheet offers plenty of room, doesn't force focus, and changes to the spreadsheet don't trigger communication, the way emails do
- Client and developers add and order user stories on a shared agile taskboard.
- Deliberately simple, customizable, valuable on your résumé
- The visual layout of Trello tends to reduce growth without bounds
- The failures I've sometimes seen are
- Clients changing the Trello board, because it's so easy to do, without conversation with the developers
- Clients and developers disagreeing on what the Done column means.
To fix this, I recommend teams
- Use four columns: To Do, Doing, Done?, and Done!
- Clients move items into the first column, To Do.
- Developers move items from To Do to Doing, and then to Done?
- Clients move items to Done! when they're satisfied.
- Pivotal Tracker
- A common choice of clients who have managed agile projects in their company
- Many features not found in Trello
- Most common failure: developers overwhelmed with the options and complexity
- My recommendation: use only if your clients insist, but see if they're OK with Trello instead
- Issue trackers like Github Issues or Jira
- These are designed for developers and intimidating for clients, IMO.
The second item in the Agile Manifesto is "Working software over comprehensive documentation." The key word here of course is "working."
Personally, I don't believe any team's claim to have working software if they don't have a large number of automated tests that is run on every new build.
To get the automated tests, you need to use a mature unit testing framework. Every language comes with a number of these. See Testing: The Technical Bits for details.
To reliably run them on every build, you need a continuous integration server. Setting one up on your own machine can be a challenge, but fortunately more and more cloud-based CI servers are being created. There are some extensive lists at Wikipedia and Yodiz.