QIMA Tech Blog

Cross Team Mercato

Tech Team -

Introduction

We are working at QIMA, a company focused on quality control and supply chain audits. We are currently building an awesome SaaS platform called QIMAone.

We are organized into teams of 6 people. Each team is multi-disciplinary, composed of frontend / backend developers, a Scrum Master (SM), an UX designer and a Product Owner (PO). All teams have all their own target in term of features.

Challenge: We want to grow the teams and also give developers the opportunity to voice their preference for the features on which they would like to work. To meet these needs we organize a “remix” of teams during each quarter.

In this article we will share out our process for mixing teams according to:

  • Subjects/Epics
  • Affinities and preferences
  • Skills and knowledge requirements
  • Experience (to balance QIMA-experienced people/newcomers and senior/juniors developers)

We will also talk about how we reviewed our requirements to facilitate these regular inter-team movements to help people to work together on the same code base.

Extrem quotation

First, to build efficient teams, we need to know the approximate size of the epics. For this, we use an agile estimation technique, the extreme quotation.

Unlike the backlog refinement where the objective is to have really “accurate” estimates, the objective of the extreme quotation is to have a light and relative estimation in record time (30/45 minutes). We use Fibonacci sequence numbers to estimate feature size.

Another benefit is to allow the developers to discover the different subjects/epics. This helps them later on to choose the subject that they might be most interested in.

The extreme quotation is animated by the PO in charge with the help of the SM.

Mercato

As input we now have :

  • Epics which will be prioritized during the next quarter (their name, an explanation/pitch...)
  • A rough size estimation of the work to do
  • Developers know the subjects/epics as they participated to the estimation
  • The skills requirements of those topics (number of back-end, front-end developers)

Let’s go for the mercato workshop !

The "Mercato" makes it possible to move people between the teams. Each team shares the same practices, way of working, coding rules making such moves easy.

The workshop can be done asynchronously to let people think about what they want to do.

And as output, the workshop ends when everyone has expressed their wishes.

Then, the management (Eng. Director + Lead PM) decide together to define who will be where. To do so, they take decisions based on:

  • Human interactions: O/O meetings with developers, discussions with SM
  • The needs of each epics (number of front/back developers)
  • The knowledge already acquired by team members (is someone new in the team, does someone already has a deep knowledge on something…)
  • A bit of magic (knowledge about personal relationships, for example)
  • Peoples wishes, expressed during this mercato

Each criteria  helps the management to take an enlightened decision. The fact that people express their wishes doesn't mean that their wishes will be 100% respected, even if the management will take those into consideration.

To let people express their wishes, during the last mercato, we hacked a "Buy a feature" workshop. Basically, we gave some "money" to everyone, and they had to express their wishes regarding the themes by putting some money where they wanted to go.

Rules of the mercato meeting

Context

  • We have multiple teams with different skills and common guidelines
  • We have some topics which are known by the developers (thanks to the extreme quotation)
  • As a developer, you share your preferences for topics you would like to work on in the next period.
  • We don't necessary require big changes between the teams, but we're open to see if some people want to move.

Reminder of the rules

  • Each developer has "money to spend".
  • The money represents the wishes you have regarding the topics.
  • You can put all your money on one topic, or split your money on severals topics.
  • You can only vote for yourself. It's forbidden to move other people money
  • You can't split your money (a $5 ticket can't be split into a $2 and $3)

What is the decision process?

  • The management will decide, ultimately, teams organization - who will go where - after taking into consideration the needs of each topic, the knowledge already acquired and the wishes developers shared.
  • It's normal that not everyone will get what they wish, but we'll try to take everything into account, including the wishes.

Money per person

  • One 10$ ticket
  • One 5$ ticket
  • One 3$ ticket
  • One 1$ ticket

Developers have 3 days to express their wishes on a dedicated miro board. The day after, the management gathers the information to decide.

Team needs for Q3: these cards line represents the number and the type of developers needed for next quarter for this epic

What to do / how to handle many different teams working on the same codebase 🔎

Our organisation

Having different teams with the same codebase has the virtue to easily generate solidarity and share knowledge between people. However, there are drawbacks and the main one is the dependency management.

On the top of common practices, like coding guidelines, cross-team code reviews... We have several ceremonies/rituals where people meet and exchange based on their core skillset. This allows an overall alignment on their technical stack, guidelines (back/front exchanges), and tech roadmap too (back/front groomings).

When we grow a development organization which is all working on the same code base, there is a point where we begin to face some dependencies between the teams. In another article, we will talk about the way we address scaling in teams and minimize the impacts of those dependencies.

We are currently hiring more developers ans also Scrum Masters ! Join us! ✨

Written by Raphael Geneteix  and POQUET Charles, Agile Coach and SM/Front-End developer at QIMA. ✍️