The facetious, arguably provocative and derogatory terminology “Reverse Waterfall” was coined to describe software development practices that begin the Implementation phase before sufficient requirements gathering, business analysis and design are performed. This referred to Implementation phase specifically consists of the developers performing coding and unit testing.

Please note that this terminology is not meant to be a strict reversal of all the sequential steps in the typical Waterfall software development methodology. Additionally, this terminology may be used describe any project’s or team’s software development practice regardless of the purported methodology being used by them - including but not limited to both Agile and Waterfall.

Taking a step back for a second, in traditional Waterfall methodologies, all possible requirements are [attempted to be] gathered at the start of project. This is then followed by phases of design, implementation and then testing. In Agile methodologies alternatively, when a team starts working on a specific story or task, just enough requirements are gathered, and analysis and design performed. Agile methodologies specifically welcome changing requirements, even late in the development cycle.

Regardless of the approach however, and regardless of changes to requirements at a later stage, in order for a working and valuable solution to be developed and delivered (incrementally or not), the following are prerequisites for coding:

1. A minimum set of core business requirements must be known;
2. A minimum amount of business analysis must have been performed to more finely specify required behaviour and functionality;
3. A minimum amount of design (both architecture and component design) must have been performed.

If a team starts the Implementation phase without these prerequisites in place, coding the solution is like building a house without a blueprint and hoping it will remain standing.

The number of businesses that are willing to waste millions of dollars building straw houses quite frankly amazes me. I have seen this happen a number of times in the past when upper management sets a strategic goal and plucks an arbitrary date for software delivery out of the air without having appropriately considered and put in place the following:

• clear core business requirements;
• clear current and future (re-engineered) business processes;
• business event triggers identified in the business processes;
• an information architecture;
• a solution architecture reviewed with a software development team that is an expert in the type of technical solution required, or the team that is likely to actually develop the solution;
• estimations reviewed with a software development team that is an expert in the type of technical solution required, or the team that is likely to actually develop the solution; and
• dependencies assessed and planned;

Software development is not just about coding and testing. When a business sets a strategic goal, a holistic approach needs to be taken. Part of the overall solution may involve the development of software, and the ability to design and develop working and valuable software is entirely dependent on the business first getting their business artefacts in order - starting with their business processes, business events and information architecture.

If these business artefacts are not in place at the start of a software development project, the project will likely stall and in a negative workplace, the software development team will be blamed for the failure of a project. How ironic it is that the business and upper management actually doomed the software development project to failure even before it started!

Reverse Waterfall is madness, but in my experience is all too common in the industry.

Have you had similar experiences? Leave a comment…