This is the traditional waterfall methodology that is widely used for software development on the mainframe.
The approach is top down, flowing like a waterfall. Each phase of the project has to be 100% complete before you move to the next phase of the project.
The argument for waterfall development is time spent early on making sure requirements and design are correct saves much time and effort later. Thus, the thinking of those who follow the waterfall process goes, make sure each phase is 100% complete and absolutely correct before proceeding to the next phase.
The idea behind the waterfall model may be “measure twice; cut once,” and those opposed to the waterfall model argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and new realizations about the problem itself.
Following this approach leads to tremendous frustration for both the development team as well as on the client side. Strict adherence to the principle of waterfall development causes lengthy delays in delivering the project to the client. In Waterfall development, the intent is to deliver the entire project as one deliverable(the big bang) instead of delivering smaller, incremental iterations.
Advocates of Agile software development will argue that the waterfall model is a bad idea in practice and unrealistic to believe that any non-trivial project is able to finish a phase of a software product’s life-cycle perfectly before moving to the next phase of the project.
Agile development focuses on short iterations, delivering the MVP( minimum viable product) to the user. The development team and product team work closely together to determine priorities and what is possible to deliver in a 2-3 week period. The greatest benefit that I see in Agile development is the principle of collaboration between the customer and the development team. Continuous customer involvement is critical to this process. There is very little opportunity for collaboration in waterfall development, which places the stakeholder and development teams in an almost adversarial position.
Agile development is based on twelve guiding principles.
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
Could agile development work successfully in a mainframe environment? It is a complex challenge when you might be working with applications that were developed 40+ years ago and the code is still running. The (DRY) don’t repeat yourself principle was not factored into those applications.
It would certainly take a huge paradigm shift to move away from the tried and true approach to software development in a mainframe shop. For me, I would have liked to have been able to use this approach to software development. The ability to to release smaller code sets would be to mitigate the risk in the “all or nothing at all” approach and would also keep the customer engaged during the entire lifecycle of the project. I have seen the project sponsors lose interest in the project they requested and throw up their hands with a “no mas” as the project withered under endless requests from IT for scope changes to be written, evaluated, approved and adopted. While scope creep needs to be managed properly, the change process should not turn the IT development teams and their clients into adversaries.