When it comes to managing software development projects, many are familiar with the sequential Waterfall and iterative Agile methodologies. Development teams are often asked to choose one approach over other, as if they are mutually exclusive. But if you consider the two approaches on a continuum, with Waterfall being more fixed and rigid while Agile is more flexible, you might find—as we have —that a middle ground is the ideal solution for your project.
Let’s take a minute to look at the development process and then consider some of the factors that might drive your project toward one of these methodologies, or a blend of both approaches.
The Development Process
The development process can contain many phases. Let’s quickly review the big four: define, design, build, and test.
- In the define phase, we determine what needs to go into the project by defining the business, functional, and technical requirements.
- In the design phase, we determine how it will get done by turning the requirements into technical solutions.
- In the build phase, we implement each of the technical solutions identify by the project.
- In the test phase, each of the technical solutions is verified to function correctly.
Comparing Methodologies
Now, let’s examine the differences between Waterfall and Agile methodologies.
- Waterfall – Each phase is executed in a linear fashion, meaning the define phase is executed before the design phase, and the design phase is executed before the build phase, and so on. This is completed for the project as a whole.
- Agile – The same big four development processes are executed but the process iterates through each of the requirements/solutions independently, usually in two week increments. This approach allows stakeholders an opportunity to reprioritize the requirements in mid-stream, or to even change project scope by introducing new requirements or by removing those that are no longer relevant.
What will work best for you? To answer that question, consider these important factors:
- Stakeholder involvement: If the project scope is fairly well known, minimal stakeholder involvement may be required. While this scenario works for either approach, an Agile approach benefits from greater stakeholder participation.
- Blended development team: A blended team can be a result of wanting to utilize available client resources, to foster the transfer of knowledge, and/or to accelerate a project timeline. An Agile approach can accommodate a fluctuation of resources by increasing or reducing the amount of work scheduled for a given n iteration.
- Project longevity: Will your project have a short lifespan or will it need to be supported long-term? A Waterfall approach typically places an emphasis on documenting requirements to support maintenance efforts for projects with a longer lifespan. For some marketing projects, an Agile approach may be more appropriate–for example, a microsite that may exist for only a few months.
- Project size: The bigger your team, the more you have to invest in ensuring clear project communication. For large project teams, a Waterfall approach works best.
How to Find the Middle Ground
However, it doesn’t have to be either or. And even if you want to transition from a strictly Waterfall to Agile approach, it can be daunting to stakeholders who haven’t used it before; they may be reluctant to try it, even if there’s a good business reason to use it. So, for many reasons, a hybrid development approach may be just the ticket for your project, allowing you to retain the comfort of Waterfall while reaping the benefits of Agile.
This can be accomplished by leaving the define phase mostly intact, as you would see in a traditional Waterfall approach, but then the team iterates through requirements/solutions in an Agile fashion by combining the design, build, and test phases. Ultimately, of course, your goal is to find the right balance of time spent to get to the end goal while minimizing the overall cost to produce it.
What has worked for us?
Over the years, as our projects have become increasingly complex, we’ve embraced a more Agile approach. In part, this is because our client’s marketing initiatives have required more complex technical integration with their existing enterprise systems. Traditionally, this meant integration with a single system: a Content Management System (CMS). But now other enterprise platforms are common—for example, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), as well as Marketing Automation tools. Since these engagements also require interaction with many different staff members, we’ve increased the number of deployments we undertake to facilitate greater collaboration, and to allow our clients more time for integration setup and testing. These additional (“iterative”) deployments reduce the risk to the overall project when compared to a single deployment scenario, known in the industry as a “big bang” rollout.
While we did not move from Waterfall to Agile overnight, we found that with each new engagement the number of iterations/deployments we undertake has increased from one to three then to six and, today, it’s as high as 20. Each iteration includes a blended team of internal and client resources, which is required to execute the defined scope. Those blended resources have included team members from across disciplines, including marketing, business analysts, designers, frontend and backend engineers and quality assurance. The Waterfall approach has lingered in some aspects as it pertains to the define phase but we think this allows us to better estimate projects using a fixed budget.
Using this hybrid approach, we have experienced an increase stakeholder satisfaction, a higher level of confidence in the client team taking ownership of the final deliverable after project completion, and a reduction in project cost by efficiently leveraging resource availability and contribution.
