Internal Retrospectives - How We Reflect to Get Better

At the end of every project, we don’t just celebrate - we pause to ask three essential questions:

• What should we continue doing?
• What should we stop doing?
• What should we start doing?

These questions aren’t just routine; they’re the heart of how we improve with every challenge we take on.

We recently wrapped a complex product build for a long-standing client and, as always, held a full team internal retrospective to reflect on the project. Here’s what came up:

What worked well

• Strong, open communication and a genuinely engaged client were major factors in our success. Quick, accommodating conversations and honest dialogue helped us keep momentum.
• The project environment fostered collaborative problem-solving, with both sides taking ownership and making course corrections quickly.

Beyond this project, the experience sparked internal improvements - from adopting better tooling and update policies to encouraging cross-team knowledge sharing between tech and non-tech roles.

Where we can do better

• Unspoken assumptions caused friction, particularly around MVP definitions, project priorities, and feature scopes. For example, unclear expectations about what exactly qualified as MVP led to surprises during development.
• We also found that without documented agreements on promised features, alignment suffered.

Moving forward, we recognise the need for earlier and clearer alignment by defining terms upfront, documenting expectations thoroughly, and validating scope before we start building.

What we’ll be doing differently next time

• Establishing clear and detailed scope definitions that explicitly state what’s in and out of scope.
• Prioritising the most complex or risky components early, such as AI.
• Train clients on how to test properly, including device-specific considerations.
• Set and manage client expectations around MVP by carefully reviewing and distinguishing core features from extras.

For us, retrospectives aren’t just an agile formality - they’re a mindset. It’s about being “less wrong over time” and continuously improving our process as fast as we improve our products.

If you’re building something big, fast, or unfamiliar, make sure your team learns at the same speed as it delivers. We’d be happy to show you how we do it.