Waterfall Vs Agile

Waterfall Vs Agile

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

 

Waterfall: 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 before the next phase can begin.

Agile: 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. 

 

Waterfall: Encourages conformance to processes and tools

Agile: Values people interactions over processes and tools

 

Waterfall: Requires comprehensive documentation

Agile: Values working software over comprehensive documentation

 

Waterfall: Restricts new ideas

Agile: Encourages experimentation and new ideas

 

Waterfall: Promotes a process-centric environment

Agile: Promotes a people-centric environment

 

Waterfall: Dependent on contract negotiation with customers or suppliers

Agile: Encourages customer collaboration over contract negotiation

 

Waterfall: Requires conformance to a detailed project plan

Agile: Embraces change over following a plan

 

Waterfall: Demotivated team members. Requires a continuous effort to motivate the team.

Agile: Creates high performing, self-organizing, and motivated teams

 

Waterfall: Requires a huge rework to accommodate late changes

Agile: Welcomes changes even late in development with minimal rework

 

Waterfall: High cost of change

Agile: Low cost of change

 

Waterfall: Upfront planning

Agile: Just-in-time planning

 

Waterfall: A higher possibility of mismatch between requirements and the final product

Agile: Frequent feedback loops reduce any mismatch between expectations and results

 

Waterfall: Unhappy customers in spite of the hard work by the development team

Agile: Delighted customers due to frequent feedback and response to changes

 

Waterfall: Requires upfront decisions

Agile: Decisions wait till the last responsible moment (LRM)

 

Waterfall: Does not encourage regular interactions with customers

Agile: Promotes daily collaboration with customers

 

Learn more on Agile, Lean, Scrum, or Kanban with below reads:

Please follow and like us:
error

Fishbone Diagram

What Is Fishbone Diagram?

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.

The fishbone diagram is a pictorial representation and categorization of possible known causes to a problem, usually gathered during brainstorming. The fishbone 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. This technique is mostly conducted in a group with people from different fields of expertise. However, this method can also be used by an individual as a tool to structure one’s thoughts and identify root causes.

To learn more about Fishbone Diagram with examples, read my book, An Expert Guide to Problem Solving, available at Amazon.

Please follow and like us:
error

What is Technical Debt?

What Is Technical Debt?

Learn Agile

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 financial debt. Like financial debt, technical 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 technical debt. He stated:

“The concept of 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.”

 

Get the answers to the below questions in my management book, The Basics of SCRUM: A Simple Handbook to the Most Popular Agile Scrum Framework, available exclusively at Amazon.

  • What is a Technical Debt?
  • What are the main causes of Technical Debt?
  • What are the consequences of Technical Debt?
  • How do you manage Technical Debt?
  • What are some of the practical examples of Technical Debt?
  • What are some of the practical techniques to manage Technical Debt?
Please follow and like us:
error