Perspectives on Agile vs Waterfall

Having been a trained and qualified project manager for several years before joining ScrumCenter, the world of Agile and Scrum was entirely new to me. I can’t believe this whole movement had entirely slipped by my radar. In November last year, I began a marketing role for ScrumCenter, an agile methods consultancy company based in the Scottish Highlands. I’m still learning more every day, but I’ve learned enough so far to understand some of the key differences. 

Waterfall methods, such as applied in PRINCE2, are generally used to manage projects. Agile, on the other hand, is not necessarily about managing projects, it’s a methodology for a way of working. With Waterfall, there is usually a fair amount of upfront planning involved, and the aims, objectives, and ultimate goal are usually fairly tightly set. However, in agile working little planning is done upfront and aims and objectives are deliberately loosely set. This is to allow for products to be adapted during their creation, tailoring it to the needs of the stakeholders as you go along. Feedback would usually be accessed from stakeholders at specific times/stages in Waterfall It’s usually accessed upfront and then towards the end. Whereas continual discussions/feedback is sought with stakeholders during the creation of a product in agile working. 

One other big difference is that usually in Waterfall, teams are created for a specific project and so separate after that project is complete. However, in agile, teams usually stay together. It takes time for a team to go through the phases of forming, storming, and norming. I’ve never thought about it before, but of course, it makes absolute sense to then continue to keep that team together.  Why waste a perfectly “normed” team. 

One of the other differences in terms of individuals/teams is that in Waterfall, generally individuals or specifically skilled people will contribute to the work at specific times/stages. However, in agile working, often individuals will work in pairs or even sometimes in a group, to perform pair-working or swarming activities for example. This enables individuals to learn from each other and the swarming technique is particularly useful to obtain ideas quickly and for allowing varied input from the whole group, rather than solely specific skilled input, which can be really useful.

From my experience, there is definitely a place in the world for both and in fact, one does not necessarily have to preclude the other. What I actually find myself doing is using methods from both types and tailoring my choice to what it is I am working on. One thing is for sure, for the creation of complex products in complex environments, I can totally understand why agile working is the right way to go. There’s no question that the ability to be able to adapt during development is a bonus for the end result for all stakeholders.