Waterfall, Agile, Scrum… what works for real web projects?

In meetings we hear clients more and more asking for Agile and scrum approaches on web projects.

Sometimes I wonder if they are actually prepared for the outcomes.

Let’s first take a quick step back and outline the definition of these project management types.

Waterfall project management:

The waterfall model is a sequential design process, often used in software (and web) development. The progress flows steadily downwards and steps (like a waterfall) through clear phases e.g. Strategy, Design, Build, Testing, Deployment, and Maintenance.

Good aspects: Secure system. Transparent. There are no surprises.
Bad aspects: Ideally it is perfect but many problems exist with real-life application. Also slow drops.

Agile project management:

Agile software development model is based on iterative and incremental development. Requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive and responsive planning, evolutionary development and delivery. It encourages rapid and flexible improvement.

Good aspects: Quick turnaround, flexible, request driven.
Bad aspects: It requires a high level of trust between client and software developers.
(Why is this bad? Clients generally want control on all the phases of the work. This is not trust.)

Scrum project management:

Scrum is a way to manage agile projects. Its focus is on a flexible, holistic product development strategy where a development team works as a unit to reach common goals. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication via stand up meeting between all team members and disciplines in the project.

Releases are planned with sprints of 1-4 weeks where a series of backlog tasks are moved through all the states of process (open, in progress, testing, resolved, and ready to deploy). At the end of a sprint all improvements and new functionality are merged with the live environment.

Good aspects: Transparency on releases drop. Issues are raised daily. Flexible.
Bad aspects: Team needs to work very effectively together. Releases can change based on issue escalation. Sprints have specific due dates, if a task is not completed it can push the sprint date back or needs to be taken out of the release.

What actually works in web development?

In my experience, agile and scrum are great approaches once the website scope has been defined but the planning stage needs to be waterfall. This is accommodated by a few back and forward adjustments between design and prototype to refine and improve the model.

Finally, once the website it’s live scrum of waterfall are great systems to refine and improve the website in short and effective drops.

The main issue is that clients and web developers have completely different views of what the project will look like at the start. The waterfall approach allows both parties to have a clarity on what needs to be delivered and what to expect. This helps to avoid the unexpected extra costs, and finally deliver the project by the due date.

I like to divide the project into the following 3 parts;

Project scope

Mainly waterfall with a bit of agile back and forward between prototype and design.
This includes:

• Requirement and business objective definition.
• User flows.
• Project plan and risk analysis.
• Prototype and wireframes.
• Design.

Project build

I like to run this with agile firstly and move to scrum in the last 2-3 sprints to ensure the team is motivated. Therefore in the last few sprints we are very clear on what it’s left to complete, so that we can assign tasks to specific releases and drops.
This includes:

• Frontend.
• Backend.
• Testing.
• Deployment.

Optimisation phase

At this stage, client trust is high (if you have done your job). Clients are confident in asking for improvements, bug fixings. Clients also want to see these going live asap, especially bug fixing. More formal and corporate clients usually prefer Scrum with the specific date releases so that they can plan testing in UAT before going live, while less structured clients (e.g. start-ups) are happy with Agile “go live as soon as it’s done” method.
This includes:

• Data analyst.
• User testing.
• Improvements plan which moves to build.