3 must-have meetings in our tech team

After months of experiments, we figured out 3 types of recurring meetings, that are necessary to keep a smooth workflow in our small software house. We tried different setups such as double daily, deep feedback or independent work. What stays with us is a truly bulletproof process.

Here is what we worked out:

Daily / Status

Every day at 10 am we gather for a quick call (5 - 10 minutes) where everyone answers 3 questions:

  • DONE: What was I doing yesterday?
  • TODO: What will I do today?
  • BLOCK: Do I have any blockers?

We keep daily extremely short and cut off all digressions. Everyone just answers the questions and we move to the next person. Sometimes, to avoid internal friction, we nominate one person to keep people on track. For any larger topic or blocker that comes up during the daily, we either book the time in the calendar or discuss it right after the daily among interested parties (to not keep everybody). During daily designated person shares the screen with JIRA and filters tasks by the person who is currently reporting their work.

The purpose of daily is to gather from everyone a brief update about the situation and to find out potential blockers.

At the end of the daily, we read the sprint goal out load and verify if it's somehow endangered.

Refinement / Planning

Once a week (Mondays at 1:30 pm) we have a longer call for 30 - 45 minutes to plan the work for the week. Usually, I prepare tasks before planning in JIRA, move them to a new sprint tab and sort them by priority. During the planning, we:

  • SCOPE - is the scope clear? do we need additional spike/research?
  • ASSETS - do we have all the needed artifacts and assets?
  • ASSIGN - we assign the task to the most suitable developer
  • ESTIMATION - we discuss estimation of the task

After assigning all tasks we organize tasks for the new spring:

  • BLOCKERS - are any tasks blocking each other?
  • ORDER - do tasks need to be done in a specific order?
  • PRIORITIES - which tasks are the most important?

In the end, we define the sprint goal and write it down in JIRA. And this way we have assigned and estimated tasks for a new sprint. With a small team, we stick to weekly sprints, for teams of more than 5 people, it's better to keep two-week sprints.

Feedback / Retro

Every last Friday of the month we meet for about an hour to summarize our work, look critically at our processes and plan corrections or (even more important!) keep our flow untouched.

We tried to do retro based on deep and introspective questions (Do you have any general observations about the functioning of the team? How do you work with the team? What motivates you? What do you like and what would you like to change?). However, these questions lead to emotional and not enough specific meetings. I think that such feedback can be done once a quarter or once every six months and individually.

Instead, we work with 4L scheme. We share Google Jamboard split into 4 parts and give ourselves about 3 minutes for every category to write down:

  • LIKED = things that we liked
  • LONGED FOR = things that we crave
  • LACKED = things that were missing
  • LEARNED = new things that we learned

Based on 4L scheme we decide what we want to change in our processes. We write out every new idea and assign one person that would be responsible for it. At the end of the meeting we read the list of changes from the previous retro, verify if we succeed in implementing each idea, and decide if we want to keep it on the list or remove it.

And that's all the meetings we need as a small tech team. It's very simple and minimalist, but there's no need to fall into overprocessing. I prefer the asynchronous approach and developing extreme ownership in team members.