As a freelance project manager, I was involved in many projects. A lot of teams are using the term Agile but are working in an “Inter-Sprint Waterfall” or “Intra-Sprint Waterfall” process. In this article, I will explain the difference between “Waterfall”, “Inter-Sprint Waterfall”, “Intra-Sprint Waterfall” and “Agile”
What is Waterfall?
First introduced by Dr. Winston W. Royce in a paper published in 1970, the waterfall model emphasizes that a logical progression of steps be taken throughout the software development life cycle (SDLC), much like the cascading steps down an incremental waterfall. While the popularity of the waterfall model has waned over recent years in favor of more agile methodologies, the logical nature of the sequential process used in the waterfall method cannot be denied, and it remains a common design process.
Find below the 6 stages of Waterfall.
Requirements: During this initial phase, the potential requirements of the application are methodically analyzed and written down in a specification document that serves as the basis for all future development. The result is typically a requirements document that defines what the application should do, but not how it should do it.
Analysis: During this second stage, the system is analyzed in order to properly generate the models and business logic that will be used in the application.
Design: This stage largely covers technical design requirements, such as programming language, data layers, services, etc. A design specification will typically be created that outlines how exactly the business logic covered in the analysis will be technically implemented.
Coding: The actual source code is finally written in this fourth stage, implementing all models, business logic, and service integrations that were specified in the prior stages.
Testing: This stage, QA, beta testers, and all other testers systematically discover and report issues within the application that need to be resolved. It is not uncommon for this phase to cause a “necessary repeat” of the previous coding phase, in order for revealed bugs to be properly squashed.
Operations: Finally, the application is ready for deployment to a live environment. The operations stage entails not just the deployment of the application, but also subsequent support and maintenance that may be required to keep it functional and up-to-date.
High-level overview of the Waterfall process:
What is Inter-Sprint waterfall?
An “Inter-Sprint Waterfall” looks like this: In one sprint, the business product owner, probably a business analyst and visual design team (UX/UI) are working on the “What” needs to be built. Since they are working “Agile”, they adopt some agile process. Requirements will be documented in user stories. The user stories are not treated like real user stories but more like mini-specification documents (or longer). The mini-specs/user stories are nearly conceivable about a given user story.
The whole sprint 0 is consumed to figure out and document the user and technical requirements. Grooming sessions are conducted, visual designs created, UX flows and style guides are created. A second sprint is added to develop the new features. Several documents are handed over to the programmers. Visual designs, spec documents, UX flows, etc. No programming can start until all defined artifacts are delivered. The programmers take an attitude of saying that they will build everything that is asked for. Some team members are sometimes a little more agile and develop all mini-spec before a user story is completed. Other team members think it is dangerous to work in an agile way.
The third sprint is used in some organizations for testing purposes only. In the Inter-Sprint Waterfall method, the test team is working 1 sprint behind the programmers. Fortunately, most teams realize that developers and testers need to work in the same iteration. They do not extend this to the whole team.
This leads to the process shown in this figure.
This figure shows a first iteration devoted to design. A second iteration (possibly slightly overlapping with the first) is devoted to development. And then a third iteration is devoted to testing. It might be your organization’s first step toward becoming agile. But it’s not agile.
What is Intra-Sprint waterfall?
People who used to work in an extensive waterfall development environment, and who are new to agile, often think that a sprint is a mini waterfall. It is not!
“We tried Agile/Scrum but it didn’t work”.
The team tried an iterative waterfall development approach. Same mistakes as described in the “Inter-Sprint Waterfall method” were made. User stories are too complex.
An “Intra-Sprint Waterfall” looks like this: In one sprint, the business product owner, probably a business analyst, and the visual design team (UX/UI) are working on the “What” needs to be built. Since they are working “Agile”, they adopt some agile process. Requirements will be documented in user stories. The user stories are not treated like user stories but more like mini-specification documents (or longer). The mini-specs/user stories are nearly conceivable about a given user story.
Once the requirements are done, the team will start developing during the defined time box. If the development is finished, that test team will do the validation within the same timebox.
This approach might work if features are prioritized and time-boxed. A strong definition of done and to not deliver features that are incomplete.
What is agile?
Agile is a specific project management methodology, most often used by software developers and engineers. This Agile project management methodology is a time-boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. Traditional project management techniques focus on achieving identifiable milestones using complex scheduling tools like Gantt charts. It works by breaking down projects into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles, called iterations.
Ideally, in an agile process, all types of work would finish at the same time. Constant feedback from the end users is asked to help developers and the product owner defining functionalities that would be integrated into the succeeding builds. The teams are Cross-Functional teams and work on interactions of a product over a time-boxed period. The work is organized into a backlog that has been prioritized based on the feedback of the clients’ needs. The backlog serves to constantly remind each team member that the goal of each iteration is to produce a working product.
The team would finish analyzing the problem at the same time they finished designing the solution to the problem, which would also be the same time they finished coding and testing that solution. Multiple features are analyzed, developed and tested by the cross-functional teams and are time-boxed. At the end of the iteration, a demo is held. The client is able to provide fast feedback. Based on the feedback, changes can be implemented and moved into production.
Agile management is not always the best choice for every industry, especially those involving long-term, complex decision-making processes. Agile allows managers and team members to make quick tweaks and adjustments. Problems caught before they progress too far or affect other areas of a project save a great deal of time and help businesses stay faithfully within budget.
The complete picture ‘Waterfall” vs “Inter-Sprint Waterfall” vs “Intra-Sprint Waterfall” vs “Agile”
So what methodology would you use?
There is no need to say which methodology is better. You can choose the one that is the best for your project.
Take as much advantage as possible of what you know. Then you would take an iterative, trial-and-error-and-learn approach to find the best methodology.
Rob Gielen