The Tools Don’t Make You Agile

One of the most common questions our team is asked is, “Which project management tool is best for us?”


The answer is that it depends…

…It depends on what software your team already uses and is comfortable with.

…It depends on what sort of tools your team already uses that you may want to have integrations with.

…It depends on how your team prefers to look at data related to your work and use that data to help make decisions.


There is no one Agile project management tool that is perfect for all teams. 


It is why our team says we are tool agnostic. 


In fact, if you listen to the different speakers at our Agile in Nonprofits Online Summit each year (you can watch as many of the past 10-minute clips here as you want), you will hear about a wide range of tools that are utilized by these awesome nonprofit professionals and their teams in their unique application of Agile methodologies. 


And because we are tool agnostic, our Marketing & Training Product Owner, Megan Martin, has produced numerous short clips featuring different tools for our YouTube channel and also created a blog highlighting the different nonprofit discounts/free licenses you may be able to access for different tools.


What our team cares more about than what tool you use is that you don’t let the tool drive your actions as a team. It is important to remember that the tools don’t make you Agile. YOU make your team Agile. The tools are there to help make your Agile way of working visible across the team and to other key members of the organization.



Don’t let the different priority flags or the different ways to save a sorted view of your work drive the way that your team thinks about the prioritization of the work. Think about one view in a tool as a flat 2D model of the work. For the visualization of your work to be as meaningful as possible, mix it up – use different views and sorts to ensure that your perspective of your work is 3D and understood by all on the team.


One of our teams recently had a realization that they had become so dependent on a particular sorted view of their work that what they were often unintentionally doing was ignoring the Product Owner’s prioritization set in the Team Backlog (the overall entire backlog for the team’s upcoming work). That sort only made sense to use continuously in their Sprint Backlog, where the *team* is the one to order the work using their own expertise to decide the best approach to the committed work.


What have you learned in trying different Agile project management tools and their features that helped you realize that the tools don’t make you Agile?


We’d love to hear in the comments below!