Agile project management isn’t new. What we know as agile project management really came to be defined in the 1990s as a reaction to the rigidly-planned, traditional approach to project management.
Software developers were tired of feeling micromanaged and started using new approaches, such as rapid application development, the unified process, dynamic systems development method, scrum and extreme programming. These approaches constituted a proto-agile framework and are now considered to fall under the larger definition of agile project management.
It wasn’t until the Manifesto for Agile Software Development was written in 2001 that this new framework got its name. And so that’s where we’ll start this ultimate guide to agile project management.
The Agile Manifesto and The 12 Principles of Agile
For a thorough definition of agile project management, let’s examine the Agile Manifesto, which was written by 17 software developers who believed they were “uncovering better ways of developing software by doing it and helping others do it.”
There are four core values outlined in the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
To help teams stay true to these core values, the group defined 12 principles for managing projects within an agile framework:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architectures, requirements and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is the baseline, and most agile project management proponents agree with this seed of agile understanding. However, as the process grows, so does the contention. The truth is that agile as a framework is not prescriptive. There is no rigid system to follow, like with traditional methodologies, such as waterfall project management. Agile is more of a philosophy of working.
Agile Project Management vs. Waterfall Project Management
As mentioned earlier, waterfall is a more traditional model to manage a project. It is also referred to as a linear sequential life cycle, which is a mouthful. What that means is that waterfall follows a specific order, one step follows the other, and that next step isn’t started until the previous one has been completed.
Agile project management, however, is all about flexibility and follows an incremental approach of continuous iterations. Agile projects always test throughout the development phase and are open to changes in requirements whenever they show up.
Pros of Using Waterfall Project Management
Waterfall and agile project management both have their pros and cons. One clear pro to using the waterfall methodology is that it’s straightforward. Each of its phases has a deliverable, which is reviewed before moving on. The template is easy to follow.
It’s a beneficial process for projects with easy-to-understand requirements and creates a faster delivery for projects of that nature. It’s also documented in great detail, which is helpful for future projects as well as keeping stakeholders in the loop.
Because waterfall is so structured, it makes it easy to onboard new teams as they come onto the project. Project managers also like it because it tends to work better at managing dependencies in their projects.
A Gantt chart is the typical project management tool that for waterfall projects and structured plans. Gantt charts break projects into milestones and smaller tasks, which, when start and end dates are added, populate a project timeline. Dependent tasks can be linked to avoid bottlenecks in production. As you can see, the timelines end up making a waterfall-like design.
Pros of Using Agile Project Management
While waterfall is focused on gathering requirements at the beginning of the project so a structured plan can be created, agile project management gathers client feedback throughout the project and welcomes changes. Agile believes in keeping clients constantly updated on what’s happening in the project. This makes for a happy client, especially since whatever they require for the project is implemented, even if that means pivoting.
The agile team by definition is a self-directed one. This gives them autonomy that other teams who use traditional methodologies don’t have. Autonomous teams are often more motivated and productive, as well as happier. Naturally, the project can benefit from this.
Quality is key in agile project management, and an agile framework focuses much attention on keeping the quality of the product as high as possible. This is done through incremental progress, which allows not only for issues that arise to be resolved and deliverables improved, but for teams and clients to stay on the same page. This reduces risk in development.
In an agile environment, where teams have more autonomy, visual workflow tools such as kanban boards are often used. When working in an agile framework like scrum, they break sprints into three columns: to do, doing and done (though column headings can be customized to fit any project). Tasks are indicated by cards that team members move from column to column as they work and complete the task. This provides transparency and keeps team members focused only on the task in their sprint.
ProjectManager.com has kanban boards as one of its multiple project views. They use a simple drag-and-drop interface, and as statuses are updated, that data is reflected across the entire software.
Cons of Using Waterfall
As for the disadvantages of using waterfall, it’s not well-suited to dynamic projects. It’s also a problem when the project’s requirements are not laid out well at the beginning. Then there’s the desire to go back to a phase, which is not part of the waterfall model. So, if there’s an issue in a previous phase that must be addressed, it can be difficult.
Another issue with waterfall is testing. The testing phase of the project is not started until development is over, in keeping with the structured steps of the methodology. When bugs show up, development is over, so having to fix those bugs can be expensive and time-consuming.
Cons of Using Agile Project Management
Agile project management isn’t perfect either. Agile project management practically requires an expert to help make important decisions that stay in line with the agile values. Therefore, without this expert, the project can suffer.
There is also the cost of using agile project management, which can be more expensive than other more traditional methodologies, such as waterfall. This is because so many changes can come up in a project, it’s hard to know exactly how much a project will cost. Also, because teams are self-directed, if they’re not given clear directions on what the outcomes need to be, the project can quickly find itself off track.
Projects are not black-and-white, however, and many are managed using a hybrid of more traditional methodologies like waterfall, which project managers and IT teams often prefer, and an agile framework, which is better suited for self-directed teams and developers.
ProjectManager.com has the best of both worlds, with Gantt charts for a more structured approach and kanban boards and collaborative tools to give team members the freedom to work more productively. There are task lists and calendars too, so everyone can find a way to be productive.
Typical Agile Frameworks
There are many ways to use an agile framework when solving problems or working on a project. Let’s look at a few of the more popular ways to practice agile project management.
Scrum is the most popular of all the software development methods. As an agile framework, scrum has actually been around longer than the term “agile.” Scrum was introduced in 1986 as part of an article on product development called the New New Product Development Game (that’s not a typo, the repetition is intentional).
Authors Hirotake Taskeuchi and Ikujiro Nonaka, claimed that this new product development would be faster and more flexible than what was currently being used. They said their ideas came from going through case studies of manufacturing firms.
Scrum developed into a formal process in 1995, and some of those people were also part of the group that came up with the Agile Manifesto in 2001.
But what is scrum? It’s a framework that teams who want to be agile can use to work on complex, adaptive problems. It helps with productivity and fosters creative solutions, while focusing on delivering projects with high value.
Scrum is a simple and effective framework for collaborative teams that are tasked with complicated projects. That said, while easy to understand, scrum can be difficult to master.
The Scrum Team
The scrum team is made up of a product owner, development team and scrum master. The product owner is responsible for managing the product backlog, which is a list of work, like a to-do list. The development team is made up of those people who are responsible for shepherding the deliverable to a done product. The scrum master is just that, a master of the scrum framework, who acts as guru and lodestar to make sure everyone is working correctly in the scrum framework.
Working in Sprints
Work in scrum is broken down into what are called ceremonies that limit the need for too many meetings. The scrum ceremonies include the sprint, sprint planning, daily scrum, sprint review and sprint retrospective.
The sprint is defined in the Scrum Guide as a “time-box” of one month or less in which a task is completed. The sprint planning event is as it sounds, the collaborative plan that the whole scrum team works on. Daily scrum is a short, usually no more than a 15-minute meeting at the end of the day, where the development team creates a plan forward for the next day.
After the sprint there is a sprint review, which is used to edit the product backlog as needed. Finally, a sprint retrospective is a way for the scrum team to address issues from the last sprint and create improvements for the next one.
All this is in service to the point of scrum, which is to get teams to work more productively together, like a sports team. Scrum got its name from rugby, scrum being short for scrummage. It also is designed to help teams learn from their experience and continuously improve, which all fit into an agile mindset.
Kanban comes from the manufacturing floor of the Toyota car company. It developed from lean manufacturing, which reduces the work-in-progress and focuses on just-in-time delivery of materials to optimize storage space and stay focused on the immediate task.
At its simplest, kanban is a board with columns marked to-do, doing and done. Underneath these columns, cards are stacked. Each card represents a specific task that is then moved horizontally across the board as it moves through a production cycle.
Within an agile mindset, a kanban board is a visualization tool that helps to control the flow of features or cards, so that there are no bottlenecks. Tasks can’t move to the next column until there is capacity for it. While part of an agile framework, kanban is not necessarily iterative, like scrum. It is, however, incremental.
Also, unlike scrum, there are no rigid roles. It’s therefore an attractive bridge between those more accustomed to a waterfall, traditional project management methodology, but who want to transition into an agile mindset.
Extreme Programming (XP)
XP was introduced in the book Extreme Programming Explained by Kent Beck. Unlike scrum, XP, as its name suggests, is used more for how to write and test code at a higher quality.
According to ExtremeProgramming.org, there are four characteristics that make XP an appropriate means to frame an agile process.
- When there are constantly changing software requirements
- When new technology and fixed time in projects result in higher risks
- When development teams are small, distributed and extended
- When automated unit and functional tests are allowed in the technology being used
There are five values associated with XP: communication, simplicity, feedback, courage and respect.
There are 12 XP practices, which are listed below:
- The Planning Game, meeting to predict what needs to be done next
- Small releases to deliver customer value
- Metaphor or a common vision for the team
- Simple design
- Refactoring, which removes duplication to add business value
- Pair programming, two programmers doing one job to produce better code
- Collective ownership
- Continuous integration
- 40-hour week
- On-site customer
- Coding standard
XP uses the agile mindset to improve software quality. It is open to the customer and their changing needs. It gets its name from taking the idea that traditional software engineering benefits are in this framework taken to their extreme.
Agile Project Management Tools & Terms
There are a number of different tools that are helpful for managing projects within an agile framework that we’ve not covered. The following are a select few.
The burndown chart is a graph that shows how much work is left to be done and how much time is left to do it. This helps with estimating when the work will be done on the backlog. It acts as a red flag if things aren’t going well and is another communication tool to show progress and estimate how long it will take to complete the work.
The burnup chart is like a companion to the burndown chart. It is used to track the amount of work that has been completed, as well as showing the total work of the project or sprint. Again, this is used to track the team’s progress and help them manage scope and avoid scope creep. It’s another easy-to-read chart that helps with transparency.
This agile project management tool is used to collect an end-user’s description of a software feature, so it comes from their point of view. After all, it’s the end-user for whom the product is designed, and agile project management is all about serving the client.
The user story also describes the user. It’s not only what they want, but why they want it. This leads to a simpler description of product requirements. There are also epic stories, which are larger user stories to get the big picture. They will get broken down into more manageable user stories.
Story points are used to determine how difficult it will be to implement the user story. It is represented as a number that tells the team the level of difficulty. It helps with figuring out what the workload will be and avoids wasting time on trying to make too precise an estimate.
This is a collaborative process that helps the team create the product backlog. It’s called a map because it is used to capture the customer on a journey they take with the product being worked on. Therefore, it begins with a goal and that is then broken down into user stories. This is all to increase the value to customers.
Iterative and incremental approaches to projects have moved out of the software sector and have come to touch almost every industry. The philosophy of agile project management has been built from years of project management experience of what works and what doesn’t. Obviously, those who prefer to work in an agile environment have embraced the adaptive, iterative and evolutionary approach to working on projects. This ultimate guide to agile project management might bring you into their camp. Even if you don’t adapt this philosophy in its totality, adopting some of its principles may improve your projects.
See Why Teams Love ProjectManager.com
Start managing your work your way.
2,000,000+ projects planned, by companies including