Waterfall Vs Agile

Let's analyze the core differences between the plan-driven Waterfall approach and the Agile methodology.


  • In Waterfall methodology, project development flows steadily downwards like a waterfall from one phase to another. The common phases are: Define, Analyze, Design, Build, Test, Launch, and Maintain. The preceding phase must be completed and signed-off before the next phase can begin. In Agile methodology, work evolves in an iterative and incremental manner with an emphasis on collaboration, responding to change, and continuous improvement. Its core foundation was laid with the Agile Manifesto for Software Development in 2001. 


  • The Waterfall methodology encourages conformance to plan and processes, however, the Agile methodology values people interactions more. 


  • Waterfall is the plan-driven or the traditional project management approach that requires comprehensive documentation, whereas, the agile methodology focuses on working software over comprehensive documentation.


  • The plan-driven or the Waterfall approach restricts new ideas that arise during design, build, or test phases of the project, whereas the agile methodology encourages experimentation and new ideas at all times.


  • Waterfall promotes a process-centric environment, whereas Agile promotes a people-centric environment.


  • With Waterfall methodology, projects are dependent on contract negotiation with customers or suppliers, however, Agile encourages customer collaboration more than contracts. 


  • The traditional Waterfall methodology requires conformance to a detailed project plan, whereas, the Agile methodology embraces change. The change control process in the Watefall methodoly is a very time-consuming process that requires a detailed impact analysis, a feasibility study, and possible re-distribution of resources/funds. With Agile, desired changes can simply be written as new user-stories/work items and can be added to the product backlog at any time. 


  • Waterfall requires a continuous effort to motivate the team. Most often, team members are not interested in the outcome of the project. On the contrary, Agile focuses on creating high performing, self-organizing, and motivated teams. In an Agile environment, team members understand the objectives and iteration goals and feel connected to the greater purpose. 


  • The Waterfall approach requires huge rework to accommodate late changes during design, build, test, or rollout phases of the project. As a result, the cost of change in this approach is quite high. On the other hand, Agile welcomes change even late in development with minimal rework, keeping the cost of change low.  


  • When Waterfall is synonymous with upfront planning, Agile is all about Just-In-Time (JIT) planning. 


  • With the Waterfall methodology, there's a high possibility of mismatch between approved requirements and the released product, whereas, Agile encourages frequent feedback loops that reduce any mismatch between expectations and results.


  • Often, with the Waterfall approach, customers stay unhappy in spite of the effort put in by the development team. Agile methodology is customer-focused. Customers stay delighted due to frequent feedback and quick response to changes or team agility.


  • Waterfall requires upfront decisions and approvals for the requirements document, the design documents, test strategy, etc. In Agile, decisions wait until the last responsible moment (LRM). LRM is a strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.


  • In the Waterfall approach, there is a limited interaction between the developers and customers (especially once the design phase starts). On the contrary, Agile promotes frequent collaboration with customers with daily stand-ups, backlog refinement, iteration planning, and product demo, and retrospective ceremonies for each iteration or sprint.


More articles on Agile:


Learn more on Agile, Lean, Scrum, Kanban, and Enterprise Agility with below books:

What is the Fishbone Diagram?

Some of you might have heard about the Fishbone Diagram for effective problem-solving. So, what is the Fishbone Diagram? The Fishbone or Ishikawa diagrams were created in 1968 by Kaoru Ishikawa who was a Japanese Professor at the University of Tokyo and was famous for his inventions for quality management.


It is a pictorial representation and categorization of possible known causes to a problem, usually gathered during brainstorming. Since the shape of the diagram resembles a fish skeleton,  it is popularly known as the Fishbone Diagram. This diagram is being used across several software and manufacturing organizations as a simple visualization tool to depict various potential causes to a problem. It provides a structured way to organize and represent data in a meaningful manner.  


This technique can be used whenever there are many possible causes to a problem or whenever there is a need to identify causes to a complex problem. One can apply the fishbone diagram method in solving day-to-day problems as well. Though this is mostly a group technique, this technique can also be used by an individual as a tool to structure thoughts and identify root causes.


Categories of a Fishbone Diagram

