Waterfall Project Management
When you complete each stage of a project in isolation. You can’t move onto the next stage until the previous one has been completed.
Teams may have frequent meetings in the form of monthly boards, where decisions are made by stakeholders, or dial in meetings with team members who may not work in the same office location (e.g. a Tester who works offshore).
A project example would be upgrades to multiple interlinked computer servers. Server one must first be upgraded first before server two can be looked at.
Pros
- Methodical and the traditional method of running projects.
- Works well for projects where there’s one end goal and nothing in between.
- Enables clear investment decision points and reviews at stage ends and also ensures everything is completed before progressing to the next stage.
- (Pro or con!) results in stricter levels of governance as projects need to fulfil specific criteria before being allowed to develop and implement.
Cons
- Slow. A hold up at one stage affects the rest of the chain for the project.
- This also includes potential impacts on dependant projects who rely on other projects for meeting their deadlines.
- This in turn can lead to resource inefficiencies, project overspend and failure to meet to time scales.
Agile Project Management
Instead of aiming to complete whole stages in isolation, Agile projects take a more cyclonic approach, tackling a project delivery in multiple smaller stages (or sprints). Sprints tend to last between two and four weeks.
Teams keep each other informed via stand up Kanban/scrum meetings. An appointed scrum master leads discussions to enable the different teams working on the project provide updates. A) with what they are going to tackle during each sprint (at the start), B) progress updates (during) and C) what they have achieved (at the end). Meetings tend to be more informal and visual compared to Waterfall and the use of whiteboards with post its and/or dedicated software are adopted more frequently to enable updates in a quicker paced project.
An example of an Agile project would be the development of a App. Over the course of multiple sprints teams are able to gradually build and test the App, first with the basic code, then the functionality, then finally adding in user appeal – pictures, sounds etc.
Pros
- Fast moving. Enables teams to quickly identify any faults and either fix or ‘drop’ them before too much money and time is invested.
- Deliveries grow over time, a project leader can start to see formation much earlier into a project, where in Waterfall the change is sudden.
- Considered to be a more resource efficient model and allows for greater collaboration.
Cons
- Agile is not a suitable method for all projects. A single delivery can’t be built over time (for example, the delivery outcome ‘running a marathon’ cannot be done in separate sprints. You sign up, train, then run it. An Agile approach would be useless in this instance – you cannot gradually run bits of the marathon over twelve weeks!)
- The working environment must contain all persons on the project (project lead, governance, software architects, testers, accountants, etc.) to enable collaboration. These resources can only be dedicated to one project or sprint. If resources are split between multiple projects (as they can be on Waterfall) then the sprint may fail to meet its delivery.
- As sprints are quite short and projects adopting Agile are quicker paced, the project lead must ensure that suitable investment and project governance/review points are put in place as the cycle system doesn’t naturally allow for any sudden or prolonged stops.
- As it’s a new methodology of project working, team members may require additional support and/or training.
And there you have it. A (very) quick overview of the two main methods of running projects. I want to add here that I am by no means an expert on either approach, having only started a career in business project management and governance three months ago(!) but hopefully for that reason it will help any new starters in the world get to grips with the basics.
(Also, I hope that doing this will stop Mumma Bennett getting into hysterics when I talk about my job- ‘Waterfall? Ha, ha, haah! What’s Waterfall?! I don’t understand, what’s water got to do with technology upgrades? You’re so corporate!’ and so on and so forth…)
And who says you don’t learn awesome things from this blog?
My Housemate's a Mermaid 
This is brilliant. I would like to reference this in an article I am writing. Thank you.
What you are giving is a model (and defined concepts) to explain those diligent, conscientious people who are married to one of two differing styles of operating end up in very upsetting confrontations / conflicts within a Church. My guess is that the Waterfall approach is less proactive in soliciting collaboration, diversity of strengths, 360-degree accountability and innovative results.
LikeLiked by 1 person
You are more than welcome to use/share this article as you wish. I’m glad you found it useful!
LikeLike
I love how your brain came up with that for today’s word prompt. Great!! It is one if the things i enjoy about this community…so diverse yet so supportive and friendly.
LikeLiked by 1 person
There are a few things here which are so simplified that they’re incorrect (sorry!). Kanban is an operational model, not a project management model – see the classic Toyota car manufacturing line example. The production method you’ve described for Agile (the App) is actually a Waterfall approach, where the processes are cadenced. Agile for an App would adopt a vertical slice method of development. You say a single delivery can’t be built over time in Agile…that’s untrue I’m afraid. Agile is entirely focused on delivery drops that provide end-user/business value. I’d recommend reading a book like ‘The Agile Samurai’ before writing an article like this 🙂
Context: I’ve managed a software development team for over two years, qualified in PRINCE2 but use Agile every day, delivered +20 web projects of varying lengths, complexity and style.
LikeLike
Hey Alexa, thanks for taking the time to a) read my post and b) provide feedback (it’s more than most do!)
Just to come back on your points, as you know (and put at the bottom) I am by no means an expert on either model, I would always encourage people to conduct their own independent research if they want to learn more about either methodology of project management. If it read as simplistic then that’s actually a good thing in my opinion – it’s what I set out to do!
With regards to Agile projects, in the organisation I work for we’re currently developing multiple mobile applications and digital products based on an Agile approach. The organisation’s ambition is to expand the use of Agile to a number of similar programmes over the next few years. Kanbans are used as a means of sharing information with other team members to aid collaboration – I never said (or intentionally referred) to them as a unique project management model. If you search ‘Kanban’ online then you get a number of timetabling/whiteboard software.
It may be a case our two organisations have flexed and adopted Agile to suit their unique business needs, but I do stand firm by what I have said in the article. It’s what I was educated during an intense training period (led by internal and external suppliers) and I whole heartedly believe that people will either know Waterfall and Agile already or go and learn more for themselves if this becomes applicable to their job roles.
Thanks for taking the time to comment!
LikeLike
Sure! Training, Google searches and textbook project management theory never stacks up to reality though 🙂 Even though certain institutions (particularly finance and personal banking) really do try to match them up, often to their detriment. Good luck!
LikeLiked by 1 person
Many thanks Alexa, when things calm down a bit here (hah, hah) I will certainly have to read a bit more theory 🙂 have a fab weekend!
LikeLike