I have decided to write this article knowing that I am going to address a delicate topic and that many readers already have a firmly held preference for one of the two types of project management methodologies… and against the other type.
I have been talking to people from both schools of thought for several years. I will try to give my opinion in this article, even at the risk of knowing that my views may discomfort one group or the other, or both.
Types of Projects
Currently, there are two main methodologies for managing projects:
- Waterfall projects, which is the classic way of executing projects in sequential stages (requirements, functional analysis, technical design, development, testing, deployment). This is the “old” approach that has been done since the 1960s or earlier with various variations (spiral, iterative…).
- Agile projects (such as SCRUM), which are carried out following agile patterns (two-week sprints, product backlog, Product Owner, Scrum Master, developers). This is the “modern” approach that emerged in the late 1990s and was formalised after the publication of the “Manifesto for Agile Software Development” in 2001.
Those of us who are older have found it a bit challenging to understand the agile way of project development. We were “taught” that a project could not start until we had a clear (or believed to have) understanding of its scope, cost, and timeframe… and a good/long contract (signed, of course!) specifying everything.
People who advocate for waterfall projects are sometimes referred to as being from the “dark side” because it seems like they prioritise their company’s interests over those of the user… and they generate a lot of bureaucracy.
In the end, these traditionalists have come to understand how to execute projects in an agile manner (the scope changes and refines as sprints progress). In fact, they explain that agile projects are easier to manage since there are hardly any contractual conflicts and less paperwork. Some of my older colleagues call them “happy happy” projects because the scope is defined on-the-go and there are never any disagreements with the client… but there are many meetings.
In my experience, I believe that neither approach is completely dark and bureaucratic nor does executing a project in an agile manner free us from pressures and deadlines related to cost, scope, and quality.
We have also learned, both us and many of our clients, that sometimes it’s good to do a waterfall project and other times it’s beneficial to do it in an agile one.
Personally, I believe that both ways of executing projects are correct depending on the characteristics of the software application to be developed, the necessary time to market,
and the organisation of the company as a whole. All these dimensions are equally important. For example, and using two very extreme examples, the ideal way to develop different versions of a mobile app should be agile since the goal is to enter the market as soon as possible, adapt very well to the changing needs of users, and offer more than the competition. However, the waterfall method is the best way to build a car production plant or a corporate banking back-office system with endless interfaces with external systems, hardware that needs to be designed and manufactured… and following EU (or similar) security or confidentiality guidelines that cannot be changed.
It doesn’t make sense to ask an external provider for an agile project when the Purchasing Department demands specific deadlines, scope, and costs with penalties within a 100-page contract that includes an unchangeable list of requirements. If also the Business Department “doesn’t have time” to participate in the project except for final acceptance testing…
Similarly, it doesn’t make sense to do a waterfall project when the scope is not completely clear at the beginning of the project, and it is defined by the Business Department (through the Product Owner) as the project progresses because competition in the market is fierce and changes every week or month. If we try to do it in a waterfall manner (even if it’s iterative), the Project Manager will spend most of their time managing changes in scope and deadlines without offering added value to the client’s business. Additionally, engaging in endless discussions about costs and deadlines that ultimately destroy team spirit between Client and Provider (whether internal or external).
Hybrid Clients
There are young clients/companies that were born and are fully and purely agile, and other older or more traditional clients that are pure waterfall, although it is true that the latter are logically disappearing at a rapid pace.
As I mentioned in a previous post www.kiteris.com/team-as-a-service-taas, there are many clients who started doing everything in waterfall but have had to adapt (market pressures, app development…) and now combine executing projects in waterfall with agile projects. However, all participants and stakeholders in each of the projects must be clear on the “rules of the game” to apply in each project… from the CEO and CFO to the IT department and Business department.
Challenges
There are a series of challenges that the current situation poses to our clients and ourselves when we are helping them manage their projects or performing Project Management Office (PMO) tasks with a global vision.
The first challenge a client must address is deciding which project management approach to execute to achieve their business objectives or those of their shareholders: only waterfall projects, only agile projects, or deciding on a case-by-case basis depending on needs. This decision implies or leads to decisions on what methodology and management tools should be available, what training should be provided to my team, what involvement and coordination is needed between Business and IT,…
The second challenge is explaining to the entire organisation (Legal, Purchasing, Finance…) that it is not the same to contract or manage a waterfall project as an Agile project. These departments must be able to accept and propose contractual solutions for both types of projects and not just for historical waterfall projects.
The third challenge is creating a reporting and management mechanism for the leadership that allows for both waterfall and agile projects to be included in the high-level vision. This can be done by creating a “hybrid PMO.”
There are other more specialised aspects to solve but that are also important and should be taken into account in large or mature clients:
- What single tool (if possible) for project and program management (groups of projects) should be used? Until very recently, there were tools that managed the waterfall project world very well (MS Project Online and its “clones,” CA’s Clarity PPM…), and other tools that were created to manage agile projects (Trello, Rally, Asana…). In the last two or three years, there have been movements of acquisitions and integrations between both worlds.
- There are very large clients that were born agile and have all their projects as agile but face the challenge of having to manage a multitude of independent agile projects in a coordinated manner. Here, methodologies like SAFe, Spotify, Scrum@Scale (S@S) emerge, which attempt to extend the agile concept to the
management of multiple projects but, in return, add complexity to the agile concept. These methodologies are sometimes not accepted by Agile purists.
- Current trends within the agile world lead to the following evolution. These are DevOps and TDD methodologies (with automated testing tools), which are currently experiencing strong penetration, especially the former. These
methodologies aim to unify in a project team the previously separate worlds of infrastructure and testing. The goal is to have a single multidisciplinary team that can carry out the entire software lifecycle and thus react as flexibly as possible.
- Within waterfall projects, ideas and working methods from the agile world can be partially applied, which can help break down silos and barriers among specialists that often appear in such projects. For example, holding daily
meetings is a very good idea.
What I see clearly is that the world of project management is becoming increasingly agile, and hybrid in some cases. At Kiteris, we must be prepared for this. That is why we need to be trained and experienced in both agile methodologies and those classic waterfall methodologies and frameworks that are opening up to the agile world, such as PM2 (see www.kiteris.com/open-pm²-para-pymes) or the recent 7th edition of the PMBok from PMI®.
