As I have been around many projects, iterative doesnt seem like the only option practictioned across every section of the software business. As much as iterative feels natural in virtually any startup environment I have taken part of, it still fails regulatory requirements of finance or medical – both which I had to experience first hand.
As one can observe continual efforts in improving both software development paradigms, however "agile" and "waterfall" are typically presented in opposition to each other.
Larger, more critical projects tend to require more architecting investment typically practitioned in waterfall methodologies. The evidence provided across decades of data on the degree of increase in software cost-to-fix versus delay-of-fix is that for large projects, the increase from fixing requirements changes and defects during requirements definition to fixing them once the product is fielded continues to be around 100:1. However, this ratio can be significantly reduced by higher investments in early requirements and architecture verification and validation - which typically are the resons for investing in some sort of waterfall development model. The key concept of waterfall software development follows v-model and consists of distinct phases: a) business analysis, b) requirements engineering, c) detailed design, d) software implementation (coding), e) software verification (testing).
Smaller projects, where requirements are minimal and evolving, typically benefit from one of the forms of iterative development (commonly referred to as "agile"). In fact, iterative software development is the development of a software system through repeated cycles (iterations), in smaller portions at a time (increments). It allows developers to learn from previous iterations and make changes to future iterations. The key concepts that form the foundation of all modern agile software development methodologies include a) smaller portions, also called limited scope. These help contain complexity and reduce risk. b) Early feedback by learning from previous iterations and apply changes to next iterations. Early feedback helps correct costly decisions and implementations early on in the process. c) Delivering more functionality through repeating development cycles.
There seems to be no "one size fits all" approach that would universally represent the best approach to all projects. Is there any way of combining the best of both worlds to satisfy business requirements in terms of predictability, scalability, agility and compliance at the same time? In case of many projects, it seems like they would not fall directly in any of the ends of the scale of small (and evolving) or large (and stable). How about approaching software development lifefycle with a combination of waterfall and agile practices – essentially encapsulating warterfall proces development proces as a set of agile sprints? Each sprint composes of sprint planning in a form of business analysys, feasability study, software estimation and breakdown, development and testing?
Combining agile with waterfall means being able to deliver smaller portions allows the user to be involved in testing and acceptance during each increment and thus provide valuable feedback. Frequent feedback that can be incorporated during next iterations is invaluable during software development. Being able to incorporate feedback and apply corrections adds lots more flexibility during development. However, the phases of the waterfall were all repeated for each iteration. You can think of the "iterative waterfall" model as a set of smaller waterfalls. As a result, the entire project has a lot less risk because each part is shorter and less complex.
If you think about it there's more to agile than iterative delivery. Agile software development is various approaches to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change. The change itself however can undergo more formal approach where investing in early investigation of complexity by formal estimation and specification can reduce the risk of missing the deadline of each iteration.
Combining agile with waterfall requires more generalist approach to software, which is typically referred to as "dev-ops". The agile waterfall development model delivered with more generalist approach pushes at the boundary of the classic phases of the software delivery model. Detailed requirement definition, normally performed during planning and analysis, has moved from complex diagrams to the code itself. Integration and testing have also become part of the implementation phase as they have been automated. And what about the actual delivery of software? Well, it’s been simplified. Now you can deploy working software frequently with a few steps, or even through complete automation.
- Comments
- Leave a Comment