Waterfall and agile, and getting the basics in place first (Part 1)
What is this about and why is it important?*
This article is about two different models for dealing with project scope. (In this context, a model is a broad idea we have of the way in which things should work.) Seen from a different perspective, these models also provide different ways of dealing with people in projects.
There are other models too, but for now we’re sticking to two models, waterfall and agile. This is to keep things simpler as we draw insights from the comparison.
The topic is important, because your choice of a model (and your choice of a framework or methodology to implement your chosen model) changes the way you run your projects. It determines the way you manage time, cost and change. Your model needs to fit the types of projects which you’re doing, and the culture of your organisation.
That last point (the one about culture) brings us to a crucial aspect which many people don’t understand well enough when they try to get some new ‘system’ going based on a particular model. The environment where you want to implement the new ‘system’ must already possess certain enabling characteristics by the time that you start implementing it. (At the end of the article, we’ll touch on some of those characteristics.) Without an enabled environment, the new approach will fail to achieve its goals.
Most of the italicised words in this article are defined in the Project Management Concepts course.
Caveat
This article does not do justice to the complexity of the subject. For example, some people will say that the clear line between the realm of Project Management and that of specialist work does not or should not really exist. The article therefore relies on a certain meta-model to make its point, and this meta-model is open to debate.
The Project Management lifecyle and the SDLC
The waterfall and agile models are used in the context of the SDLC. (SDLC is the acronym for Software Development Life Cycle. Some people use SDLC for Systems Development Life Cycle.)
The core principles addressed by these models also apply to a variety of other types of projects, so it’s important for Project Management people who don’t work in software to be aware of them too.
In his book Effective Project Management, Robert K. Wysocki explains that the Project Management Lifecycle and the SDLC run parallel to each other, with the phases linking into each other. What he’s talking about is the relationship between
- managing the project (dealing with a wide range of stakeholders, risks, costs, the procurement of services, etc.), and
- managing the specialist work to create the project’s deliverables.
What is ‘specialist work’?
In the context of software development, the specialist work is typically done by systems architects, software developers, front-end designers, testers, and so on. These are the people whose work delivers the scope according to the quality requirements.
In a construction project, the specialist work is done by architects, engineers, building contractors and various others.
When a project is simple, this is all that we need: specialist work. We need management, but we don’t necessarily need Project Management. The discipline of Project Management becomes necessary when there’s greater complexity or risk in a project, including a greater number of stakeholders who need to be considered.
Parallel but not equivalent
Although the Project Management lifecyle and the SDLC run parallel to each other, the major phases of the Project Management lifecycle do not ‘line up’ precisely to the major stages of the SDLC.
However, the phases of these two lifecycles do influence each other. The sketch below shows a basic Project Management lifecycle mapped to a basic SDLC.
The various Project Management frameworks and methodologies list stages or phases which may differ from the four illustrated at the top of the drawing, although they usually contain some similarities.
Likewise, the different SDLC models also list stages or phases which may differ from the ones seen in this drawing, but they will also be similar in some ways.
In this article, we use the term phases to mean the major sequential realms of activity in a project.
Some Project Management people divide phases into stages. Some use stages as synonymous with phases; yet others use stages to designate Project Management activities, dividing specialist activities into phases (e.g. “We’re finishing Phase 2 of the housing estate now.”).
Waterfall and agile: what’s the difference?
Remember, when we’re talking about waterfall and agile, we’re talking about different models for the Software Development Life Cycle, not for the Project Management lifecycle.
The waterfall model says that at the start of a software development project, you should make up your mind exactly what you want, so that the specialists can get down to their work. If you come along with changes along the way, you’re messing people around, and the deadline and cost are going to suffer. The framework or the methodology which you use to manage your waterfall lifecycle must therefore have good procedures in place for containing scope and preventing scope creep.
The typical phases of a waterfall project are shown in the sketch above: find out what people want, design the system, develop and test the system, get users to test it, install it, then provide maintenance and support.
The waterfall model is linear-sequential. This means that you are supposed to go through these major steps in sequence, from beginning to end.
The agile model says that at the start of the project, people may not be able to figure out exactly what they need or want, and what could work. They may also prefer to have something that “sort of works”, rather than having to wait for a long time for some perfect system which they can’t even imagine yet. The agile model accepts these uncertainties, so it allows for a lot of change along the way.
Considering that change is a given, it wouldn’t be logical to start off with a fixed deadline and budget (although there should be a system for preventing time and cost from running to crazy amounts). The agile philosophy values frequent interaction between the people who want the new system, and the people in charge of the specialist work.
Unlike the waterfall model, the agile model is not linear-sequential. It is iterative and incremental.
In this context, iterative means that several times in your project, you cycle through the same series of major steps. Each cycle is called an iteration.
Incremental means that you keep adding something that can be put to use while the project is in progress.
Here is the Web site of the original Agile Manifesto, written nearly 20 years ago.
Lessons from models for software development
SDLC models provide inspiration for managing specialist work in a variety of project contexts. For some time, people in advertising, publishing and various other industries have been drawing from the agile model to develop structured processes for projects which require creativity and flexibility.
This brings us to the end of Part 1, and so far, things are looking rosy. Now let’s get scared: here’s Part 2…
* We owe some aspects of the structure of this article to Richard Newton, author of The Project Management Book. Every chapter of Newton’s book begins with What is this about and why is it important? and ends with tips for project managers.
