Waterfall Development is Not a Bad Word - or When to use Waterfall in an Agile Environment.

Over the past decade, agile software development has grown exponentially across all types of organizations and industries. During this time period, having been involved in several small and large scale agile and waterfall projects involving custom development as well as third party implementations, I found that there are some cases when the traditional waterfall methodology of requirements analysis, design, build and test, is a better choice over an agile methodology like SCRUM or XP.

Implementation with a waterfall methodology doesn't necessarily mean we throw out our agile mindset (now might be a good time to refresh yourself with the agile manifesto), rather it means we still embrace these things by choosing the right development approach, based on the particular job and team.

WATERFALL DEVELOPMENT

AGILE DEVELOPMENT - SCRUM  

So, when is the best time to implement something using a waterfall methodology?

A core approach within agile methodologies like Scrum and XP, is to break effort down into small work iterations, or sprints. These sprints can range anywhere from a few days to a month, but commonly are implemented in 2 week iterations.  The purpose of iterations, is to deal with the ever changing environment and conditions that happen over the course of a project. This enables us to reassess user requirements frequently, preventing situations where a change in our environment resulted in a substantial change to our requirements after spending  months on a design.  But what if there wasn't much change happening?  What, no change?!

One of the primary examples of something that tends not to change, is when the product being implemented is something of a known quantity. This usually occurs in package applications or applications within an organization that have been implemented over and over again with regularity.

Generally in the case of locally installed package or cloud applications, the vendor tends to do some initial planning & analysis with the client to determine the core configuration of the product and it’s necessary infrastructure, and can tell the client how long the implementation & testing should take. In many cases, the vendor can even provide test cases along with test data to validate everything is working.  In cases like these, the teams that implement these kinds of products, generally should not have a need to create a backlog of user stories have daily scrum meetings, and plan things in development iterations as this would likely generate a lot of waste.

In cases where a product may need some significant customization and/or integration, cases where there are a lot of UNKNOWNS, an agile methodology tends to works best, but in cases where the vendor or internal team, has implemented them over and over, most of the variables needed to install or configure a product are well known a simple waterfall methodology should be acceptable. 

In these situations, consider following the vendor’s methodology or internal team's methodology, versus trying to squeeze in an agile methodology you normally use for custom development.

This doesn't mean your infrastructure or architecture teams should only use one methodology, what it means is that you need to match the approach to the job. So it might be possible that in one instance, a team uses scrum or Kanban, and in another uses waterfall.  The key is to determine what's best for the team so that the product can be delivered in minimal time with the most value to the organization.  For example, it's fairly common that large package implementations go awry, but this is primarily the result of treating the core package (known) and customizations AND integrations(unknown) the same. If we implement and test the package's core functionality first using standard waterfall and then treat the customizations and integrations with an agile methodology (stories, backlogs, iterations, etc.), we get the best of both worlds.

Remember, the first tenant of the agile manifesto is: Individuals and interactions over processes and tools. Don't get hung up on the need to apply an agile methodology to everything, apply an agile mindset to everything.

It would be great to hear about your experiences, success and not so successes too.