Agile Project Management (APM) is an iterative approach to planning and guiding project processes.
Just as in Agile Software Development, an Agile project is completed in small sections. These sections are called iterations. In Agile Software Development, for instance, an iteration refers to a single development cycle. Each section or iteration is reviewed and critiqued by the project team, which should include representatives of the project's various stakeholders. Insights gained from the critique of an iteration are used to determine what the next step should be in the project.
The main benefit of Agile Project Management is its ability to respond to issues as they arise throughout the course of the project. Making a necessary change to a project at the right time can save resources and, ultimately, help deliver a successful project on time and within budget.Content Continues Below
What is APM?
Agile project methodology breaks down projects into small pieces that are completed in work sessions that run from the design phase to testing and quality assurance (QA). These sessions are often called sprints, the term for iteration used in one specific and popular Agile development method known as Scrum.
Sprints are generally short, running over days or weeks; they're typically two to four weeks long.
The Agile methodology enables teams to release segments as they're completed. This continuous release schedule allows for teams to demonstrate that these segments are successful and, if not, to fix flaws quickly. The belief is that this helps reduce the chance of large-scale failures, because there is continuous improvement throughout the project lifecycle.
How APM works
Agile teams build rapid feedback, continuous adaptation and QA best practices into their iterations.
They adopt practices such as continuous deployment (CD) and continuous integration (CI), using technology that automates steps to speed up the release and use of products.
Additionally, Agile Project Management calls for teams to continuously evaluate time and cost as they move through their work. They use velocity, burndown and burnup charts to measure their work, instead of Gantt charts and project milestones to track progress.
Agile Project Management does not require the presence or participation of a project manager. Although a project manager is essential for success under the traditional project-delivery methodologies, such as the waterfall model (where the position manages the budget, personnel, project scope, quality, requirements and other key elements), the project manager's role under APM is distributed among team members.
Learn how an Agile project can effect an entire business.
For instance, project goals are set by the product owner, while team members divvy up scheduling, progress reporting and quality tasks. Certain Agile approaches add other layers of management; the Scrum approach, for example, calls for a scrum master who helps set priorities and shepherd the project through to completion.
However, project managers are not obsolete in Agile Project Management. Many organizations still use them for Agile projects -- particularly larger, more complex ones -- but the organizations generally place these project managers in more of a coordinator role with the product owner taking responsibility for the project's overall completion.
Given the shift in work from project managers to Agile teams, Agile Project Management demands that team members know how to work in this new fashion. They must be able to collaborate with each other, as well as with users. They must to be able to communicate well to keep projects on track. And they should feel empowered to take appropriate actions at the right times in order to keep pace with delivery schedules.
History of APM
The 21st century saw a rapid rise in use of the Agile Project Management methodology, particularly for software development projects and otherIT initiatives.
However, the concept of continuous development dates back to the mid-20th century and has taken various forms and been championed by different leaders over the decades. For example, there was James Martin's Rapid Iterative Production Prototyping (RIPP), an approach that served as the premise for the 1991 book Rapid Application Development and the approach of the same name, RAD.
A specific Agile Project Management framework that has evolved in more recent years is Scrum. This methodology features a product owner who works with a development team to create a product backlog, a prioritized list of the features, functionalities and fixes required to deliver a successful software system. The team then delivers the pieces in rapid increments.
APM vs. waterfall
Agile Project Management was, and remains, a counter to the waterfall methodology. The waterfall methodology features a strict sequential approach to projects, where initiatives start with gathering all requirements before the work begins, scoping out the resources needed, establishing budgets and timelines, performing the actual work, testing and then delivering the project as a whole when all the work is completed.
In response to what were recognized problems in that approach, 17 software developers in 2001 published the Agile Manifesto outlining 12 principles of Agile Software Development. The principles include to "welcome changing requirements, even late in the development" and "deliver working software frequently."
These principles continue to guide Agile Project Management even today.
Pros and cons
Proponents of Agile Project Management say the methodology delivers numerous benefits. Those include the rapid deployment of solutions, more efficient use of resources, greater flexibility and adaptability to changing needs, more rapid detection of problems -- and thus quicker fixes -- and increased collaboration with users and, therefore, products that better meet user needs.
There are also potential drawbacks, however, including a tendency for projects to go off track, a lack of documentation and less predictable outcomes.
Because Agile management relies on the ability to make decisions quickly, it is not suitable for organizations that tend to deliberate over issues for a prolonged period or for those that take decisions to a committee.