Waterfall vs. Agile (Part 2): Development and Business

We saw in the previous article the main differences between agile and waterfall. In the following articles we are going to take a deeper look by focusing on the four main actors in software development: Development, Business, QA, and Management. This article will start with Development and Business. 

Development

Development is made up of activities (coding, unit testing, etc) and the team members (developers, architects, etc) who are in charge of producing the code of the application. It excludes QA, which will have its own section in the next article.

Architecture and Design

In Waterfall, the Architecture and Design phases are considered the most critical ones.

It encourages the team to create an architecture upfront that will fulfil all the requirements of the application. This focuses a lot of resources and energy at the beginning of the project. 

The main arguments used by waterfallists to try to get the architecture right at the beginning are:

1. The design integrity of the application is unchanged throughout the development.
2. It helps to prevent finding later in development that the architecture is not fit for purpose.

Agile, on the other hand, is based on the assumption that uncertainty is so common and change so large, that no upfront architecture/design can possibly be right or fit for purpose further down the line. Agile therefore takes an iterative, keep it at as simple as possible, refactoring approach to architecture/design.

Integration

Agile has a big focus on integrating the application components as soon as possible (it actually encourages a releasable product by the end of each iteration), and building functionality rather than modules. Agile focuses so much on integration, even though it may be seen as a minor part of software development, because it is usually one of the most troublesome parts.

Waterfall, on the other hand, focuses more on completing technical modules highlighted by the initial architecture/design. This usually causes a lot of trouble and deviation in the plan because of issues related to integrating the components of the application.

Process and philosophy

Agile is philosophically very close to Lean as it promulgates many principles to avoid waste, for instance, having as little documentation as possible. It is also very strong on engineering practices (TDD, pair-programming, refactoring, etc), open door management, and self-managed teams, affirming that the core of software development are the people itself.

Waterfall is more documentation and process oriented. It does not trust people as agile does, but instead provides checks and measures to control them.

Business

The Business in this article refers to all the actors that influence the approval of the final product, and/or in charge of providing requirements to development.

The main difference, from a business perspective, between Agile and Waterfall is the degree of involvement.

In a Waterfall project, the Business provides the requirements at the beginning of the project and sometimes approves the budget and the schedule. At the end of the project, they need to validate that all the requirements have been met.

In agile, the engagement is much bigger. The Business is involved in the development of the application because requirements are gathered and changed on a daily basis. The Business is also required in an agile project to validate the application at the end of each iteration as opposed to waiting until the application is complete.

In the next article...

In the next article (link below), we will continue to look at the differences between Agile and Waterfall from the perspective of the two remaining classic structural areas of software development: Management and QA.

Further Reading

Waterfall vs. Agile: QA and Management