Everything about an Agile Development Team (ADT) should be agile. They should always have tasks on hand for the team to work on. They should always be iterating their processes, methodologies and practices to optimize their efforts. They should always have the right tools at the right time and in the right configuration to support them.
When we think about the “velocity” of the application delivery process it is clear that some tools are essential to maintaining the speed and direction of the ADT. These tools fall into three broad categories: development, organization and automation.
Development tools. The Integrated Development Environment (IDE) tools that support a developer are commoditized these days. According to Eclipse Foundation research more than 90% of all IDE’s in use can be accounted for between Eclipse (and Eclipse-based IDE’s) and Microsoft Visual Studio. The choice of IDE is usually a practical one based on language and target platform but is also often a personal favorite one. Whichever it is, the choice of IDE is important for the ADT. It needs to be an IDE that can have features like task lists, versioning, visual representations of branching and merging and collaboration capabilities integrated into the fabric of the tool. This means that developers can stay in their IDE for most of their work and handoffs can be automated through the IDE.
Organization tools. Without doubt the most important tools for any ADT are the tools that manage the team. And to be clear here, when I talk about organization tools I am not necessarily talking about software tools. It is perfectly acceptable, actually often desirable, to stick with the whiteboard, Post-It Notes and magnetic arrows. The essential aspect of an ADT is the self-organizing principle: this allows the team to throttle the amount of work they do and self-select the tasks. Keeping track of this is essential but auditing it less so. So when it comes to organization tools we should look for the ones that are easy to use and flexible to the process, easy to modify and highly visual. If the ADT is not co-located collaboration tools are critical. These can be as simple as online chat or as sophisticated as those that detect presence and activity.
Automation tools. Perhaps the worst legacy of the development processes we have evolved over the past 60 years are the many manual steps and the duplication of effort in our development practices. When creating an ADT it is the perfect opportunity to get the development infrastructure right. We should not have developers writing scripts for builds when there are outstanding commercial and open source build tools. We should not be manually copying artifacts from development to testing to staging to packaging to production but should be using automated tools that come with approvals and notifications. We should not be testing “by hand” but using all the tools at our disposal so that every change is exercised against the battery of predefined and growing tests and this should be done by the developers.
A small team will become a big team. Getting the basic infrastructure of the development organization right to begin with will pay dividends as the team grows.
Originally authored for SearchSoftwareQuality magazine.
BizTechFuturist 
A few observations from experience….
i) Small teams leading to big teams is not always a good idea. Small teams morph into sub groups when the developer count gets as far as 10 or 12 developers.
ii) Regardless of what language I’m developing I use Eclipse, until it comes to iPhone development then I’m forced down the XCode route. The learning curve switching between the two will cost you dearly to start off with but will decrease over time.
iii) Use Ant or Maven as build tools, like IDE’s they are personal preference. I’ve used Ant for years and still do for deploying dev/test/live integrations.
iv) I’ve been using Pivotal Tracker for project velocities but you have to keep on top of these things otherwise the velocities are meaningless.
v) For first stage planning post-it notes and bits of string works well for me. Also remember that once you hit over 40 man hours a week the risk of errors in code will increase dramatically. I’d rather have a small team who’ve slept well than a large team who are all knackered.
Its a great explanation about ALM tools and Automation tools,I get some knowledge about that,please more details send to your link.if u think refer about software testing and QTP in Automation and Tools to see qtp book qtp book that would made yours a complete one.