Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / operating-systems / Windows

Agile Project Management Tools

5.00/5 (1 vote)
19 Feb 2011CPOL4 min read 20.4K  
Agile Project Management Tools

the-difference-between-waterfall-iterative-waterfall-scrum-and-lean

Fig: Evolution of commonly known software development models

Recently, in one of the Project Management conferences, I was asked "which agile management tool would you recommend?". As per Wiki, Agile Project Management is an iterative method of determining Requirements for Software and for delivering projects in a highly flexible and interactive manner. It requires empowered individuals from the relevant business, with supplier and customer input. Agile methods are becoming increasingly popular among software companies today. Agile methods have proven the best way to develop various software projects with accelerated software development. Increased productivity, reduction of off-shore risks due to customer collaboration and ability to absorb changes in requirements are only some of the important benefits of using agile methods. SCRUM is one of the several software methods derived from Agile Management. SCRUM is all about direct communication and fast, creative decision and control. Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. More information on Kanban in the upcoming posts.

Well, the answer depends upon size, complexity, team location and budget of the company/organization. For each project type, or business environment we need to adapt or choose the tool that best fits our needs. I think the best tool encompasses different tools, for example white board, a software and a couple of templates, or even more. It is important to take into account who is going to use the tool, who is going to provide the data, who is going to use this information to take decisions during the project lifecycle. Acquiring an Agile program management tool should be a team and management’s choice which is projected to add value.

For Local Teams

We used physical boards, because they are visible in the office and promote interaction between team members. And besides a whiteboard which holds current Sprint Data, all you need is a spreadsheet for storing all Scrum data.

Tools

We used physical boards and Excel sheets for about 1.5 years, and then transitioned to JIRA with GreenHopper (as we became a large and distributed development team) which we’ve now been using for about a year. It takes a little getting used to having everything in an electronic format, but it's flexible and gives you a board in a browser which mimics the physical one you’re used to and the ability to collaborate with dispersed teams. It allowed us to build up an extremely integrated tool chain with JIRA as central platform and customized Dashboard for the different stakeholders. One key advantage is that JIRA is quite flexible and can be used in different areas in an organization. We’ve implemented JIRA for Scrum, Incident Management, Issues Management, Time Management, Action List tracking in meetings, and so on. We’ve integrated Version Control, Code Review, Continuous Integration, Automated Testing, etc. It allowed us a very high level of transparency in different processes.

Summary

In summary, the needs should dictate the solution, and one should understand the true need before choosing the tool solution. One person’s amazing tool is another’s waste of bytes. This is SCRUM, and should not be overly elaborate or complicated, it’s towards the far end of the Agile spectrum, i.e., more adaptive rather than prescriptive. But saying that, JIRA plus GreenHopper gets a tick from me! Jira’s flexibility has allowed our different teams to create a planning and story boards that meet each sprint team’s unique requirements. The tool has provided an effective way to manage stories in both co-located and distributed (global) team scenarios. Projecting our digital story boards has allowed transparency throughout teams and across the organization.

Thinking Bottom-up

Sometimes, the "recommended agile tool" depends on the management view and attitude of the people using it, as opposed to size, complexity or budget of the project. Sure, there are some basic principles that we need to adhere to, but you should consider the abilities of your people, their ability to communicate, their capability to make decisions, and then on that basis choose a tool that helps them achieve amazing results.

“Leaders aren’t born, they are made. And they are made just like anything else, through hard work. And that’s the price we’ll have to pay to achieve that goal, or any goal.”


Filed under: CodeProject, Software Development Process

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)