Why Everyone Should Use Agile But Most End Up With Waterfall

Why Everyone Should Use Agile But Most End Up With Waterfall

5 minute read

download blog's klood as pdf

DOWNLOAD BLOG AS PDF

Waterfall and Agile are both Project Management methodologies. If you’re reading this article you probably already have a reasonable understanding of what both Waterfall and Agile are but nonetheless I’ll give you a quick explanation of both. Additionally, just as a quick note, as I’m a Website Project Manager I’ll be referencing software development mostly in this article.

Waterfall

Waterfall is the traditional method of project management where each stage in a project has to be complete before moving onto the next stage. Named waterfall because if a river was flowing downhill any pool on the way down would have to fill up to the top before water could fall out of it down the river into the next pool.

Agile

Agile project management, although relatively new in name (the ‘Agile Manifesto’ was created in 2001), has been around much longer in terms of the process. Agile is simply an iterative and incremental method of managing the design and build activities for engineering, information technology, and new product or service development projects in a highly flexible and interactive manner, for example agile software development. There are multiple methodologies within Agile, the most popular being DSDM and Scrum which have both been around since 1996 before the Agile Manifesto was created.

Who uses agile

Agile is most commonly used in silicon valley type tech companies, Facebook being one. Although they’ll go to great pains to not use the word Agile, Facebook, without a doubt, will use the term ‘agile’ in-house. Agile is perfect for companies that are building their own products for the general public or for internal use. The main blocker to being able to use Agile is client buy in, this is something that companies building their own products don't have as they only answer to themselves . They probably need to field user requests but these feed in quite well into an agile structure for improving and building upon an existing product, and they can just ignore the bad requests.

Who doesn't use Agile, why they should and why they don’t

Firstly, I should highlight the problems with waterfall before I try to explain why everyone should be using agile instead. The idea with waterfall is that you plan everything up front, if you work for an agency and have clients, they will almost certainly want to know exactly what is going to be delivered to them up-front. So agencies tend to plan everything down to finite detail. The client approves the plan and you go away and design. The client approves the design, perhaps with some small amends but they’re not too difficult to accommodate at this stage. And then you go away and develop, you finish all your testing and you show the client what you’ve built and they say, “Oh, that isn’t what we had in mind”. Software isn’t a simple thing and it’s incredibly hard to define everything you need up front. With this in mind the client will undoubtedly want to change whatever has been built as it either doesn't match their real needs, even though it may match the original requirements. At this stage, making changes will ultimately be both timely and costly. You then also have to have the very awkward discussion around who foots the bill (I find this often puts a strain on client relationships and can be a large factor in poor client retention).

Why, then, is agile the solution to this problem? Agile not only states that change is expected and to some extent also encourages it. You only do Enough Design Up Front (EDUF) and through iterative and incremental building from solid foundations, the client gets to see the key elements of their project first and can request changes early on when they’re much easier to go back and amend. By building incrementally you can also release functionality incrementally and deliver business benefit as soon as possible. The end product will always be of a much higher quality and closer to what the client really needs rather than what they just felt they initially wanted. Sounds great right? So why do some many agencies end up using waterfall instead?

As mentioned, one key reason is client buy in and I’ve found there’s two things that cause this, cost and (their) time. Most people have heard of agile by now and will have heard that it’s the solution to all their project woes. When you go to a client and tell them you can use agile they’ll undoubtedly be bouncing up and down with excitement. However, when you come to discussing pricing structures and how much time you’ll need from them that’s when they’ll start shying away.

Lets talk about pricing first. With agile you agree to deliver some high level objectives in a given time period but to achieve this you may have to leave out low level tasks within the main objective. You can charge a fixed amount for this time period, but clients don’t like the idea of not having everything they want being delivered. Alternately you can agree to run the project iteratively until it’s possible to achieve all the clients high level objectives and every task within. However, to do this you have to have a running cost over an unlimited set of time periods and clients don’t like not having a fixed cost either.

Another factor blocking client buy in is simply the amount of time required from them. To do agile properly you need the client's input almost everyday to help define the softwares growth and make sure that what’s being built is still meeting the business need. The client is just as busy as the agency they’re working with and will often not have the time for this.

Finally, there is also an Agency level blocker to agile. Whereas with the Waterfall methodology and it’s one step at a time process, the average Joe should just be able to pick up a project and run it with a bit of good communication and organisation. Conversely, because of it’s constantly evolving nature Agile is a far more complex process to successfully manage. As a result it requires a skilled Project Manager with a significant degree of training to understand how to implement Agile correctly. Many agencies simply won’t have that skillset to hand and it may well be a time and cost they are not willing to invest in immediately.

OK fine, so what’s the solution?

In short, Time and Tutoring. As time progresses I expect more and more people will learn about how agile really works and it’s success within the Silicon Valley tech industry. If we all work closely with our clients to explain why Agile really is the best option for their project despite the downsides around cost and their own time required. If we put in the effort to really show people why agile will deliver higher quality projects then I believe slowly but surely more and more agency projects will be done using Agile. And well that, will definitely be good for us all.

So what does Klood do?

We understand that not everyone wants to do or has the time to do Agile. With that in mind, for those that want to use a traditional approach we’ll work as closely as possible with a client to make sure we’re delivering not only what they want, but also what they need. We understand that things might need to change near the end of a project and we’ll always go the extra mile to accommodate that too. We’d love to do Agile with you, but if you want to do Waterfall, well thats just fine too.

Download the Beginner's Guide to Growth-Driven Design