The most commonly used categories for identifying the potential causes to a problem are listed as below:

  • People
  • Methods
  • Materials
  • Machines
  • Measurements
  • Environment


The 'People' category helps us to identify all causes that are people related. Here's an example. One of the leading software organization was having major quality issues and one of the primary causes was the unavailability of skilled resources. When represented on a fishbone diagram, this cause, Unavailability of skilled resources, will appear under the ‘People’ category.


Any causes that deal with the process or method to perform an activity are listed under ‘Methods’ category. Primary causes such as Inefficient development processes, Unnecessary effort spent by the team, etc. are few examples of the causes that fit well under the ‘Methods’ category.


The ‘Materials’ category is specific to any material or parts required to produce a product. This category is more common in the manufacturing industry. However, within software organizations, this category can be used to group any causes related to external dependencies. For example, if you are making changes to a front-end application that calls a service to fetch some values and if you hit a roadblock, then a primary cause such as Unavailability of the dependent service will be represented under this category.


The ‘Machines’ category is used to group all the causes related to hardware, software, and tools. For example, one of the primary causes of poor system performance could be the Unavailability of additional servers. Then again, one of the primary causes of ineffective communication within an organization could be the Unavailability of collaboration tools. Such causes are usually grouped under the ‘Machines’ category on a fishbone diagram.


The ‘Measurements’ category is used to group the causes that relate to incorrect data to measure the quality or success of the product. Consider an example where your team has launched a new website but the product goal to reduce call volume to the service center is still not met. Now, if one of the primary causes to this problem is the Incorrect data gathered during user research of the product, then this primary cause will be represented under the ‘Measurements’ category on a fishbone diagram.


Causes that relate to an environment are usually grouped under the ‘Environments’ category. For the manufacturing industry, an example of an environment-related cause is Lack of appropriate weather conditions or location. For software organizations, an example of such a cause could be Instability of development, test or production environments.


Though the above categories are the most commonly used categories for a fishbone analysis, people often tend to brainstorm the categories that are relevant to the problem they are trying to solve.


Now that you better understand the Fishbone Diagram, learn the steps needed to conduct a Fishbone Diagramming session with your group. Also read about other problem-solving techniques such as Brainstorming, Failure Modes and Effects Analysis (FMEA), SWOT Analysis, 5Whys, etc. with my book, An Expert Guide to Problem Solving - With Practical Examples.


More articles:


More books:

What is Technical Debt?

If you are applying the Agile Scrum Framework at work, you must have heard the term, Technical Debt. So, what is the Technical Debt? Who invented this term? In this article, you will understand what it means and how to manage it.


The Definition

Ward Cunningham introduced the concept of technical debt in 1992. He defined it as follows:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

Cunningham used the ‘Technical Debt’ metaphor to emphasize the benefits and limitations of speedy development. The metaphor was well received by both business and technical people as it resonates with the financial debt. Like the financial debt, this debt accumulates interest with late repayment.


In 2004, Joshua Kerievsky describes ‘design debt’ in his article ‘Refactoring to Patterns” and the associated costs. Then again in 2014, Grady Booch compared evolving cities to evolving software and described how lack of refactoring can lead to the technical debt. He stated:

“The concept of the technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So, it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.”


Main Causes of the Technical Debt:

Review your product, system, code, practices, and processes for:

  • Outdated design
  • Low code coverage
  • Lack of automated regression test suite
  • Lack of continuous integration
  • Lack of appropriate testing
  • Tightly-coupled code
  • Delayed code refactoring
  • Aggressive timelines


How to manage the Technical Debt:

An organization should enforce good technical practices to all the developers, including but not limited to technical design review, code review, automated regression suite, high code coverage, adequate testing, and continuous integration. This will limit the accrual of this debt. The products that have accumulated the debt should focus on refactoring to reduce technical debt and improve maintainability. Below techniques will reduce your debt:

  • Have a strong definition of done
  • Create visibility for the tech debt
  • Prioritize the tech debt
  • Leverage an incremental approach


Learn more about the technical debt and other concepts of the Agile Scrum Framework with my book, The Basics of SCRUM: A Simple Handbook to the Most Popular Agile Scrum Framework, available on Amazon.


More articles:


Recommended books: