Can We Combine Agile and Waterfall Development Strategies?

July 19, 2008 | Author: PM Hut | Filed under: Agile Project Management,Project Management Best Practices,Project Management Musings

Can We Combine Agile and Waterfall Development Strategies?
By Gina Lijoi

While there are likely as many unique Project Management approaches as there are Project Managers, there are two well-know production cycle methodologies that have been the topic of much discussion in PM circles – agile and waterfall methodologies. As I evolve in my own area of expertise, I am constantly reinventing small aspects of what I consider best practice. Most recently, to address the incredibly complex requirements of a large client initiative, I challenged myself to come up with a ‘super’ Project Management process that would not only improve the way in which we deliver, but what we deliver at the end of the engagement. I determined there was a way to combine the best features of waterfall development disciplines with agile principles for superior results.

Simplistically, the waterfall approach infers structure, control, progression and finite project cycles. This approach works when you have access to limited resources and when specific hours are assigned to granular stages of a project phase. Agile is different in that additional leaway is given for teams to iterate through a single deliverable numerous times until a level of satisfaction is achieved. It’s difficult to implement this approach when you are working with shared resources, or when time to market and budget cannot be shifted. It’s important to understand my descriptions of the two approaches are extremely simplified and highlight key differences – for this entry, it’s important that I make the distinction clear. I encourage all readers to conduct their own research into each approach more thoroughly.

Both approaches boast significant and different benefits, and are generally seen as being mutually exclusive of one another. It can be argued, however, that certain elements of both paths can be merged into a single process to achieve greater results. With this in mind, I have proposed a slightly refined process to my internal team, where iterations can be accommodated, but are scheduled within a defined process and period of time. In order to deliver on this approach, the efforts of multiple departmental leads (such as Information Design, Interface Design and Technical Development) must occur concurrently so that the team can produce deliverables as a single entity. By doing this, each person’s feedback is representative of the iterations which normally occur as a deliverable is transitioned from department to department. The net result is a more controlled cycle where iterations can still be accommodated.

I believe that the quality of an end deliverable will be superior when the expertise of each lead can be amalgamated into a single output. This style of collaboration will also result in a greater understanding of practice areas among the larger team – this will create long-term synergies that spur individuals to consider varying points of view, even when they work isolation.

This approach may seem like a very small deviation from standard operating procedure, but asking different subject matter experts to come together and produce one element together represents a big shift in previous thinking. This approach moves traditional agencies away from a manufacturing-based production cycle, and propels them forward into a more advanced collective and collaborative environment. As online initiatives take on more sophistication in usability, interface design and technical functionality, there will be a stronger mandate for this style of production.

Gina Lijoi has worked in the online space for eight years, and is currently the Director of Fulfillment at WebFeat Multimedia Inc., in Toronto. In this role, Gina is responsible for strategy, methodology, pricing, scoping and execution of client initiatives. She is passionate about how marketing is affected by technology and trends in social media.

Related Articles

7 people have left comments

Hi Gina,
I’ve always thought elements of the 2 approaches could coexist as one hybrid plan. It really is a matter of how far to an extreme do you sway in either approach to formulate your process and I think that really depends on who your client is. The client or project stakeholder(s) is the key because they need to be convinced that the approach will be best for the project.
For example, when I suggested an agile method to their project they said “that sounds great but what does that mean”. So I gave them the metaphor…it’s just like watching your kids grow up through all the good times and bad (newborn, toddler, adolescence, adult etc). And there response to me was, I’m the type of parent to send my child to boarding school and have them come back to me fully mature with their PHD in hand.

Brennan Hom wrote on July 19, 2008 - 10:40 pm | Visit Link

Hi Brennan,
You have brought up an important point – ‘selling’ a new or different process to your clients. It’s worth noting that such an approach (the hybrid approach) should only be taken if it will support meeting difficult deadlines, complex project requirements, and budgetary restrictions. If it does, however, these benefits must be explained to your client, as we recognize that at least 50% of a Project Manager’s role is to educate stakeholders on the importance of what we do. This education process will help elevate your profile with the client, building credibility as well as trust.

Ultimately, a project is a collaboration between client and project team, with the Project Manager leading both down a common path. Always ensure you have your client’s approval and conviction in the way you work – it will build a stronger relationship long-term.

Gina Lijoi wrote on July 21, 2008 - 8:26 am | Visit Link
Riggs wrote on July 21, 2008 - 2:16 pm | Visit Link

Great post, Gina. I too believe these processes can either be combined, or otherwise used separately within one organization. I wholeheartedly agree with you with one critical point:

“I believe that the quality of an end deliverable will be superior when the expertise of each lead can be amalgamated into a single output.”

What I struggle with is the poor IA’s role. In my experience, EVERYONE thinks they’re an expert in interfaces. Heck, they surf the web, right? So how do you keep everyone focused on their bit? Because if the business owner focuses on the strategy, and IA focuses on IA, and the designer focuses on design, and the tech lead focuses on system architecture, and if they can share and collaborate from these specific points of view, you’re going to end up with a kickass product.

I’ve seen it in action before, but boy is it hard to initiate!

Alec wrote on August 5, 2008 - 9:44 pm | Visit Link

Gina, sadly you don’t seem to have understood the crux of what agile methods are all about. I would recommend that you spend some time reading up on what Agile methods are truly about and revisiting this blog post.

Ag wrote on November 4, 2008 - 7:17 pm | Visit Link

Attempting to merge best practices between waterfall and agile methodologies will be present in business as long as the two PM styles exist; this comes from a wealth of experience from introducing Scrum to businesses that were either struggling along with no PM tech or were heavily invested in a waterfall style because it is the “classic” way to do things. Hybridizing the two is possible, but can be fraught with peril without a deep analysis of what currently works and what the desired end result is. As I started to discuss in my Art of Scrum blog post “We Do Scrum But…” without at least trying a medium-sized project with all of the components of Scrum working in synch, it will be very difficult to ascertain how Scrum without buts will be of use to the existing culture of the organization. Many Agile PMs, like PMPs, perhaps like Ag above, are too caught up in the evangelism of the methodology to actually understand the flexibility that is sometimes needed to evoke change in an organization. Check out Collaboration Explained by Jean Tabaka for a good discussion of facilitating this sort of paradigm shift.

Froggacuda wrote on November 14, 2008 - 1:02 pm | Visit Link


I agree that moving from a manufacturing approach of throwing a deliverable over the wall, to collaborating on a deliverable is an important and significant step.

Adding to Froggacuda comments, I think it is important to try a full scale Scrum Implementation that also includes Extreme Programming (XP) Engineering Principles (assuming you are doing software development) to get the maximum positive impact, but this is not appropriate in all environments and situations.

David Bulkin wrote on January 31, 2009 - 4:04 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories