Waterfall and/or Agile - Not another blog about this topic

Waterfall software development life cycle vs. Agile methodology ???

Not another blog about this topic; that's probably what you are thinking.

The answer is not as simple, and there is actually no right or wrong answer. The answer is what fits your organization best. I just want to put all the debates aside and describe this from an angle of a software engineer who worked in very different environments for 16 years. I have used waterfall approach and I have used agile approach before the word "agile" even existed in the vocabulary of software engineering.

Some organizations will do 100% of waterfall approach and they could be very successful.
Some organizations will follow scrum 100%.
Most organizations will adopt a methodology that is a mix of waterfall and agile.

What are the areas in SDLC that should be analyzed and dissected to see if you can apply more waterfall-ish or agile-ish approach. They are:
- Requirements phase
- Technical Design
- Execution phase
- Testing and Launch


Let me first address the technical design phase as it is a special case.

Technical Design:

You can see that I purposely crossed out the Technical Design. Whether you do the waterfall, or agile approach, it is crucial that you do the overall technical design before the execution phase starts. Yes, there will be technical design changes as you are developing; that's totally acceptable, but that overall design plan at the beginning keeps you on the right path.

“No battle was ever won according to plan, but no battle was ever won without one.”
–Dwight D. Eisenhower

The most common mistake made in agile methodology is that the overall technical design and plan gets ignored and you start writing a bunch of prototypes that turn into production code.

Therefore, please put effort into the technical design before you write a line of code in your waterfall-ish or agile-ish approach.

Requirements Phase:

The waterfall approach tells you to define all the requirements and lock them down. Is it how it really works in reality. We all know the answer for this. However, the intention is to define everything completely before the execution phase.

The agile approach tells you to have rough idea on what your requirements are but you are defining them and adjusting them as you move from one sprint/iteration to another.

There is another approach to this that allows the product management team define more accurate requirements in waterfall methodology but applying some flavors of agile methodology. It is as following:

Let's assume you are developing a website or changing/introducing new features in your website.
Let's assume you have a platform and/or list of APIs and coding methodologies that allows you to quickly put together a website and with fields on the screen being saved into database.

Instead of having a UI designer doing the designs/wireframes in photo editing tools and generating PSD/JPEG files, you have the following members as part of the product management team close to business:
- designer
- web developer
- possibly even an engineer

This team would work closely with the product management teammates who have the vision on what the product would look like. This team would actually in an agile way build the UI prototypes directly in the code base of the website and the platform.

When this UI prototype is done, you are already a step ahead of the game. This prototype with some minor supplementary documentation becomes your business/functional requirements for the technical design and for the execution phase of your project.

Execution Phase:

You can run the execution phase with a true waterfall approach and that means:

- schedule is followed and there is a set production launch date
- schedule contains each task in the project that you track by percentage complete
- schedule is used to determine the critical path
- you have a lot of tasks happening in parallel and everything falls together into a final product when everything is launched to QA environment for testing.

You can also run the execution phase with a true agile/scrum approach and that means:

- no schedule
- no end date or production launch date can be determined
- current sprint is defined precisely
- demo at the end of the sprint
- you have the backlog of stories
- you have a list of stories that are very high-level and are not define clearly yet.

You may ask: "Why can't you determine the production launch date". The reason why you cannot do this in a true scrum approach is because you building your product from sprint to sprint and you are constantly adjusting what you want as the product.

There is a hybrid approach:

- Based on finalized requirements, create all the stories.

- Product owner does NOT own the stories as the requirements are already determined in the requirements phase.

- All stories in the project are clearly defined and estimated because the requirements are finalized.
- Tech lead picks the stories in the iteration and watches the burndown rate.
- Based on the burndown rate you can calculate your development end date and ultimately calculate the production launch date including the QA estimates.
- Demo the iterations to product owners and possibly accept minor adjustments in requirements if they don't impact the dates.

This hybrid approach allows you to introduce flavors of agile methodology into the waterfall system. The iterations add a little bit of extra cost as you have to prepare the demos as a team.


Testing and Launch Phase:

If you take the best of waterfall and agile, I believe that the QA testing should be fully an on-demand-run team. Without too much planning you can basically run the execution phase in parallel with the testing phase. As the features are being developed, they can be deployed to the testing environment for exploratory testing and the official round of testing can be performed when all of the functionality is implemented and deployed to the testing environment. This basically makes the development and QA team be part of the same team with with same goals to have a stable product ready for launch.

As for the launch strategy, the goal should be to soft-launch to production as much as possible. As the features are being developed, those features can be soft-launched to the production environment; with this approach you are not holding back any code that is ready.


Conclusion:

This is just my opinion on this subject. There is no right or wrong. Different variations of this will work for different companies; it is up to you to find the formula.

Keywords: #waterfall #agile #methodology #SDLC #software #development #life-cycle #lifecycle  
<THE END>