Why waterfall approach is a bettter solution than agile approach from a manager's perspective

Stages of Software Development Lifecycle using a waterfall approach

In the waterfall approach, each stage of the project delivered is a set of tasks that have to be completed by a planned deadline. A common set of stages for a software development project are [1]:

1. System requirements
2. Software requirements 
3. Analysis
4. Program design
5. Coding
6. Testing
7. Operations (until the system reaches its end of life - EOL)

In theory, after the requirements are gathered, and the system was designed, implementation has to satisfy the requirements and the design without the possibility of changing the agreements made during in previous phases. Each phase is a silo of work, which is disconnected from other silos.

This can result in a situation of conflicting requirements being detected during the testing or deployment phase without a chance to discuss these requirements with their authors.

Maintenance is a special type of stage because there are cases when it is unknown, how long the system will be maintained. From a programmer's perspective, maintaining software can be a daunting task in comparison to the creative and empowering phase of implementing the software requirements.

A significant characteristic of this approach is that after the last phase, the software is retired and there is no possibility of starting previously finished phases.

Stages of Agile Software Development Lifecycle

A common sequence of phases, when approaching software development using the Agile approach are [2]:

1. Requirements gathering to form a backlog of tasks required to build a product
2. Planning of the scope of upcoming iterations
3. Iteration of coding, which delivers items from the backlog and contains daily team meeting
4. Demo of delivered software to the customer
5. Review of what was delivered during the iteration
6. Retrospective of what was good and bad about the finished iteration
7. Steps 3, 4, 5, and 5 are repeated until the customer requires more software

First, the major difference compared to the waterfall approach which I described in the previous paragraph, is that the sequence of phases has a point, where it returns from step 6 to step 3 until the customer requires the team to deliver more software. This means that experiences gained during the first iteration will be carried on to the next iterations. Compared to the waterfall approach, knowledge is not siloed in each phase and it is discussed during daily team meetings, spring review, and sprint retrospective phases.

Looking at step 7 in the Agile approach, we can see that similar to the last waterfall phase called "Operations", it may be unknown how long the customer will require new software.

What is the reality

I will begin with a statement that I heard from my colleague while I was working on an "agile maintenance project" for a large commercial bank:

"In the waterfall, I feel that the project ends, and we have lessons learned and we implement them and the next project is better. Here, we meet every two weeks and I feel there is not much of a change after we do the retrospective"

You can feel from this statement, that the author favors a sequential, siloed waterfall approach over the iterative and open to the knowledge flow agile approach, but why?

Because in reality, the company has hired Agile coaches who determine how the Agile approach is executed in every project. These coaches are leaders, who introduce new tools, vocabulary, and a new way of thinking about software delivery, and from my experience, they usually do not accept Gantt charts simply because Gantt chart is not agile.

So when the theory of delivering software in iterations may sound like a way to produce software faster, it sometimes is not the main focus for the managers. From a manager's perspective, a clear timeline for the next 12 to 24 months can be more valuable, than having the assurance that the customer is happy about what was delivered in the last two weeks simply because some managers operate in a larger ecosystem of projects and other managers who need to coordinate next few months of work for their teams.

Summary 

On a large scale, having a structured and sequential way of delivering software, as described in the waterfall approach, brings order to the work of project managers. On a smaller scale of the developer team, the day-to-day work is the main focus, which fits perfectly with the agile approach. This brings me to the conclusion, that context of responsibilities from which we look at the software development lifecycle determines the methodology which is the best fit.

Sources:

[1] "Agile project management and the PMBOK® guide"; Sliger, Michele; https://www.pmi.org/learning/library/agile-project-management-pmbok-waterfall-7042 

[2] "Agile processes a unifying approach for the future of projects"; Casanova, Pietro; https://www.pmi.org/learning/library/agile-approach-projects-market-globalization-5777