Agile Drupal: Retrospectives Mean Better Project Learnings

When an agile Drupal project ends successfully—you know what it’s like—the last thing anybody thinks about is “let’s analyze our learnings and document them.” If it is, it’s done out of obligation, with an air of “everything went great because we released on time and budget.”

Of course, these retrospective learnings happen eventually, or at least these should, but isn’t it true that we don’t often see project “closure” as an opportunity?

Moreover, some teams miss an opportunity and its signs, as an agile Drupal project unfolds. Whether learning is ongoing or is accomplished in retrospect, it’s not often viewed from the practical standpoint.

Here’s the thing:

Reflecting on agile Drupal projects and management thereof isn’t just about learning for the sake of learning. It’s a matter of return on investment, ROI.

What’s ROI Got To Do With It?

You’ll agree that in the software world, learning for its sake doesn't offer a return on your investment. You gain nothing because learning is an opportunity, not an end in itself—right? Just because you now know something doesn’t make you better off. It’s what you do with it that matters.

ROI comes from what you do with your learnings. How you apply retrospective learnings is what makes retrospectives so valuable; worth much more than their time and trouble alone.

Retrospectives That Make Sense

Granted having the ability to be agiler involves having the right time and talent on your side. Unless a retrospective is observed or developments are being recorded and brought to bear, stagnation isn’t just possible, but likely. There can’t be profitable growth if teams miss or bypass opportunities to become agiler.

Evolving processes based on retroactive feedback, versus going with your gut, is how you invest in your current and future projects and clients.

Isn’t it true that when developing any project or process, decision makers should act on tangible feedback—actual data versus assumptions? Data is what retrospectives provide tangible feedback.

Agile Drupal & Opportunity

Project contracts, even agile Drupal projects, are often centered on development hours and resources. Despite the best planning, the unexpected can happen. Despite pitfalls, we need to manage our client’s expectations.

These outcomes are especially true—and very challenging—when feedback or bugs go beyond what’s contracted such as time or resources. So with this in mind, we can take prior project learnings, and we can apply them when setting client expectations in the future.

But what about forwarding the way we do things? How can we get better at spotting opportunities for growth?

Some Internal Insights

We’ve achieved rapid Drupal evolution in many ways by looking back on projects. Many of these insights have helped us optimize strategic project management and enable future business endeavors.

By discerning sure signs from retrospectives, we’ve been able to hone in on new opportunities. Historical learning in this way isn’t opportunistic or exploitative; it helps us readily prepare for what could come next.

Contractual Realignment

• Lots of Stakeholders: We started with Tom, then we worked with Bill during the development, and now we’re working with Sara post launch. If we’re going to get our best work done, we’ll need to align better.

• Tool & Process Standards: While the team may consolidate all issues raised in emails and resolve them efficiently, it’s important that all parties are utilizing project management tools. More importantly, we're holding each accountable. It helps us all.

Project Development

• Removing Undiscovered Roadblocks: Because of our expertise with headless Drupal and Drupal Commerce, we're able to prevent cache stoppages from arising in similar projects. Further, we're able to recognize when off the shelf modules are good enough or not so that the right product is built, rather than something new and cool.

Continued Partnership

• Indirect Work: We have seen this frequently happening in cases where we deal with a design agency. The end client is going to need someone to support the site after delivery, and we know we can help.

• Technical Needs: Some clients aren’t so good with the technical. That’s ok, and that’s what we’re here for. What this indicates is that they need some help post launch. We’re great at handling ongoing Drupal support and maintenance projects.

These internal insights have positioned us to spot opportunities, room for growth, and strategic ROI for our clients and ourselves. Before starting your next project, learn from your previous one first.