The practice of project management is used in order to ensure successful results. However, there is no one-size-fits-all approach to project management, as each project is unique.
Since project management became widely utilized, quite a variety of project management methodologies have been developed to suit different types of projects and business industries. Agile project management rose to fame at the turn of the millennium, and you probably want to know what all the fuss is about.
In this article, you will read everything you need to know about Agile project management, plus some of the most popular methods that fall under the umbrella term.
Before we dive into the specifics of Agile project management, let us explain what the differences are versus traditional project management.
The structure of traditional project management
A typical project includes a sequence of activities, divided over different phases. According to the Project Management Institute (PMI), these phases are:
This is a very general structure of course, as each project is unique. The activities and phases can look entirely different depending on the scope of the work, and the industry.
Overall, traditional project management usually follows this structure.
Traditional project management takes a linear approach
Other things that mark traditional project management are the step-by-step approach, and the chronological order of execution. Most commonly this traditional approach is known as the Waterfall method. Each phase is completed consecutively, from initiation to project closure. Thus, this approach is linear.
For a lot of industries, traditional project management works really well. Especially in the manufacturing or construction industry, where a solid plan is followed until the end, without requiring any big changes along the way.
Agile project management takes a non-linear approach
However, other industries found that this linear approach doesn’t align with the complexity of some of their projects. For example, in the software engineering industry.
While some software development projects have a singular, clearly defined deliverable that can be tightly monitored, other projects require a lot of flexibility.
Agile project management was developed as a much more suitable structure for complex, flexible projects. Instead of following chronological phases, these projects require multiple evaluation phases during which changes can be made. Thus, Agile project management takes a non-linear, iterative approach.
This means the team works on a project during multiple iterations. After each iteration, a meeting is held to evaluate the status of the deliverables and to see which changes should be made.
Sometimes, it’s decided that the team needs to take the project in a completely new direction, changing the course of a project multiple times. Instead of having a concrete vision that is set in stone from the beginning, this vision is developed and more clearly defined during each iteration with agile project management.
With its roots in the software development industry, the first practices of agile project management can be traced back to the 1950s.
Early alternative approaches
While working at IBM and Motorola, Bernie Brimsdale, Herb Jacobs, John von Neumann, and Gerald Weinberg developed incremental techniques to build software. They didn’t coin the term ‘agile’ yet, although it was clear that their approach was very different from traditional linear forms.
The development of this approach continued into the 1990s, after what was dubbed the “application development crisis”. During this decade, the average development time for software technologies could take up to three years.
Due to this long process, the technology was already so much more advanced by the time a product was finally released. This also meant that clients’ and customers’ needs and wants had changed by then, leading to many failed projects and wasted money.
The introduction of modern-day Agile Project Management
Leaders of the industry realized something really needed to change, and focused on developing new, more flexible approaches that would be more effective while also speeding up the process.
Modern-day Agile project management was officially introduced in February 2001, by a group of 17 software professionals that explored the matter thoroughly. Ultimately, they mapped out the principles of this new approach in what is called the “Manifesto for Agile Software Development”.
You might already have an idea based on the information given so far. Agile project management was developed because traditional methods lacked the flexibility and velocity needed for certain projects. These types of projects are fairly complex, as they often have a degree of novelty to them.
Using software development as an example again, a project is unique when new technologies are being developed. There is no past data to base it on, as it’s something that nobody has ever done before. Therefore, it’s hard to pinpoint what needs to be done in order to create it, and how long this will take. All of this needs to be discovered along the way.
Another important factor is that these projects all have fairly aggressive deadlines. As mentioned before, you don’t want to waste time and money on developing a product that nobody wants in the end because technologies or customer needs have changed in the meantime. But some projects are so big that it does take a certain amount of time, it just needs to be managed efficiently.
Big projects that can be cut up into smaller chunks, and need revision to avoid becoming inadequate in the end, would really benefit from Agile project management methods.
Agile project management takes its name from the word “agility”, which is synonymous with terms such as “mobility” and “nimbleness”. It is also derived from the Latin word “agere” which means “to do” or “act”. In essence, agility conveys the ability to move forward rapidly, while welcoming changes of direction.
In project management, agility can be signified by five principles:
As we know, the needs and wants of customers can drastically change by the time software development projects are completed. This is exactly the reason why agile approaches focus much more on the customer.
Sometimes customers voice what they want, without really knowing what that looks like in reality. The iterative approach of agile project management is a perfect solution to this disconnect, as the customer can be involved in the evaluation of each iteration.
These evaluation “feedback loops” serve as project lifecycle checkpoints, to determine the direction of the project at each step of the way.
In order to maintain an open dialogue on how to do things best, full transparency is key. The whole team plus stakeholders are encouraged to share their ideas and opinions throughout the process.
This means all team members’ tasks and work processes are openly discussed, and preferably visualized by using a tool or system that everyone can access.
Getting fast and frequent feedback after each iteration, helps teams to respond and adapt faster too. Instead of defining a clear plan and working on the deliverables in one long go, the work is divided into very small chunks to maintain adaptability.
If customer requirements change after an iteration, the team can quickly adapt to a new plan for the next iteration.
While traditional project management leaves most of the decision-making up to the project manager, the agile approach requires all team members and stakeholders to be more involved with this. Not only does this instill a strong sense of ownership, but it also contributes to more effective leadership.
This is probably the core of agile project management. There are various agile methodologies that slightly differ, but they all promote an iterative process that allows continuous improvement.
The goal is to continuously improve the product or service until the customer is perfectly satisfied. But besides this, team members have the opportunity to continuously develop their own skills and knowledge while actively working on the project.
Normally, they would be able to explain which lessons they have learned after a project when the end result is measured against expectations. Now, this process is ongoing while the project is still in motion.
Now that you understand the characteristics and principles of Agile project management, let’s take a look at some of the most popular Agile project management frameworks and methods.
As mentioned above, the Waterfall method takes a traditional approach for which a thoroughly planned step-by-step process is defined. The hybrid approach blends this with Agile project management styles.
Some companies have found that using principles from both of these methods works better than selecting just one of them. Combining the traditional waterfall method with Agile methods is referred to as the Hybrid approach.
This is done by thoroughly setting up the budgeting, estimation, and planning process for example, while Agile methods are used for an iterative development and evaluation process. Many different ways of combining these principles exist, it really depends on the project.
Usually, the hybrid approach works well for projects that rely on hardware and software development activities at the same time.
This combination of traditional Waterfall and Agile methods was introduced by Gartner in 2014. It involves two separate teams that work on projects while having two different goals.
The Agile team focuses on problem-solving and developing innovative solutions along the way, while the Waterfall team focuses on the predictable areas, making sure the project remains stable while changes are implemented.
Both teams use very different methods and have different reporting processes, but they still keep each other informed on updates and results.
The bimodal method is especially suitable for companies that work on a variety of long-term and short-term projects that require different development processes.
The Kanban method divides all project tasks into three categories:
These categories are visualized by three columns displayed on a Kanban board, which is mounted on the wall of the workspace or generated digitally.
Each task or activity is represented by a card that will move through the three columns until it’s completed. First, it’s added to “Requests”, moved to “In Progress” once team members start work on it, and moved to “Done” when the task is completed.
Throughout this process, it’s very important to limit the amount of work-in-progress. As this is visualized clearly with a Kanban board, the team is able to see right away if they should wait before moving a request to the next column. The amount of cards allowed to be in each of the columns is called the WIP limit.
The Kanban method is suitable for many industries, from marketing to IT. Moderately flexible and complex projects will benefit greatly from this method, as it shows the team how to prioritize tasks and evolve gradually after changes are made. However, these are small evolutionary changes rather than huge revolutionary changes.
The Lean project management method became widely adopted after Toyota achieved impressive results with it. Their production system utilized this approach in order to: ”make the vehicles ordered by customers in the quickest and most efficient way, in order to deliver the vehicles as quickly as possible” It is still widely used in the manufacturing industry and becoming more common for software development too.
The principle of Lean project management is to identify and cut all types of waste, in order to provide what is needed, when it’s needed, with the minimum amount of materials, equipment, labor, and space. The three types of waste are classified as the 3M’s:
Muda: non-value adding activities that take up resources
Muri: excess use of equipment or employees
Mura: Any type of overload or unevenness that slows the work down
Constantly reviewing and eliminating waste that falls in these three categories will help the production process to be as fast and efficient as possible. This approach is great for companies that want to restructure and speed up their processes while cutting costs
Developed in the 1980s by Hirotaka Takeuchi and Ikujiro Nonaka, the Scrum approach is probably the most popular agile method used by software development companies. By the 1990s a very clear structural framework for Scrum was developed including specific roles and meetings.
A Scrum team works on projects in multiple short iterations, which are called sprints. These sprints usually run anywhere from 1-4 weeks. If they would take longer, the team would not be able to review things fast enough, lacking the necessary flexibility. At the end of each sprint, progress will be evaluated in order to determine which changes need to be made.
There are three important roles:
Scrum Master: The main responsibility of the Scrum Master is to make sure the team adheres to Scrum principles and to deal with the obstacles that prevent them from doing so.
Product Owner: Sometimes this is the customer or other stakeholder. However, it can also be an employee that functions as the voice of the stakeholders. After every sprint, the Product Owner compares the results with the vision for the end product, providing valuable feedback.
Scrum Team: The team that is responsible for delivering the product. It is usually a team between 7-10 members max, that are able to collaborate cross-functionally.
Specific Scrum components:
Product Backlog: As changes are made after each sprint, the product backlog is a list of items and requirements the team might need to complete the project.
Sprint Backlog: This is an overview of the tasks that need to be completed before the end of one sprint. It’s an agreed-upon plan for the work that needs to be delivered during the sprint.
Sprint Burndown Chart: This chart shows the day-to-day progress of the remaining tasks so the team and Scrum Master know exactly what still needs to be done in order to achieve the sprint goal.
Specific Scrum meetings:
Daily Scrum: Every day, a 15-minute meeting is held during which the plan for the day is discussed. This meeting is held by the development/production team daily at the same time and place.
Sprint Planning: This meeting involves the team, Scrum Master, and Product Owner and takes place once before the sprint starts. They discuss what needs to be done during the sprint in order to achieve the sprint goal, and define how this will be achieved.
Sprint Review: After each sprint, the Product Owner meets with the team to review the work completed and discuss what needs to be done during the next sprint to add more value to the product.
Retrospective Meetings: After the sprint review with the Product Owner, the team comes together for a retrospective meeting to discuss their work in the past sprint. What went well, what could be improved, and how to proceed. This all needs to be reflected upon before the next Sprint Planning.
Scrum is suitable for very complex, long-term projects that require a lot of flexibility. Often end deliverables can’t be determined exactly beforehand, but become more clear after every sprint.
The name speaks for itself; Scrumban is a combination of Scrum and Kanban, although some of the scrum rules are eliminated in the process. The benefit of combining the two methods is that there is now a visualization of the Scrum process on the Kanban board. The Scrum sprints will just require the board to be extended with more columns.
Most things stay the same: the amount of work in progress must not go beyond the WIP limit, and cards are moved closer to the last column as tasks progress. However, estimating if goals can be achieved and planning these goals are considered obsolete according to the Kanban approach. Therefore, Sprint Planning is only scheduled if the team deems it to be necessary. If not, the lack of Backlog items on the board already indicates that more tasks can be planned.
This method is named XP, derived from Extreme Programming as it’s an agile approach for improving software quality based on changing customer requirements. It tackles the problem that technologies advance faster than the delivery of a product.
The product is developed during short cycles, which are referred to as releases. These serve as checkpoints during which new customer requirements can be discussed.
Some components of XP are:
User Stories: The customer states which functionalities and features the software should have in a User Story. After each release, a new User Story is provided that might differ greatly from the last one.
Metaphors: Based on the User Stories, the team can propose a Metaphor. This is a proposed idea of what the requirements stated in the User Story would look like in reality.
Spike: If the team wants to implement a Metaphor, a Spike is built to explore what this new feature/functionality would look like. It’s basically a prototype.
As you can see, this method is very similar to Scrum. Albeit the components are fewer and XP is designed exclusively for software engineering.
In contrast to Scrum which focuses on certain components and meetings, Crystal Agile methods focus more on the team and its individuals. Team size, criticality, and priority of the project strongly influence how the team will perform.
This method was developed by Alistair Cockburn at IBM, during the 1990s. He analyzed several successful teams, concluding that their best practices varied based upon the characteristics of the team and the project.
A small team doesn’t really need regular meetings and formal reports as it’s easy to communicate habitually while working. For bigger teams, it’s harder to align and information is much more likely to get lost in translation.
There are different gradations to the Crystal method, based on team size:
Crystal Clear: 8 team members max
Crystal Yellow: between 10-20 team members
Crystal Orange: between 20-50 team members
Crystal Red: between 50-100 team members
Out of the seven components of Crystal Agile project management, only the first three are necessary for all gradations. The rest can be added depending on the characteristics of the team and project:
Frequent delivery: Regular iterations must be set to deliver code to users. If this can’t be reviewed often or fast enough, you might be developing something the user doesn’t need.
Reflective improvement: Team members continuously reflect on what they have done, how they did it, and why. This is done to determine how the work can be improved in the future.
Osmotic communication: The Crystal method requires all team members to be in the same physical location, so information can flow as if by osmosis.
Personal safety: Open and honest communication is promoted, so team members can always introduce ideas or speak without fear. There are no bad ideas or suggestions.
Focus on work: Tasks should always be prioritized to avoid switching to one that requires less attention at the time. Each team member knows exactly who works on what, which boosts team communication and accountability.
Easy access to expert users: Regular communication with real users is supported in order to receive useful feedback when needed.
Technical attributes: Some specific technical tools could be helpful to catch errors, such as automated tests, configuration management, and frequent integration.
This acronym stands for Dynamic System Development Method, which was developed in the 1990s. It’s based on the principle that each action should strategically align with business goals while ensuring swift delivery of value to the company.
It can be combined with other methods, such as Scrum. Basically, it covers each step of the project by reminding team members of the company’s strategic objectives. Everything they do must add real value to the project on a very short-term basis.
Here are the eight principles of DSDM:
Focus on the business need
Deliver on time
Never compromise quality
Build incrementally from firm foundations
Communicate continuously and clearly
Another acronym, which stands for Adaptive Software Development. ASD was created by Jim Highsmith and Sam Bayer with similar objectives to other Agile methods; to allow projects to be more flexible and adaptable to changing customer requirements. However, ASD does this by introducing a three-phase approach:
It’s important to note that these three phases overlap, as they non-linearly appear at different stages of the process. Or, they might appear at the same time! The team speculates, collaborates, and learns whenever this is necessary throughout the project lifecycle.
This is based upon these principles:
You can’t collaborate without learning, or learn without collaborating
You can’t speculate without learning or learn without speculating
You can’t speculate without collaborating or collaborate without speculating
This method is highly suitable for niche software development companies where small teams work on single projects. It wouldn’t really work for larger teams that work on multiple types of projects at the same time.
Here is a concise overview of the benefits of Agile project management:
Improvement of team collaboration
Improvement of team accountability
Increase in flexibility and adaptability to changes
It promotes continuous improvement
It helps to build client and customer relationships
It helps to catch and deal with obstacles early
Improvement of the quality of deliverables
Decreased risk of missed objectives
Faster delivery of deliverables
Increased rate of success with complex projects
There is no one-size-fits-all approach to project management, it really depends on the type of projects your organization works on. What this article makes evident, is that Agile methods are great for big, complex projects that require many revisions and changes. Projects with a degree of novelty also greatly benefit from these methods, as a clear plan for how objectives can be achieved can not be determined beforehand.
We have explained some of the most popular Agile methods in detail, as the scope of Agile projects but also the characteristics of your team determine which one would be best for your company. Maybe this article has even made you realize that your company would benefit more from traditional project management methods. This could definitely be the case.
Besides adopting a certain project management method, you can also increase the success rate of your projects by implementing project management software such as Rodeo. Again, there is no one-size-fits-all tool for all companies. Making a choice can be very challenging, as explained in this article. It greatly depends on the type of work processes at your company.
Fortunately, our experts would love to take the time to learn all about your work processes in order to explain how Rodeo could support them. Schedule your free demo now!