In our efforts to help teams adopt agile practices to solve enterprise problems, we have found the most common request we get from our partners is for tools to help make their job easier.  This situation poses an interesting challenge to the agile practitioner, as typically the most effective agile tools for the individual have been those that emphasize face-to-face communication and are generally 'low-tech' in order to remain malleable.  

Some of the agile tools that have been adopted as natural extensions of this philosophy have been tools such as index cards, spreadsheets, and wikis.  What these tools have in common is that they are all 'flexible'. What each one of these tools varies in is the degree of collaboration that they provide to an agile team. For example, an agile team co-located in one room may find that a stack of index cards and a magic marker are the only tools that they need, whereas a distributed development team might want to use tools that enable them to more quickly share ideas with colleagues overseas.

We typically arrive on a client site with a kit that contains both low and high-tech tools to support the interactions that we are trying to promote.

In our experience, most teams practicing agile methodologies use:

• Information radiators to share important indicators of progress.
• Index cards of different colors to represent user stories, tasks, defects, risks and issues - usually tracked on a large 'story board'.
• Sticky notes to tag cards with special context.
• Wikis to collaborate on documents with remote colleagues.
• Software to facilitate the writing of automated unit tests.
• Advanced integrated development environments to allow refactoring of code with impunity.
• Continuous integration servers to regularly integrate changes to the software being developed.

In addition, there are some other tools that the most effective agile teams employ. Albeit these are less tangible:

• A policy of openness with information.
• The expectation that processes will change regularly.
• The notion that whatever is being worked on is the most important thing.
• Trust between team members.

The former sets of tools are very powerful in terms of improving team productivity on an everyday basis. The latter are part of what distinguish high-performance teams from everyday software development organizations.  

Unfortunately, the market has not been served well by tools that facilitate the kind of interactions that high performance teams need to be successful. Most tools on the market are either focused on one of two things:  project management or information sharing.  Project management tools employ a top-down approach because their main constituency is the management who wants accurate data about how their teams are doing in terms of progress. This approach, while of good intent, tends to alienate the very people on the team that do the work day-in and day-out.  Agile emphasizes the focus on the team as the driver of project decisions. Agile tools must have a bottom-up approach.

Pure information-sharing tools tend to allow team members to put volumes of information into a shared workspace without necessarily providing any proper sense of context.  They often allow users to create their own information architecture - however, this quickly loses its usefulness when that ontology no longer reflects the realities of the project.  Agile teams change their process regularly to make sure they are always maximizing their throughput. Agile tools must support ongoing flexibility in the way information is shared, categorized and manipulated.

With Mingle, we have strived to create the first agile collaboration tool that gives teams the flexibility that they need, while actually enhancing the ways in which the team can collaborate.  Teams can drive the structure of their project and change their process as needed. Stakeholders inside and outside the project can easily interact with, slice and dice the project information to meet their needs, all without imposing a rigid methodology on the team.  

We believe that agile teams should not be satisfied with the status quo. They should take the initiative to use the tools that best enable them to be most productive, collaborative and responsive to change.