Agile Drupal Retrospectives Enable Prospective Success

Agile Drupal retrospectives are about one thing and one thing only. Making future success easier than the last time (and the time before that, and the time before that). That’s the whole ballgame and the stakes are high.

Retrospect and adapt or die"

-Michael Cannon

Agile Drupal Retrospectives = Future Success

We call the agile Drupal retrospective “the ritual we can't live without.” Because if we didn’t learn from our mistakes, we would’ve fizzled out a long time ago. Being consistent and timely with retrospectives is one of the things that keeps us burning bright.

When done the right way, when consistently applied to development projects across the board, agile Drupal retrospectives transform the quality of a team’s work. And the effect is real because agile Drupal retrospectives apply a focus, directly, on continuity and resilience; this applied focus is what gives our partners dependable services.

Collective learnings keep us growing.

The agile Drupal retrospective is a time when everyone in our development team can come together to express themselves freely, to share and to learn. The co-author of the book Agile Retrospectives: Making Good Teams Great, has said:

"Agile retrospectives stoke the engine of team improvement."

-Esther Derby

Individually, each team member concentrates on what needs to be done in future iterations from their perspective. Collectively, we determine how to repeat and optimize successes and eliminate missteps.

Principled reflections help keep us honest. 

Here retrospective Drupal development isn’t about assigning blame or cheap talk. In fact, our retrospectives begin by reading out the Retrospective Prime Directive, that usually goes like this: “Regardless of what we discover, we understand that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

See how we do Drupal differently.

The goal is always productive, not regressive. Taking collective ownership of the work we offer our partners is important. And since we own this as a team, we reflect on it together. This keeps us straightforward but away from scapegoating.

Why is our Customer Happiness index so high?

These retrospectives allow us to reflect and align to our partner’s vision. We’re able to see from their perspective, and clearer each time. When we retrospect collectively as a team, we identify success factors that need to be repeated and failures that need to be eliminated. When it comes down to it, it’s that simple.

Our partners learn to expect continuous improvement.

The discipline that goes into our agile Drupal retrospectives paves the way for partner satisfaction—happy customers. These retros keep the customer well informed and it maintains transparency.

Clear updates and a commitment to continuous improvement are what they expect and depend on. The key here is to allow continuous, constructive, feedback to flow in.

Partner feedback specifically is used to improve the development of the next cycle. Our goal is to achieve the customer goal in most efficient way possible and keep everyone happier.

Because at the end of the day, it’s not about us.

We’re not committed to defining Open Source success for ourselves. We don’t do Drupal development for ourselves, we do it for our partners. Our aim is to effectively offload deadline pressure, to ensure their ROI.

Retrospective partner feedback helps us do right by them.

Increasingly shorter product life cycles, cost pressures, and demand for customer orientation requires our partners to be flexible. Their flexibility requires our agility. We are required to improve efficiently so we can do the right things by our partner.

Through early integration with agile Drupal retrospectives, we bring our partners voice into our development process so we're able to deliver what's important to them.

This helps define value-driven development.

During these retros, it’s the Scrum Master who facilitates the meeting, including both the development team and client’s Product Owner. It’s for their benefit. By the time each time-boxed iteration ends, we have a clearer picture of what jeopardizes the project’s success. With this in mind, we can take early preventive action to keeping it on track and moving forward. The result is a faster Time to Market (TTM), and a highly productive and potentially long-term relationship.

And we seize these opportunities for growth.

Agency self-organization nurtures in each team member such qualities as openness, individual leadership, and their communication skills. In our self-managed teams, team members are put not just in charge of task execution but also for managing their progress.

"Learn from yesterday, live for today, hope for tomorrow.The important thing is not to stop questioning." 

-Albert Einstein