Embedded Files
Differing Philosophies
Differing Philosophies
There is much debate about which is better: a traditional approach to software development or an innovation called "Agile" that came about in 2001. Those who favor the traditional top-down approach will site the many failures of Agile projects. Those who favor Agile might say that the traditional approach is too slow and cumbersome. My philosophy is: No One Size Fits All. What works well for one organization may not work well for another. It depends on the people involved, the software being produced, and the organizational/cultural environment in which the software is being produced. My intent here is not to take sides because organizations with different processes are successful. But I want to at least explain the arguments for Agile.
Shorter Iterations
Shorter Iterations
Whereas Waterfall plans out big projects over many months, Agile attempts to provide small increments of value very often. It's called the "iterative and incremental" approach. The idea is to get completed software into the hands of the users as quickly as possible for rapid feedback on your progress. The picture to the left shows the difference between the long timeline of Waterfall and the shorter iterations of Agile
Smaller, More Frequent Value Increments
Smaller, More Frequent Value Increments
The shorter timeline for deploying value to users means that Agile delivers smaller increments of value sooner. The intent is to improve the feedback loop from stakeholders and users. By getting regular feedback on the progress of the product, the team is able to adjust what is planned for the upcoming increment, thereby increasing the value to the users and stakeholders.
Increased Visibility
Increased Visibility
With frequent deliveries, stakeholders see the progress of the product first hand, rather than waiting for a big bang deployment at the end which may or may not delight them.
Decreased Risk
Decreased Risk
The risk with Waterfall is that the software delivered does not match the expectations of the stakeholders or the needs of the users. By increasing the frequency of delivery and feedback, Agile reduces that risk. With every release the functionality of the software is validated. With every release feedback from stakeholders and users goes into the next iteration of the product. Therefore, by the time product development is complete, the stakeholders know exactly what is being delivered, and they have had as many opportunities of shaping that product as possible. This reduces the risk that the software does not meet expectations. Both the software and the expectations have been modified over time.
Summary
Summary
The increased frequency of delivery of smaller value increments in Agile increases visibility of progress to stakeholders and reduces the risk that the software will not meet expectations. Stakeholders are much more engaged throughout the development lifecycle than in Waterfall. In Waterfall, the stakeholders define the product in the beginning and receive the product in the end. In an organization where stakeholders do not want to be involved in the software development process and are willing to accept the risk that the software does not meet their expectations, then Waterfall can be a better approach. Waterfall can be more efficient that Agile in cases where feedback during the development cycle is needed. It increases risk, but in organizations willing to accept that risk, there may be value in using a more traditional approach to software development.
Page updated
Google Sites
Report abuse