Agile Zone is brought to you in partnership with:

Alberto has posted 4 posts at DZone. View Full User Profile

Waterfall vs. Agile: Development and Business

06.15.2010
| 22750 views |
  • submit to reddit

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.

Read the other parts in DZone's 'Agile vs. Waterfall' series -

 

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.

Summary table

In summary, the following are the main differences in Development between Agile and Waterfall.

 

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.

Summary table

In summary, the following are the main differences between Agile and Waterfall from a Business perspective.

In the next article...

In the next article we will continue to look at the differences between Agile and Waterfall from the perspective of the 2 remaining classic structural areas of software development: Management, and QA. Please stay tuned!! Same Bat-Channel, same Bat-Time!

AttachmentSize
SummaryTable.png103.34 KB
SummaryTable2.png44.79 KB
Published at DZone with permission of its author, Alberto Gutierrez.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Walter Bogaardt replied on Tue, 2010/06/15 - 11:56pm

This said, what are pros and cons of each based on an organization or project struture. IE Agile would not be good for a space program sending man to the moon or developing a fly by wire system. Web development where we have a product launch in x month Waterfall might not be a good fit.

The key point in software development is that one methodology is not exclusive or inclusive of the other. It's really project and people centric.

Stephane Vaucher replied on Thu, 2010/07/15 - 12:24am

I agree with Walter. The article is really too light to be useful.
Honestly, one of the domains were I can see a waterfall (-like) approach being still relevant is the aerospace industry (as mentioned by Walter) where formal verification methods are employed to verify that the logic of a program does not contain errors. In this case, the code needs to match exactly the form for which the proof of correctness was done. For almost all other projects, waterfall should not even be an option. Actually its adoption was an error. Royce ("original author") mentioned that the waterfall is risky and invites failure.There are many other approaches to development than agile vs. waterfall. 99% of projects should NOT use waterfall. I really do not see why this is relevant unless there is a discussion of the risks associated to waterfall/agile.
Example of risks in agile development: 1. Agile requires a culture shift: adoption of another way to produce software (involvement of business) 2. Agile does not necessarily emphasise traditional large org activities like metrics extractions; effort estimations can be difficult
Example of risks in waterfall: 1. The system will not work as required 2. You will spend all your budget before actually coding

Sri Prakash replied on Fri, 2011/11/11 - 5:03pm in response to: Walter Bogaardt

Here is a comprehensive set of risks associated with Agile development... something I had compile a while ago... http://ecomcanada.wordpress.com/2010/10/08/pitfalls-in-agile-software-development/

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.