Skip to main content

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]: System requirements Software requirements  Analysis Program design Coding Testing 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...

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

Comments

Popular posts from this blog

Java Text Blocks

When programming, sometimes you need to store a multi-line text in one String variable. So instead of having multiple variables of type String and then, joining all of them into one I recommend using Java feature called Text Blocks. Compared to a simple String variable, a text block has to start with a triple quotation mark. //regular String variables String greeting = "Welcome to Dastin Sandura's blogspot!"; String description = " I blog about the practical use of Java language. " For comparison, below is a String, initialized with a text block. //text block stored in String variable String multiLineGreeting = """   Welcome to Dastin Sandura's blogspot!    I blog about the practical use of Java language."""; Both of the variables presented above are of type String, which means that by looking at a variable type you cannot tell if its value was set, by using the text block Java feature. However, the most critical difference betw...

Type inference in Java 10

Which Java version understands the var keyword? In order to use the var  keyword, you must use a project based on Java 10. It is the first Java version that has introduced this keyword. How can the var  keyword be used? The formal name of this keyword is local variable type inference [1]. If we take a closer look at this name, we can recognize that it is composed of two parts: "local variable" and "type inference". Why could you use type inference? The juicy part of the local variable type inference is the  type inference  part, which practically means, that Java will assume the type of the variable, removing the need to explicitly write the type of the variable. It can reduce the number of keystrokes that are necessary to write our program by a significant amount and eliminate the possibility of making a typo. For example, instead of writing ArrayList<ObservableClassName>,  we can write only 3 letters: var . Where var cannot be used as of Java 10? It can...