The basics of waterfall and agile software development processes

• Published on March 23, 2015

Matthew Whetton

Chief Technology Officer at Oakbrook Finance

10 articles Follow

A basic understanding of software development practices can really help when starting a software development project, in particular agile software development. Even if you’re not the person managing the project having this basic understanding will aid both you and your software development team in delivering the right solution.

This post will take a brief look at both the agile and waterfall methods of software development explaining what they are at a high level, and the pro’s and con’s of each approach. I’ll also briefly touch on where the lean start-up methodologies fit in.

Post originally featured on itsmonkie.co.uk

Waterfall software development

Broadly speaking, up until the early 2000’s the prominent software development methodology was waterfall software development. That’s not to say it was the only methodology, or that people weren’t practicing other approaches, but more to say that in general waterfall was the ‘go-to’ approach.

So what is waterfall?

The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Requirements, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance (ref wikipedia waterfall).

The key point in this model is that everything has to go though certain gateposts before it can proceed to the next step. So before you can start analysis requirements must be signed-off, before you can start design analysis must be signed-off and so on. Oftentimes the actual steps involved may be different (i.e. analysis might be combined with design etc), but the underlying principle of signing off gateposts is always there.

Whats good about waterfall

The big benefits with waterfall revolve around the fact that the planning is far more strict and completed early in the process.

• Planning: As the planning is completed largely up front its much easier to work out when a project will be completed, how much it will cost etc.

• Requirements: Given that the requirements are signed-off early in the process, designing the product can be simplified somewhat. Furthermore clients have a better idea of what to expect.

• Documentation: Detailed documentation can provide security to a project as less knowledge is ‘in peoples heads’. So if questions arise around why certain decisions have been made or a team member leaves, they’re easily resolved

Problems with waterfall

Waterfall has really waned in popularity in the last 15 years, as the agile software development movement has taken off. Agile was designed to address specific issues with the waterfall process, namely

• Requirements: It requires that all requirements be known up-front which is rarely the case on software projects.

• Change: Requirements often change during the project as the software itself evolves and gets used – this is not catered for in waterfall.

• Quality: Testing is often the first thing to be cut, as it is usually the last step in the process. This can result in poorer quality software.

• Visibility: As the product is normally not available until the end of the project, its hard to know if its what the customer is expecting.

• Risk: The risks are much alrger as things don’t really get tested until the end of the project.
  Ref: Agile vs Waterfall

Whilst all of these issues do exist within the waterfall model of software development, its really important to note that it is still in use, and works well in certain circumstances. For example, small projects with fixed budgets are often approached using the waterfall methodology, or projects that require strict adherence to legislation or regulations.

Agile software development

The agile software development movement started to really gain popularity after the establishment of the agile manifesto in 2001. Agile focuses on the problems with waterfall development and promoted evolutionary development and adaptive planning to deliver better quality products, that meet customer needs better.

So how does agile work

There are numerous agile methodologies such as scrum and extreme programming that approach the challenge in slightly different ways. Right now Scrum seems to have the highest rate of adoption, perhaps because it provides a solid balance between the managing changes in requirements, whilst maintaining some level of long term project planning.

Ref: Agile project management in Visual Studio (Agile Methodology Adoption Rates)

Each methodology addresses the same issues in different ways, by

• Delivering working software early and continuously integrating that software into the product

• Allowing for changes in requirements

• Inclusion of product owners throughout the process

• Focus on conversations rather than documentation

• Shorter software development cycles

For example, scrum focuses on creating a backlog of features, then delivering each of those features in short ‘sprint’ cycles at the end of which something is delivered and visible to the product owner (roughly speaking). Scrum puts emphasis on having conversations with product owners, delivering only what is required and continually integrating those deliverables into the product.

Clearly I’m glossing over the details and nuances of the scrum processes, but the rough principles are there!

The benefits of agile

Agile works really well in most software development projects, if applied correctly. The real benefits come from its focus on delivering working software early and constant engagement with product owners:

