WATERFALL

Waterfall Challenge: Delivery of Business Value

• Realization of value –Value does not become visible to the customer until some of these features start being tested, and we are well far away in the development cycle (month 10 typically)

• It is not until the system is deployed that we see this value being realized (month 12)

Waterfall Challenge: lack of flexibility

• Change in requirements – waterfall is based on the theory that all requirements should be defined up-front. In reality:
  • More requirements are discovered in Design => Analysis rework
  • More requirements are discovered in Build => Analysis + Build rework
  • More requirements are discovered in Test => Analysis, Build and Test rework

Waterfall Challenge: Critical issues addressed late

• Major risks aren’t identified and mitigated early
• Value to the customer isn’t realized until the end of a project
• Change isn’t easily accommodated
• Quality is often compromised to meet deadlines
• Defects and integration issues are found very late in the project
• All requirements are delivered at once, instead of being phased by priority

AGILE

• Benefits

  • Fast time to market

    • Able to launch high quality product on time due to early and iterative testing
    • Able to deliver most valuable business features early on
    • Able to react faster for evolving requirements due to short feedback cycle
    • Able to deliver with reduced cost of change
    • Able to release software faster to retain the client’s competitive edge

  • Early delivery of customer value –

    The focus on delivering working software early and often , make it easy for the customer to evaluate the functionality and usability of the application and of course to provide feedback

    • Allows for recurring releases that can be either internal or external
    • Prioritization of requirements means the highest value is delivered first
    • Customer sees growing value at the end of each iteration
    • If at any point project is halted, the most critical value has already been delivered
    • Customers may choose to halt a project once key requirements are delivered; thereby saving money
  • Early and frequent testing – prescribes testing within the sprints so that defects can be found and fixed early
    • Testing is performed on each level of granularity (Unit tests, integration tests, automated regression tests,..)
    • Most critical bugs are identified and resolved early in the project, reducing overall cost of project
    • Each iteration is well-tested, allowing for faster delivery of functionality.
    • If at any point a project is halted, functionality built to-date can be deployed and released.
  • Transparency and visibility – promotes transparency through the involvement of stakeholders on day to day operations. They would be part of stand-ups, reviews and retrospectives.
    • High level of transparency and visibility through various meetings and artifacts:
      • Backlogs, daily meetings, burn down chart/burn up chart, iteration reviews, client involvement
    • Provides more control and feedback to all interested parties.
  • Early risk identification and mitigation – the iterative nature of development attempts to address risk early in the development process. As iterations aim to deliver working systems as early as possible, performance and acceptance testing can begin early in the process to further mitigate risk
• Agile Drivers
  • Accelerate time-to-market
  • Alignment between IT and business needs
  • Manage change in priorities
  • Improve project visibility
  • Reduce project risks enhance software quality
  • Increase productivity
  • Improve inspection and adaptation feedback loop
• Potential Challenges of Agile
  • Cross functional and self-managed teams
    • Changing the mind-set of the team and encouraging them to self-managed is one of the biggest challenges
  • Availability of business users
    • Business users should be available for clarifying the requirements, participating in the reviews etc.. this involvement would be mucho more than waterfall projects
  • Adopting agile in larger teams
    • Agile methodologies depend on effective face-to-face communication and are, therefore, best suited for small teams.
  • Adopting agile in distributed delivery
    • Since agile methodologies place a strong premium on co-located face-to-face communication, distributed teams create significant challenges.
  • Contracting agile on fixed price projects
    • Contracting agile on fixed price may be very challenging since agile allows for evolving requirements
  • Some organizations may not be ready
    • Sometimes for cultural, historical, or political reasons. Realistically assessing an organization’s readiness for Agile methodologies is key.