15 differences between Waterfall and Agile Scrum

15 differences between traditional Waterfall and Agile Scrum approach

Here's a quick comparison of the plan-driven Waterfall methodology and Agile Scrum approach:

 

Core Waterfall Features:

  • Encourages conformance to processes and tools
  • Needs comprehensive documentation
  • Restricts new ideas
  • Promotes a process-centric environment
  • Depends on contract negotiation
  • Conforms to a plan
  • Requires continuous effort to motivate the team members
  • Require a huge rework to accommodate late changes
  • Results in a high cost of change
  • Encourages a detailed project plan
  • Leaves a large possibility of a mismatch between requirements and the final product
  • Is likely to have unhappy customers
  • Supports late customer feedback
  • Requires upfront decisions
  • Does not encourage regular interaction with business sponsors

Core Scrum Features:

  • Encourages people interactions
  • Promotes working software over comprehensive documentation
  • Encourages experimentation and new ideas
  • Promotes a people-centric environment
  • Encourages customer collaboration
  • Embraces change
  • Creates high performing, self-organizing, and motivated teams
  • Adapts late changes with minimal rework
  • Has a low cost of change
  • Is based on just-in-time planning principles
  • Reduces mismatch between initial business requirements and the final product
  • Is likely to produce delighted customers
  • Encourages fast and frequent customer feedback
  • Decisions wait till the last responsible moment (LRM)
  • Promotes high collaboration with the Product Owner

Learn Agile Scrum with my complete handbook, The Basics of SCRUM.

Please follow and like us:

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:

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: