Agile vs Traditional Project Management : a guide to choose
Agile project management and software development have become hot topics in recent years. To date though, the emphasis seems to have been on how to move from a traditional approach to Agile, abandoning the traditional approach completely.
While Agile might be the best approach for some projects, other projects still require the rigor of a more traditional approach. For example, upgrading a financial system may require specific documentation to comply with Sarbanes-Oxley. How should an organization decide which approach to take? Does an organization have to use just one approach? Can the approach be modified in the middle of the project?
In this article, we will discuss how to decide the best approach based on key parameters such as the level of risk, the level of uncertainty, and the speed of delivery.
However, always remember that the chosen approach will have to be adapted to the organization needs and context.
Also remember that a number of factors that won’t be discussed, such as organizational change management, training, management support, and coaching must be considered.
Traditional Project Management
Project management is an age-old practice. Project management as a practice can be found in the making of the Pyramids or the Taj Mahal or even in more modern projects of developing the highways, roads, bridges, new cities, new railroads, and new products to name a few.
Project Management is a discipline consisting of a set of proven practices, tools and techniques which are applied in managing a project. As per many definitions, project is a temporary endeavour undertaken to create a unique product, service, or result. The result of a project is always something unique, something new.
For most of the products such as traditional infrastructure construction, it is possible for the team to define and establish the entire requirement of the final product upfront. Hence the entire project can also be planned in detail upfront. It is also assumed that the number of changes is relatively low. The entire project development can become predictable. In such projects, a series of activities can be defined for the project such as initiation, planning, execution, monitoring and controlling, and closing etc. All the activities happen in a sequence. The entire project life cycle is divided into a number of phases and the work is completed phase by phase. Traditional project management uses a waterfall model of development, where one phase is completed before the next phase can start. At the end, the final product or service is ready. Tools such as Work Breakdown Structure, Gantt Charts are extensively used.
A traditional project management methodology is often packaged as a toolkit that is used to manage projects where there are a number of detailed contents, such as:
- Definitions of Roles and Responsibilities
The procedures may be packaged in a project management handbook and contain the step by step approach to running projects.
iLEARN® proposes many courses regarding traditional project management approaches. For more details, read:
- APM, https://www.innovativelearning.eu/products/association-for-project-management-apm.html
- PMI, https://www.innovativelearning.eu/products/pmi.html
- Praxis Framework, https://www.innovativelearning.eu/products/praxis-framework.html
- PRINCE2® https://www.innovativelearning.eu/products/prince2.html
Agile Project Management
The Manifesto for Agile Software Development (© 2001) set the core values for the Agile approach:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. (Agilemanifesto.org, 2001)”.
While the manifesto focuses on software development, the principles apply to project management as well.
All the agile project management methods have some common characteristics, such as:
- Focus on value creation and customer satisfaction
- Fast delivery times
- Continuous adaptation
- Focus on collaboration
- Greater transparency
- Test early and often
- One step at a time (build by iterations)
- Self-motivated and autonomous workforce
- Efficient communication
Methodologies for agile project management are interpreting and detailing with a different emphasis some elements constituting a traditional project management approach (typically processes, procedures). The agile project management approaches remain “light” or “simplified”.
iLEARN® proposes many courses regarding agile project management approaches. For more details, read:
- AgilePM®, https://www.innovativelearning.eu/products/agilepm.html
- AgileShift®, https://www.innovativelearning.eu/products/agileshift.html
- PRINCE2® Agile, https://www.innovativelearning.eu/products/prince2-agile.html
- Scrum, https://www.innovativelearning.eu/products/scrum.html
Additionally, AgileLearn® courses, https://www.innovativelearning.eu/products/agilelearn.html, give a great overview of Agile management approaches and how to use them in project management but also other contexts, such as product/service development and business as usual.
Differences between agile and traditional Project Management
So, what is the difference between traditional and Agile project management?
Typically, Agile methodologies are not as detailed as the traditional methodology. This supports of the idea of “individuals and interaction over process and tools” contained in the Agile manifesto. While there may be general guidelines in the Agile approach, it does not have the details provided with the traditional approach. There will be fewer templates and less specific procedural steps in the Agile methodology.
Agile principles stress a working product over documentation. Because of this, the Agile approaches shifts more quickly to execution and spends less time on planning. Complex project management plans, detailed requirements documents, or documentation of roles and responsibilities, which are key planning documents of a traditional methodology, are not included.
One key aspect of the Agile approaches is adaptability. The team not only looks at the product as it is being developed and make changes to features, they also look at the process. At the end of each iteration, the team conducts a lessons learned session, often referred to as a retrospective. The point of the session is to review both the product and the process. The team discusses how the project is going and what changes to the procedures would increase their performance. For example, the team may decide they need to modify the testing process or change the format of meetings.
In traditional projects, conducting lessons learned is part of the project closing process. As in the Agile approach, one topic is a review of the project management activities; although any recommendations to changes in the process impact future projects rather than the current project. Even if the lessons learned are conducted at the end of each phase, because that phase will not be repeated for the project, the recommendations will only impact future projects.
However, there are several common myths in Agile project management. One myth is that there is no planning in an Agile approach. Planning does occur, but, like the actual development, it is an iterative process. Teams initially plan high level features. At the start of each iteration, a more detailed plan is created for that iteration. While detailed plans are not developed at the beginning, because of the unknowns, planning is definitely part of an Agile project.
Just as there are no detailed planning documents developed at the start of the project, there are no detailed requirements documents. Project teams work closely with the customer to define the features of the end product. In this phase, only high-level information is documented for each feature; details are determined during the iteration in which the feature is developed.
A second myth is that Agile projects do not require project managers. In reality, the role of the project manager is different since there is less emphasis on management activities, such as planning or budgeting and more emphasis on leading the team. Jim Highsmith uses the term “leadership-collaboration” to describe the modified role of the project manager. In the Agile environment, project managers focus on communicating the project vision, providing support for the team, and removing obstacles that would impede progress.
How to Select the Correct Approach at Project Start
As often happens, there is no silver bullet in project management too. The decision to adopt a traditional vs. agile project management approach should be made base on several factors. Among others, factors to consider are:
- How clear are the requirements? An Agile approach better suits a situation where the requirements are unclear or subject to change whereas the traditional approach is more suited to the situation where the requirements can be clearly defined at the start of the project
- Is new technology involved? The Agile approach allows for more experimentation with new technology. When the technology is not new, a traditional approach may be more appropriate.
- Is there a lot of risk? With an Agile approach, risk can be addressed sooner in the project.
- Is the right team available? An Agile team is typically small and composed of more experienced members. If the project requires a larger team, the traditional approach may better suit the project.
- What is the criticality of the end product or service? Because there is less documentation, an Agile approach may not be appropriate for critical products such as drug development or space shuttle components. In these cases, a more traditional approach is best.
Based on these questions, checklists can be used to assess the project factors to decide the best approach for any project. Obviously, the sponsor will need to be comfortable with the decision. If a sponsor is more used to a traditional approach, supporting an Agile project could potentially create confusion or conflict. For example, consider project status reporting. In the traditional approach, sponsors typically receive a weekly written status report. In the Agile world, the sponsor is told they have to show up for the daily stand-up meeting to get a status update. They may resist this change and ask for the weekly status report anyway. The project manager will need to educate the sponsor on the Agile approach and sell the benefits so that the sponsor understands how they support the project in this new environment. In some cases, the project manager may have to perform some of the traditional project management tasks behind the scenes to support stakeholders while the team marches forward using the Agile approach.
A possible solution and improvement are hybrid approaches that mean combining traditional with agile project management methodologies aspects. This an always more frequent trend in organization. For example, a traditional based governance framework on top of different teams working on several phases and/or parts of the project with different methodologies, some traditional and other agile.
Each approach has a number of advantages. Organizations that use both approaches must understand the advantages of each so that the best approach can be selected for any given project. In some case hybridization could be the way to go.
In general, the traditional approach is better suited for complex projects with larger project teams. Agile works well with smaller teams with high skill levels. However, this may be questionable as methodologies to scale agile approaches in large organizations and projects are emerging and getting mature in the recent years.
What is undoubtful is that the traditional approach works better in more stable environments where there is little use of new technology. Agile works well when new technology is being used. A traditional approach provides a higher level of documentation. Agile works well when requirements are unclear, or risk is high.
While Agile is flexible, it is not always the fastest approach. Although it is true that a working version may be developed sooner, the situation could also exist where a first version of the product is developed and, after reviewing it, the team starts over again. Because there was not as much planning, the team may discover how not to design the product.
Finally, traditional approaches tend to be easier to adopt when key parts of the projects are assigned to external organizations and need relatively inflexible agreements. In this cases it is usually required to defined precisely the work and terms with the supplier and this fits better in a traditional project management framework.