An Iterative Waterfall Isn’t Agile
The success of a software development project is closely tied to the chosen development approach. Waterfall and Agile are two of the most popular SDLC methodologies in the present. As such, development teams might find themselves asking the question, which one to choose? Both Agile and Waterfall methodologies are mature approaches to software development. Although the two share a few similarities, both SDLC models are different in several aspects. So, one should keep these in mind while making the pick amongst them. Before setting out to explore the various dissimilarities between Agile and Waterfall methodologies, first, let us take a closer look at what they are and what are their strengths and weaknesses.
The iterative waterfall begins with a sprint that is dedicated exclusively to deciding what needs to be built, which is done through user stories. In this case, though, the user stories become “mini-specification documents” that go on for multiple pages and into excessive detail. Then the second sprint becomes about designing the user interface for the user story. Following this, programmers receive two documents, one detailing what the story should look like and the other providing the context for its behavior. Testing and Coding tend to at least coexist, but they still become the third sprint in a weird-looking project. Cohn notes that such a process could very well be the beginning of a business’s journey to becoming agile, but it is not agile in itself. Ideally, in an agile process, all types of work would finish at exactly the same time. The team would finish analyzing the problem at exactly 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. All four of those disciplines would all finish at exactly the same time. It’s a little innocent to assume a team can always perfectly achieve that. But it can remain the goal a team can work towards.
A team should always work to overlap work as much as possible
- An iterative waterfall looks something like this: In one sprint, someone figures out what is to be built. Because they’re trying to be agile, they do this with user stories. But rather than treating the user stories as short placeholders for future conversations, each user story becomes a mini-specification document, maybe three to five pages long. And we saw them longer than that.
- These user stories document nearly everything imaginable about a given user story. Because this takes a full sprint to figure out and document, a second sprint is devoted to designing the user interface for the user story. Sometimes, the team tries to be a little more agile by starting the design work just a little before the mini-spec for a user story is fully written.
- Many on the team will consider this dangerous because the spec isn’t fully figured out yet. But, what the heck, they’ll reason; this is where the agility comes in. Programmers are then handed a pair of documents. One shows exactly what the user story should look like when implemented, and the other provides all details about the story’s behavior.
- No programming can start until these two artifacts are ready. In some companies, it’s the programmers who force this way of working. They take an attitude of saying they will build whatever is asked for, but you better tell them exactly what is needed at the start of the sprint.
- Some organizations then extend things out even further by having the testers work iteration behind the programmers. This seems to happen because a team’s user stories get larger when each user story needs to include a mini-spec and a full UI design before it can be coded.
- Fortunately, most teams realize that programmers and testers need to work together in the same iteration, but not extend that to being a whole team working together. In traditional, full waterfall development, a team does all of the analysis for the entire project first. Then they do all the designs for the entire project. Then they do all the coding for the entire project. Then they do all the testing for the entire project.
- The team is doing the same thing but they are treating each story as a mini-project. They do all the analysis for one story, then all the design for one story, then all the coding and testing for one story. This is an iterative waterfall process, not an agile process.
- Ideally, in an agile process, all types of work would finish at exactly the same time. The team would finish analyzing the problem at exactly 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. All four of those disciplines would all finish at exactly the same time.
- It’s a little innocent to assume a team can always perfectly achieve that. But it can remain the goal a team can work towards. A team should always work to overlap work as much as possible. And upfront thinking should be done as late as possible and in as little detail as possible while still allowing the work to be completed within the iteration.
- If you are treating your user stories as mini specification documents, stop. Start instead thinking about each as a promise to have a conversation. Feel free to add notes to some stories about things you want to make sure you bring up during that conversation. But adding these notes should be an optional step, not a required step in a sequence process. Leaving them optional avoids turning the process into an iterative waterfall process and keeps your process agile.
The Agile and Waterfall methodologies are distinct forms of software development methodologies. Hence, each of them is great in some scenarios while impractical in others. Software development projects that have evolving or uncertain requirements are ideal to be completed using the agile methodology. Contrarily, smaller software development projects with definite requirements find the Waterfall model to be the best pick. We hope that the aforementioned comparison will make it easy for you to make a selection among the two popular SDLC models. Wish you all the very best with your software
For more Blogs: https://blog.scrumstubs.com/
Aleph Technologies is a premier IT training and staffing group with state-of-the-art facilities based in Dallas, Texas. Aleph Technologies specializes in providing hands-on classroom-based and onsite IT certification training courses taught by expert instructors with practical industry experience. Classes span focuses on Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on Certified SCRUM Master, Scaled Agile Certifications in Dallas, and leadership roles in Agile development. Since 2000, over 3000-course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. We guide you through your Agile Transformation