• Risk: Risk can be reduced significantly as a project that is veering off course, or a solution that is not fit for purpose can be caught much earlier.

• Transparency: Agile promoted greater transparency with product owners are involved throughout the process.

• Fit for purpose: Given that the agile process allows for changing requirements throughout the project, the end result is usually better fit for purpose.

• Quality: Constant testing and integration ensure that bugs are caught and dealt with much earlier.

• Less wasted time: Less time is wasted on designing unneeded features, pre-optimization where it is not required and extensive documentation rather than conversations.

The problems with agile

Reading the list of benefits it may seem like a no-brainer to adopt an agile development process, and in most cases it is, but there are significant disadvantages and issues associated with the agile process.

• Long Term Planning: It can be very difficult to plan long term for time, cost and resources in agile projects as the scope of the work to be completed can change frequently.

• Business Engagement: Having active business engagement is critical to success in agile projects, but can often be very difficult to achieve.

• Requirements: Sometimes allowing requirements to change during the project gives rise to poorly defined requirements or no requirements at all.

• Testing Resource: Given that testing happens throughout the project, having dedicated testers is required.

• Design and Architecture: There can be a lack in focus on good design and architecture in most agile methodologies which can result in a poor code base.

• Developer motivation and burnout: There is some criticism that agile processes can be quite intense and cause developers to burn-out. There is also some feeling that any heavily structured approach stifles developer creativity.

This does seem like a pretty damning list of problems with agile, but most are as a result of improper implementation of the process. For example the argument around design and architecture is often caused by an unwillingness to refactor existing code – but refactoring code is absolutely essential in an agile team.

Implementing an agile process into a company that is more used to a typical management approach can be difficult, but the rewards can be incredible.

What to choose

In general choosing an agile approach should always be the first choice, but there are situations where a waterfall approach is either neccessary or preferred, for example:

• Fixed rate development projects are almost always going to require up-front requirements and design, and therefore a waterfall approach.

• If budget and/or time are absolutely the most important things and are under extremely pressure then waterfall may be preferred. (Be careful here though, this often means at the sacrifice of something else)

• If sign-off is a very bureaucratic and drawn-out process, waterfall may work better – as is the case in some highly regulated industries.

Other than that I’d always choose agile, as it delivers better results and is realistic about the process.

Where does lean start-up fit in?

One thing I thought I should mention is the lean start-up and how its influencing software development practices. To be clear:

• The lean start-up is not a software development methodology in itself.

• The lean start-up is not only applicable to start-ups (contrary to the name)!

That said lean start-up methods tend influence the software development approach throughout, rather than in the middle of it. It is also very clear that it fits in very well with the agile mentality of delivering early and often.

Ref: lean startup methodology simplified

All in all the lean start-up parts are more about choosing what to develop, when to deliver it and how to learn from it, rather than the details of how that process should be managed.

So you don’t need to choose between agile and lean, but more make them work together.

For more insights and industry updates visit itsmonkie.co.uk

https://www.linkedin.com/pulse/basics-waterfall-agile-software-development-processes-matthew-whetton/

CONFIDENTIALITY / COPYRIGHT NOTICE: This site and my information and any attachments contains the PRIVILEGED AND CONFIDENTIAL INFORMATION of Fred Finkelstein & Irondesigner DBA / LLC mutually, Inc., its affiliated corporations or legal entities, and is intended only for the use of the individual(s) named above. If you are not the intended recipient of this e-mail or invited to this site, or the employee or agent responsible for delivering this to the intended recipient, you are hereby notified that any unlawful interception, dissemination, disclosure, printing or copying of this e-mail or site or any attachments is strictly prohibited under the Electronics Communication Privacy Act (ECPA), 18 USCA 2510, 18 USCA 2511, and any applicable laws. If you have received this e-mail or viewing this site in error, please delete or destroy it & close down, including all attachments or copies, and immediately notify us by e-mail at mechanicalengrg@gmail.com