Agile (Scrum) vs Waterfall

The other days I was browsing through LinkedIn as I like to see what companies are doing, what people are posting and if there's anything interesting to read.

A recruiter with whom I am connected posted this:

Is the Waterfall method really that bad? It seems to me that its become popular to put older methods down, and that’s across all walks of life.

This was followed by the image at the bottom of this post, produced by Toggl (whose product I love and will delve into in a future post) and my reply in it's original form can be found here, but I wanted to expand upon those thoughts.

Agile is a buzz-word. Everyone wants it, thinks they know it and believe all they need is tell everyone "they're doing Agile". It's not that simple.


I've been a Certified Scrum Master (CSM) since December 2010. It was the first business-based certification I ever received and it's been a major part of my professional career ever since. I've learned Prince 2 and the waterfall methodology purely because:

  • It looks good on the CV
  • Big clients want to know that you can put together a Gantt chart
  • It's actually a great methodology for showing a plan with all dependencies and milestones

At the end of the day though, it's not the framework within which I want to operate on a daily basis for my staff, projects or clients.

At the same time, Agile (Scrum) can be fantastic for development teams, but only if it's managed properly. Time needs to be taken to educate internally and externally and those at the coal-front (usually a project manager), has to be strong enough to say "no" if there's someone on the other side pushing for more work than can be feasibly achieved by the team.

What you need

There are a number of requirements to getting any Agile methodology successfully in place in an organisation, be that internally or externally

The lack of real and sustainable buy-in is the biggest thing which stops any methodology taking hold. It isn't just the CEO who needs to believe in the change, it needs all levels of the organisation to get on board and invest their time.

It doesn't mean you can tell a group of people once and they'll really understand and be motivated to continue. You need to constantly and consistently apply knowledge and understanding of what and why this change is happening. This can be through:

  • Company-wide meetings
  • 1:1 meetings
  • Team meetings
  • Training (both internally and externally)

On the last point, the organisation must be prepared to pay for not only the training (CSM training in London can be £1,000+ for two days), but also allowing time and money for the staff to "top-up" their training with conferences and further Scrum training. Your Scrum Masters and Product Owners must also be given the time every-day to practise their craft and embed into the team.

In my experience, even with a mature team that has worked together for 12+ months, they are going to need six months at least to really understand and embed themselves into the methodology. You may seem an uplift in the first month, but the real synergy isn't until later.


This project is the same as all of the others
You've done this before and it never changes
We only want Agile delivery. Please send a project plan with all of the dependencies in the next week
Surely we can just add stuff to the sprint?

The above are real quotes from either clients or internal stakeholders, to me, over the years during projects or assisting project managers with issues.

Agile development doesn't mean you can add in any number of tasks, to every sprint and hit a fixed deadline.

Dilbert Agile Triangle
Dilbert Agile Triangle

It does mean you can embrace change, but when a client says they need something new in the sprint, that probably means something needs to come out as well.

Getting your stakeholders to understand a finite amount of time means work can only go in if something comes out is the key to Scrum working. It's called prioritisation. If one things has to come in, then it's more important than something else. The most successful projects, in my opinion, even if they are driven by a fixed time and a fixed budget, have people on both sides understanding:

  • the importance of prioritisation of what is actually important
  • open communication
  • people are people; they get sick, they take holiday

Can't you just add more people to get more work done?

This is almost every project and also some managers. The quote I was given by my scrum trainer was "that'd be like asking nine women to give birth to a baby in one month". Development teams defeat math in this case: 1+1 does not equal 2. You need time to on-board people (which means a team member's efficiency drops in the short term) and the more people you add, the longer those meetings take. You also start running the risk of people over-writing each other's code, or the new person doesn't know how the team "works".

Can you mix Agile and Waterall?

If you're a purist, of course not. If you're a business selling development services to another business, yes you definitely can. The term I usually find myself using is "Scrumerfall". I've had to use this term plenty of times with clients of all sizes. Simply put, client wants:

  • a Gantt Chart
  • clear milestones
  • dependency tracking
  • steering committee meetings
  • sprint plans
  • the ability to change work in progress mid-sprint
  • re-prioritisation of work
  • stand-ups and sprint demos (see progress)

You can achieve this in a Waterfall approach, but it's less natural. It does mean a project manager has to be flexible, using one methodology to the client and another with their team.

What you do if you want to adopt Agile

  1. Get an understanding of Agile, be it Lean, Scrum, Six Sigma. Go to conferences, read books, find a coach.
  2. Go on to the course yourself to understand the content, the what and they why. What are you asking your teams to do?
  3. Sell the idea internally to the teams and business decision makers
  4. Continually invest your time. Agile if a methodology, with Scrum as a framework. They don't work without time and effort. Buy-in from the team members and rest of the organisation is vital.
  5. Don't give up
Rocket to Mars - Development methodologies
Rocket to Mars - Development methodologies

Author image
All views are my own. Proud fiancé and cat dad, Technical Director at We Are Kitty