Project Tracking Tools in Agile

This is a big question that most of us come across once we start dealing with "How to Implement Agile". Do we really need tools that are made for Agile? Is it about the principles or is it about the tools?

First off, Agile practices emphasize more on "Getting the work done" over "Following Process" - so it looks like no tool is required for the task management and whiteboard and story cards kind of approach is good enough.

On the other hand, you need to answer very basic questions at any given point of time, to anyone from any location.
- How many tasks (Backlog) are pending?
- Who is working on what?
- How many bugs need to fixed?
- What are the tasks being worked for this iteration?

Assume these questions are being asked from a project stakeholder from a different site; we can't show him the Task Whiteboard or send a snapshot of that on a daily basis. It is impractical.

So, maintaining the balance - "Not deviating from the Agile principles" and at the same time "Respecting the interests of all the stake holders including the execution team" - we need a tool which has a simple "search", "categorization" and "prioritization" capabilities.

Here is an example of what we used to do for project tracking purposes:

-- Someone from the team used to make a TODO list from our daily meetings or Sprint meetings. He need not be the Scrum Master and we actually rotated this job among the team members.

-- Rotating this job also helped in creating more "participation" and "sense of ownership" among the team and the team used to get more understanding of tasks beyond their ownership.

-- After the meeting, the person who made the TODO list, would create Tasks and Bugs on a Bug Management tool (We used Bugzilla). Tasks are the new development (Bugzilla has support for Tasks) work. The Tasks and Bugs on Bugzilla looked like this.
-----------[Task] [Login][Implement Basic Login]
-----------[Task] [Login][Implement Forgot Password]
-----------[P1] [Registration][Fix UserId validations]
-----------[P2] [...][............................]
[You may think of other practices like using user-derived standard prefixes for a bug's subject line, use of Keywords etc. for categorizing the work based on Functionality or Iteration basis. The idea is to find out what is already available and how you can make use of that to fit in your requirement.]

-- This would not take more than a few minutes and the SCRUM master (or the Project Manager, whatever the title is) also used to sit with the engineer who is creating the task to guide them better and it also used to help them as "undocumented" mentoring process.

-- We used to assign a default priority P5 for all the Bugs (including tasks) and assign P1 for the Tasks/Bugs for this iteration. Also, P2 priority was used for those tasks/bugs that were planned to be handled in the current iteration but could be pushed to the next iteration should the time did not permit. This was for handling the priority within the iterations.

-- This helped everyone being in sync with the task management. Also, there used to be minimal duplication of work - like using some tool for the Project Management and some other tool for the Bug Management and manually transferring information from one to another.

-- Even for the project stake holders from different sites as well, they can simply run the "Saved Queries" to get the information they need. Remember you need to have different "Saved Queries" to serve the purpose of different stake holders and it is one time job. Some of the "Saved Queries" that I can list from the top of my head:

--- Tasks/Bugs for the Current Iteration

--- Tasks/Bugs for the Previous Iterations (Copy & Paste job with the Iteration name being the variable)

--- PENDING: Backlog (Same as above but no Iteration tag/keyword assigned)

--- DONE: Overall Tasks/Bugs already closed

--- OPEN: Tasks/Bugs being worked on

--- <Any other queries that we used on a routine basis would go here>

-- The same queries were used even on the project Wiki pages as pointers.

-- It also helped any quick review meetings at any time and from any place.

-- Beyond that it worked as a good engineering practice to integrate SCM tool (for Bug Reviews and Tracking Regressions etc.) as well because you are tying up a Bug Number. (We integrated Bugzilla with SCM).

This was a "good enough" and "a derived" approach for us with the Questions we needed to answer in the project management. Again, this was the solution that worked for the requirements we had and mention of Bugzilla here is just to state an example. What we need to take into account is - thinking beyond the bookish approach and having a simple process in place to answer the basic Task Management requirements for "serving the individual stakeholder requirements" and at the same time "ensuring the sustained development".

"No Process" and "Over Process" both are equally dangerous. Improvising your processes does not mean doing everything new and deploying new tools.

Have you charted down your project tracking requirements (what exactly you want) before zeroing down on any tool?

Has your team been involved in evaluating the project tracking requirements? Are you ensuring that the 'team collaboration' principle is used in developing the project tracking process OR reviewing the existing process whatever the case maybe?

Have you evaluated if the existing in-house tools can be tailored to meet your requirements before investing your time and money on a wholesale new tool?

Is your project tracking tool or methodology adding to the "Simplicity" principle of Agile than adding more "Complexity"?

Overall, Are you inviting the feedback of the team to ensure this process also evolves better (iteration by iteration) as you progress? (Just like we talk BIG about evolutionary requirements and evolutionary design)

"Simplicity of Agile should not be lost in the complexity of Tools"


(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)