For the great majority of us, the term project management is related to the compilation of steps taken to develop a project from beginning to end. Most of these steps are more logical to some of us than others.  You basically divide the project into sections, where one section needs to be completed before the other. The reason to complete section A before Section B is that there are many requirements in Section B that are to be completed in Section A, and that without Section A finished, section B just cannot start or be completed. There is a whole chapter in the PMBOK for this reasoning [i]. The PMBOK describes techniques to determine the precedence of such activities, their dependencies and talks about many other tools that are important for project completion. The PMBOK was the basic guide to the standard of project management until a few years ago. To make things easier to write, we will call this traditional project management methodology “waterfall”. Then we have the newer stuff. Agile.

Agile was developed due to the frustration of software developers in the ’80s to the slow progression of projects when using waterfall methodologies. The time between designing a product and releasing it to the customer could be well extended into the years; and this without receiving feedback from the customer. This caused costly issues, for example, clients not satisfied with the final product. In a way, it was a problem of timing plus lack of communication with customers. Besides the process itself, Agile methodologies approach the final product throughout by strengthening the working relationships of developers and people working in the project, rather than the process itself. Jim Highsmith in the “History: The Agile Manifesto” said:

“At the core, I believe Agile Methodologists are really about “mushy” stuff—about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important and lose the word “asset”. “ [ii]

To me, there are a variety of differentiations between Agile and waterfall methodologies, but there are also similitudes. These characteristics plus the growing question, “Can agile be applied to any kind of projects?”, is what I am working on resolve and explain. I believe we can use Agile for more than only software development projects. To me, Agile is a necessary evolution of Project Management.

Let me just start by saying that to me these terms, Agile and Waterfall, are not necessarily antagonistic. One can be part of the other, you can develop a project on a macro scale being managed by waterfall, and the sub-projects be treated with agile or the other way around. We just have to be cognizant of the differences and needs of each methodology. It might get very confusing at the beginning, but as with quality after any change, “it will get worse before it gets better”. Let’s starts by defining the differences.

The main difference to me is the “people” approach from both methodologies. While waterfall is focused on the processes to be taken in the project to complete the final item, agile empowers the people working on the project to create the process. In waterfall, the responsibility of “employee empowerment” falls into the company’s culture. In Agile the employee is empowered by autonomy and purpose to gain mastery in their craft. The center of Agile Methodologies comes from a document called, The Agile Manifesto, which describes the main focus of any project developed with Agile. The Agile Manifesto says:

“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.” [iii]

Two out of four statements in the manifesto refer to individuals, interactions, and customer collaboration. Projects that are well managed with Agile Methodologies require collaboration between customers (the individuals using the final product) and the developers (the creator of the products). There is a direct line of communication from developers to customers; this communication is always open in case of questions about customer needs and developers’ doubts. On the other hand, waterfall requires a defined plan that the creators of the final product would work on. If there are questions about the project that needs to be addressed with customers, they have to follow a chain of command, not everybody can approach the customer with questions.

Another main difference between Agile and Waterfall is the responsiveness of the methodology. Although a lot of professionals would differ with me on this point, I consider any project developed with waterfall very stiff and hard to change. There are a lot of steps required to implement a change on a waterfall project besides the chain of command. A change request has to be created and documented, then the change request has to be analyzed and measure to know how the change impacts the other phases of the project, and only then after the change is analyzed, it can be reviewed and approved. All of these steps start with documentation. In contrast, Agile is designed so changes are quickly accepted and implemented. Scrum, an Agile approach, works in cycles known as “Sprints”. The length of a sprint varies usually between 1 and 4 weeks.

Sprint Length is the defined interval within which the team delivers an incremental workable solution that meets the definition of done and therefore acceptable to the customer. In a developer’s words – “ready to ship or release to the customer”.[iv]

In simple words, a sprint is a predefined set of time. Developers agree to start and finish “some” small increments of a big project in this predefined time. The agreement is that the small increments to be worked on during the sprint will comply with the “definition of done” by the end of the sprint time. “Definition of done” is like a “Go No Go gauge”; either complies or does not comply. In that way, the project has small, fully functional increments by the end of each sprint. Then, if the customer wants a change, the change can be implemented after the sprint finishes, because every new sprint is planned based on current needs. This provides great flexibility to the projects.

Another main difference between Agile and Waterfall is the project manager role. I will generalize the role of the project manager here. Although it does not apply to all, the general role of the project manager (PM) in waterfall is to delegate responsibility for a small part of the project to individuals. He/she also is the one to have full contact with stakeholders regarding questions and reports about project advancement. The PM also is the one responsible to keep tracking the project budget and, with the permission of stakeholders and customers, is the one to approve changes to the budget. He/she also is responsible for the timeline of the project. PMs also records and reports milestones in the project, plus are in charge of the solutions to any issue that might emerge. Depending on the structure of the company and the contract between the project manager and the customer, he/she might have enough power to decide the direction of the project. By the PMBOK:

“The project manager is the person assigned by the performing organization to lead the team that is responsible for achieving the project objectives. “ [v] (A Guide to the Project Management Body of Knowledge, 2013, pp. 16-17)

In Agile, Scrum to be more precise, the responsibilities of the project manager are broken down into different roles. The Scrum Master that ensures the project is developed according to Agile methodologies, he/she facilitates collaboration between the team members, he is a teacher and facilitator of the team. The scrum master is the champion of change. The Product Owner manages dates, budgets, and expectations with stakeholders. He/she manages the product backlog which is the list of items to be worked on in future sprints. The Product Owner is the main point of contact for customers to prioritize but encourages direct interactions between the users and developers. The Developers make the decisions on how to work and what can be done during a sprint. They take accountability for developing the tasks to be completed during the sprint. They are in charge of the development and quality of the product.

In conclusion, Agile does not have a main person in charge of the project, instead, the responsibility is shared among the individuals of the agile team. Each one of the members fulfill a part that used to be satisfied by the project manager and as we said before, empowers the whole team. The fact that Agile represents a more flexible system overall represents a win-win situation for development/production teams and customers/users. On one side the development teams work on small chunks of the project that have a low probability of being change while work is in progress. This means developers can focus on the immediate objective until they are Done and waste no time on changes or “what if” thinking. On the other side, customers do not have to have their mindset in the final product, they can actually change their point of view and improve, enlarge or change their idea of the product/project as time passes. Flexibility for all.

[i] Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide). 5^th Edition.  Newton Square, Pennsylvania: Project Management Institute, Inc.

[ii] Jim, J.H. (2001) History: The Agile Manifesto [Online] Available at: https://agilemanifesto.org/history.html (Accessed: 31 March 2021)

[iii] Jim, J.H. (2001) Manifesto for Agile Software Development [Online] Available at: https://agilemanifesto.org (Accessed: 1 April 2021)

[iv] Anurag, A.P. (2020) How to define an Ideal Sprint Length [Online] Available at: https://www.orangescrum.com/blog/how-to-define-an-ideal-sprint-length.html (Accessed: 4 April 2021)

[v] Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide). 5^th Edition.  Newton Square, Pennsylvania: Project Management Institute, Inc.