For a software engineer most tools are pretty obvious. For instance a compiler, an editor, or a test framework (e.g. csUnit, JUnit, etc.), etc. But then there are other tools that are less obvious. What about the index card that you use for writing your story? What about the cards you use for planning poker (TM)? They are all tools in a wider sense.
An agile project leader has tools as well. Again some are more obvious like a reporting tool that gives him/her the latest financials for his/her projects. But there are others such as if you detect that a group of people is not on the same page in terms of information sharing. Then your tool of choice might be to get these people into one room and get them talking. Communication and collaboration are agile principles and so getting people to do both of this is a tool that an agile project leader has at his/her disposal.
It is important to use a broader definition of the term "tools". If you do you will discover many more tools you are using. Experiment with them. Try out new ones. Drop the ones that don't work for you. Listen to your team members. Often they have the best ideas anyways. Don't put tools away completely that didn't work at some stage as maybe at a later stage their time might actually have come.
Equally important is to look for tools that are simple and easy to use. Keep them as simple as you can get them. No need for an elaborate version control system if you can get away with a simple one like CVS or Subversion which have essentially little more features beyond update, commit, label, or branch.
Simple and small tools are much more flexible. They are easier to learn. They are easier to integrate with your existing environment. They tend to be easier to operate. And you can combine them forming more powerful solutions. If you select a good set of light weight yet efficient tools you can almost use them like Lego (tm) blocks to build the environment you need. And still you stay flexible and can adapt as needed by recombining or reconfiguring your toolset.
An Example
As an example for a simple yet efficient tool let's look at how you evaluate the engineers on your team. Many options exist. In large companies I have found systems (probably running on expensive hardware) which the managers are supposed to use for their evaluations. But there are simpler options. First of all, are you as the manager in the best (or only?) position to evaluate your team? What if you would delegate that task to your team and perform a peer review? What if you could use a simple tool to do that, e.g. a spread sheet that you send to all your engineers to evaluate each other?
You can find such a tool for free here. And here are a few things you can try out:
- Before you send out the actual sheet ask you team to review the categories or the descriptions of them.
- Try out different cycles, e.g. once a year, at the end of each project, every three months, etc.
- Try to expand it to non-engineering roles
- Ask people to also fill in the column with their own name. Is there a big difference between their self-perception and how they are seen by the team?
I'm sure you can find more factors to play with. Let me know how it goes and whether you find this type of tool useful. And always remember:
"A fool with a tool is still a fool." (anonymous)
So always THINK before you start using a tool.
And finally: The agile community would love to hear about your experiences. So I'd like to invite you to participate in the tools stage at the Agile 2008 conference.
