Agile and Waterfall methods for SaaS, Application, and website development in an agency setting

Brandon Blais I started writing a longer post to answer your question about my thoughts on agile based on the build process flowchart I designed for JHMG from this post:

My response was too long for a comment to respond to you, so I wrote it here.

I'm going to break this up into two different kinds of projects, a website and an application / SaaS offering.

Website Projects

For the website, you can put it onto a more agile framework than what I have in the chart. But the process is pretty similar to what you're going to start with because most of the time the stakeholders want to have something to show sooner than later and agile processes are often employed with ongoing work where features are constantly being deployed and bugs constantly fixed. Whereas in a website project, you're expected to have all features wrapped up and bugs fixed within a fairly set time period. So you're going to end up with a more waterfall approach to start, then move into an agile process (the CI/CD process shown at the bottom left of the flowchart) post-launch as noted below:

Also, on purely website projects, if you have an experienced team, you almost always have a pretty clear scope of work to start. So a purely agile project isn't often needed, and in my opinion will often waste money. If you want to learn how to build a great estimate (not a SOW, just an estimate) here's a link to an article I wrote on our large project / SaaS build estimation process.

Agile Method Application In Website Projects

That said, the areas you could or would break into agile processes for a website would be each major section of the build - SOW development, content, design, and development.

For each, you could set up an agile process and run sprints, although, for content, you're almost certainly going to be on a kanban since what needs to be completed should be straightforward to gather specifications and complete. I'm not saying it couldn't be agile for this area, just that I haven't had many (any?) experiences where it needed to be.

Larger Website Projects

Even for larger website projects (for me, projects at over 300 pages, not including the blog or other similarly templated pages), I usually run a waterfall method for the initial development of the system then move into the CI/CD and ongoing marketing and analysis portions.

But that said, if you had a website project that was very large, in the thousands or tens of thousands of pages which is going to take a substantial amount of time to complete and will have a release cycle, then I think agile method would be the way to go.

The key here is that a very large website like this would have a release cycle, where you would release some features or pages at certain intervals. But, in order to do this, you would almost always still have some basic system live first, which you built on at least a semi-waterfall/mixed method.

If you don't have a release cycle then the build team would, in essence, be building on a monolithic release cycle and would be missing the whole point of the agile method. If you want to see what happens when you do this, take a look at my post on managing a failed release.

Building on a monolithic release cycle is the starting point for a failed release. - Jason Long

Application / SaaS Offering Development

I mention SaaS Offering Development because that's what we do a lot at JHMG . It's similar to application development from a dev perspective, but there are so many other things that go into it because we assist in building businesses, not just applications.

Getting to MVP

For these kinds of projects, the stakeholders still need to get to a launch point in a somewhat known amount of time. What we often do here is present an estimated number of cycles before we expect to have an MVP or MVSP (minimum viable sellable product). So even though you're on an agile project, you still have some constraints that often make it a more mixed method than a true agile method.

Post MVP/MVSP

After the MVP/MVSP has been released and there are users on the system and/or revenue is being generated, then we can move into a more 'true' agile process.

Waterfalling Into CI/CD

The way I think about this insofar as the flow chart is concerned is that the top Build Process areas (waterfall process), the Continuous Marketing and Analysis section, and the Project Success are all part of the CI/CD section. They all flow in together.

The CI/CD area IS THE AGILE PROCESS.

Here's how the Build Process and Marketing & Analysis areas flow into CI/CD:

For the Project Success areas, here is how that flows into CI/CD and the Continuous Marketing & Analysis area, which flows into CI/CD:

In the agency world, we move from Waterfall to Agile because we have to

In conclusion, the waterfall areas are a part of CI/CD, but in the agency world, we are often held to deadlines for the initial build of applications and thus need a mixed model instead of a purely Agile method to meet customers' requirements.

After that has been accomplished, then we can move into a true Agile model, or more often than not, we help the customers source their own developers, product owners, designers, department heads, etc. so they can run independently from us, which they will need in the long-run anyway.

If you want to learn more about this kind of thing on a regular basis, jump on my SaaS email that I send out weekly (or close to it).

I hope this was helpful! Please let me know if you have any further questions!