DrupalCon Barcelona 2024: Drupal Dives into Agile Waterfalls

At DrupalCon Barcelona 2024, I had the chance to share some valuable lessons learned from managing closed-scope Drupal projects with an agile mindset and an agile set of practices. Working for different companies in the public and private sectors, I have refined an approach that benefits both clients and delivery teams, helping everyone reach that final milestone with a sense of accomplishment… and a great Drupal website.

When (and why) to be flexible in closed-scope projects

Traditionally, the waterfall methodology has been the preferred choice for managing projects with a closed scope. Most clients need to know upfront exactly how much and what they are paying for, but it’s often hard to collect well-detailed requirements before implementation. This is especially common in less technologically mature organizations where stakeholders struggle to envision exactly what they need—and stick with it once the website is delivered. Other times, companies need a bit of “wiggle room” to experiment and test in the context of a minimum viable product despite having a limited budget and time to invest in it.

This is where an agile framework can help. Taking Scrum as an example, we can introduce some flexibility to refine the scope as we develop and deliver it in successive iterations. This approach involves the client during the implementation phase, allowing them to review and provide feedback on the deliverables presented after each sprint.

Navigating feedback and dealing with scope creep

The client’s feedback can include different kinds of issues. Some are bugs that can be fixed in the next sprint or minor improvements that can benefit from Drupal’s built-in flexibility and modularity and fit within the team’s capacity without jeopardizing future milestones. However, more often than not, the client’s feedback also contains "scope creep"—the dreaded beast that often appears when we invite new ideas, comments, and perspectives into the ongoing implementation of a closed-scope project.

To avoid falling prey to the scope creep, I shared with the audience a little strategy of mine I like to call “the 3 Rs”: 

1. Reduce: Understand the need behind the change request, simplify it as much as possible, and ask your developers what the least expensive way to fulfill this need is.
2. Reuse: Is there a Drupal module for this, or can we reuse something we have already built (or will build) with minor changes? 
3. Replace: Get an estimate for the change request and negotiate with the client about what part of the to-be-delivered scope they are willing to trade for this new feature or improvement.

Key takeaways

The key to successfully implementing this agile/waterfall mixed approach is communication: being collaborative yet clear and assertive, knowing when to say “no,” and always valuing your development team’s input. 

Finally, I reminded the audience that the main goal of this approach is to foster a more collaborative relationship with clients and development teams so that everyone feels their investment—whether money, time, or work—is well rewarded with a terrific Drupal website and the mutual trust of everyone involved in the project.

This was a great experience for me as both a Drupal expert and an Agile enthusiast! Afterwards, I was happy to talk to some of the people in the audience about their own experiences and challenges in handling closed-scope Drupal projects. After all, the best part of any Drupal event is learning from each other. It’s also how we improve the way our projects are delivered, contributing to Drupal’s reputation and long-term adoption in more companies every day.