Another item of note is how well-suited agile is (and how poorly suited waterfall is) to cloud development in general. It seems that all of the significant cloud providers are releasing new features almost monthly. The only way to stay current and take full advantage of these features is by having the flexibility to adapt your code quickly and efficiently, which agile allows.
Engagement is king
Another key benefit of agile is that it favors flexible, collaborative communication throughout the process. What this brings along with it is a level of engagement that is not possible with a waterfall approach.
The product owner and other "customer" resources are intimately involved from the onset. This higher level of engagement, as it is not optional, always alleviates the lack of customer involvement in a waterfall project. Furthermore, the product owner is responsible for making decisions that affect all stakeholders, giving everyone representation, if not an actual seat at the planning table.
Couple this level of engagement with the iterative nature of having short development sprints, and the customers and stakeholders have no choice but to stay engaged, as they are seeing working software and providing detailed feedback after each sprint.
Because every developer is also a tester, quality assurance is built into the agile process from the beginning. This is part and parcel to the concept of delivering working software at the end of each sprint. "Working" means that the software has been developed and tested with the appropriate rigor and thoroughness ... and that happens for each feature of each sprint.
Indeed, no feature can be marked "complete" until it has been fully tested and is ready for release as part of the "end of sprint" delivery. This does not constitute anything close to User Acceptance Testing (UAT), a requirement in many companies. We will address that as a concern in Part 2 of the series.
By definition, agile projects start and end at a certain time. By definition, agile projects do not, and should not, allow for a "push to release, also known as a "death march," scenario.
If you know how many sprints you have in a release, how many resources you have on the project and the cost for each of those resources, you can predict, with relative certainty, the cost of the project. The way this phenomenon is enforced is through the concept of "Next Release" (see below).
Hiring and training new developers is hard. Most folks prefer to keep the ones they have. If you have spent any time around developers, you know that the ones who produce the best code are usually a bit more "high maintenance" than those that do not produce the best code. If you are lucky enough to attract those top-tier developers, it is always in your best interests to keep them happy.
Sign up for MIS Asia eNewsletters.