Our tried and tested process for managing a high performing distributed development team

Arif Harbott
Arif Harbott

At HERO Transformation we made a conscious decision to build a distributed development team and we’ve previously written about why and what we’ve learned.

Part of what makes our global team so effective is the weekly process we’ve honed over many months. This is what works for us and why.

Our original cadence included lots of meetings. But after several retrospectives, we eliminated meetings that were not adding value. Why have a meeting if you don’t need one? This is a good reminder that agile is a template that must be adapted to fit your organisation.

Weekly meetings

Sunday: Backlog planning and prioritisation

We spend time discussing, debating, prioritising and challenging each other on the order of the backlog, new upcoming items, longer-term roadmap and most importantly what we can eliminate.

About 80 percent of the time we agree and the remaining 20 percent we fight our corner to convince each other. If we have a stalemate then we sleep on it and try again the following day. If we still cannot agree then we ask our third founder to arbitrate.

We have settled on having three backlogs:

  1. MVP backlog : epics and larger chunks of work
  2. Upcoming work: more granular work for the upcoming sprints
  3. Current sprint: small tasks for the team to work on this week

We prioritise MVP backlog and upcoming work and leave the current sprint empty for the team to pull work down into.

Backlog structure
Example of our backlog structure

Monday: Team sprint planning

First thing on a Monday morning from 7 to 8 a.m., the team reviews the upcoming work backlog and then we ask questions about the items. Team members have been included in breaking down the items so there usually aren’t too many questions.

The meeting outcome is for the team to populate the current sprint from work items in upcoming work. This is what they commit to deliver.

Monday: Technical sprint planning

After the team sprint planning, the team works together to decide who is going to work on which item. This when we agree on the technical approach and sketch out architectural solutions.

Monday: Founders’ alignment call

The founders have a call on Monday evening to decide on the most important work for the week. This is also a time for us to talk about things that are on our minds and any personal commitments that will eat into working time.

Topics that we cover tend to be finance, sales and marketing, proposition development, legal and longer-term vision for the product.

Friday: Sprint retrospectives

The team reviews what was planned vs. what was done. They conduct a retrospective on how they worked, whether anything needs to change and whether work needs to be reprioritized.

Daily cadence

Checking in and out

Everyone in the team posts at least two messages in daily stand-up channel. This is to ensure alignment and keep the team on track:

  1. When they start work, team members post about what they are going to work on for the day as a sort of check in.
  2. At the end of the day, team members write about what progress they have made, which items have been deployed, are ready for testing, etc.
Slack board
Example of a team member update on Slack pulling in work items

Reviews of deploys

We make deploys to development multiple times per day, so there is always something to test. Our process allows us to have steps in each item e.g. item is in test or item is in dev so it is easy to know what we need to test.

We tend to do reviews of deploys two to three times per day, typically in the morning, lunchtime and afternoon.

Our definition of done

  1. Deployed to dev
  2. Smoke tested by developer
  3. All test cases are passed green on dev by another team member
  4. Metrics are in place and reviewed to be working

Backlog refinement

Because we have very light documentation there is often the need to explain items in more detail. We are constantly solving very complicated user design and workflow problems so it helps to talk them through. This is usually done towards the end of the working day.

Our definition of ready

  1. Item has been discussed with product owner
  2. Test cases documented and reviewed
  3. Task is smaller than half a day
  4. Task estimated (size and hours)
  5. Metric defined
  6. Impact on UI, bots, performance, scale considered


Our process is constantly evolving as we inspect and adapt, so we are always looking to streamline meetings.
The objective of our process is to ensure alignment, common knowledge and to stay focused on the end goal. This is even more important for teams that are not co-located.

Our tried and tested process for managing a high performing distributed development team
Scroll to top