Spotify Engineering Culture - Part 1

Un des grands facteurs de succès ici

chez Spotify, c'est notre culture de l'ingénierie agile.

La culture tend à être invisible.

On ne s'en rend pas compte.

parce que c'est là tout le temps.

C'est un peu comme l'air qu'on respire.

Mais si tout le monde comprend la culture,

nous sommes plus susceptibles de pouvoir le garder..

... et même la renforcer au fur et à mesure que nous grandissons.

Alors, c'est le but de cette vidéo.

Quand notre premier lecteur de musique

a été lancé en 2008.

On n'était qu'une entreprise de Scrum.

Scrum est une approche de développement agile

bien établie...

et ça nous a donné une bonne culture d'équipe.

Cependant, quelques années plus tard,

nous avions beaucoup plus d'équipes

et on a découvert que certaines des

pratiques du Scrum standard

commençaient a nous ralentir.

Nous avons donc décidé de rendre toutes les règles de Scrum facultatives.

Les règles sont un bon début, mais

il faut savoir les briser au besoin.

Nous avons décidé qu'Agile était plus important que Scrum.

Et que les principes Agiles

étaient plus importants que

les pratiques spécifiques.

Donc, nous avons renommé

le rôle de Scrum Master à Agile Coach.

Parce que nous voulions des chefs serviteurs

plutôt que des Process Masters.

Nous avons aussi commencé à utiliser le terme

d'escouade au lieu de l'équipe Scrum.

Et notre principal moteur est devenu l'autonomie.

Qu'est-ce qu'une escouade autonome?

Une escouade est une petite unité interfonctionnelle

qui s'auto-organise...

habituellement moins de huit personnes.

Ils s'assoient ensemble..

et ils ont une responsabilité de bout en bout

pour les choses qu'ils construisent,

conçoivent, committent, déploient,

entretiennent, font tourner,

en somme, le système dans sa totalité.

chaque escouade a une mission à long terme...

tels que "Faire de Spotify

le meilleur endroit pour découvrir de la musique."

ou des choses internes comme

L'infrastructure pour les A/B tests.

L'autonomie signifie essentiellement que

c'est l'escouade qui décide quoi construire,

... comment le construire et

. comment travailler ensemble

en le faisant.

Il y a bien sur

certaines limites à cela, telles que

la mission de l'escouade,

la stratégie globale du produit

quel que soit le domaine sur lequel ils travaillent

et les objectifs à court terme

qui sont renégociées tous les trimestres.

Notre bureau est optimisé pour la collaboration.

Voici un espace d'escouade typique.

Les membres de l'équipe travaillent ensemble ici

avec des bureaux réglables

et un accès facile aux écrans des autres.

Nous nous rassemblons ici

au lounge pour des choses comme

les rétrospectives.

et à l'arrière, il y a une salle de meeting

pour les réunions plus petites ou

prends juste un peu de temps au calme.

Presque tous les murs sont des tableaux blancs.

Alors, pourquoi l'autonomie est-elle si importante?

Eh bien, parce que c'est motivant

et des gens motivés

construisent de meilleures choses.

Aussi, l'autonomie nous rend rapides

en laissant les décisions se faire localement

dans l'équipe au lieu de

via un groupe de gérants

des comités et tout ça.

Cela nous aide à minimiser les transferts

et l'attente.

Donc, on peut mettre à l'échelle

sans blocage avec les dépendances

et la coordination.

Bien que chaque escouade ait

sa propre mission.

Ils doivent être alignés

avec la stratégie produit,

priorités de l'entreprise,

et les autres équipes.

Essentiellement, être un bon citoyen

dans cet écosystème Spotify.

La mission générale de Spotify est la suivante

plus important que

n'importe quel escouade individuelle.

Le principe clé est donc

être vraiment autonome

mais ne pas sous-optimiser.

C'est un peu comme une Jazz band.

Bien que chaque musicien soit autonome

et joue de son propre instrument

Ils s'écoutent mutuellement

et se concentrent sur la chanson entière

ensemble

C'est là qu'un beau morceau

de musique est créé.

Donc, notre objectif est légèrement couplé

mais avec des équipes bien alignées

On n' y est pas encore tous.

Mais nous avons expérimenté

avec beaucoup de façons différentes

de s'en rapprocher.

En fait, cela s'applique

à la plupart des choses dans cette vidéo

Cette description de la culture est

un mélange de ce que nous sommes aujourd'hui

et ce que nous essayons de devenir

dans le futur.

Alignement et autonomie

peuvent sembler

à deux extrémités d'une échelle.

Plus d'autonomie

signifie moins d'alignement.

Cependant, nous pensons qu'il s'agit plutôt d'un

deux dimensions différentes.

Ici-bas, il y a

faible alignement et faible autonomie,

une culture de microgestion.

Pas d'objectif de haut niveau

Tais-toi et

suivre les ordres.

Là-haut,

haut alignement, mais

autonomie encore faible.

Donc, les leaders sont capables

de communiquer

quel problème doit être

resolu.

Mais ils disent aussi

comment le résoudre.

Haut alignement et haute autonomie

signifie que les leaders se concentrent sur

quel problème résoudre.

Mais, laissent l'équipe

trouver comment le résoudre.

Et ici, alors?

Faible alignement

et haute autonomie

signifie que l'équipe fait ce qu'elle veut

et pratiquement tous courent dans

des directions différentes.

Les leaders sont désespérés

et notre produit

devient un Frankenstein.

Nous faisons de notre mieux

d'être ici.

autonomie alignée

et nous continuons à expérimenter

de différentes manières

d'y arriver.

Ainsi, l'alignement permet l'autonomie.

Plus l'alignement est fort,

plus on peut s'efforcer d'accorder de l'autonomie.

Cela signifie que le travail du chef

est de communiquer

le problème à résoudre

et pourquoi?

et les équipes collaborent entre elles

pour trouver la meilleure solution.

Une conséquence de l'autonomie

c'est que nous avons

très peu de normalisation.

Quand les gens demandent des choses comme

quel éditeur de code vous utilisez

ou comment tu planifies?

La réponse est principalement

Ca dépend de l'escouade

certaines font le sprint de Scrum

d'autres font du Kanban

certaines font de l'estimation

et mesurent leur vitesse

d'autres non

c'est vraiment à chaque escouade

de décider.

Au lieu de normes formelles

nous avons une forte culture

de pollinisation croisée.

quand assez d'escadrons utilisent

une pratique spécifique

ou un outil tel que

Git. Cela devient le chemin de

moindre résistance

et d'autres escouades ont tendance à choisir

le même outil

L'équipe commence à maintenir

cet outil et aider les uns les autres

et ça devient

un outil standard.

Cette approche informelle

nous donne un équilibre sain

entre la cohérence et l'uniformité.

Notre architecture est basée sur

plus d'une centaine de systèmes séparés,

codés et déployés

indépendamment.

Il y a beaucoup d'interactions.

Mais chaque système se concentre sur

un besoin spécifique

comme la gestion des playlists,

le moteur de recherche ou l'instrumentation.

On a essayé de les garder

petits et découplés

avec des interfaces et des protocoles clairs.

Techniquement, chaque système appartient à une escouade.

En fait, la plupart des escouades en possèdent plusieurs.

Mais nous avons un

modèle interne Open Source

et notre culture est plus axée sur

partage que la possession.

Supposons que l'escouade 1 a besoin

de quelque chose de fait dans le Système B

et l'escouade 2 connait ce code le mieux,

Ils demandaient généralement à l'escouade 2 de le faire.

Cependant, si l'escouade 2 n' a pas le temps.

ou ils ont d'autres priorités.

Alors, l'escouade 1 n' a pas besoin d'attendre

On déteste attendre.

Au lieu de ça, ils sont les bienvenus

pour procéder à la modification

du code eux-même

et à demander à l'escouade 2

d'examiner les changements.

N'importe qui peut donc éditer n'importe quel code.

Mais, nous avons une culture

d'examen par les pairs.

Cela améliore la qualité et

plus important encore, diffuse les connaissances.

Au fil du temps, nous avons élaboré des lignes directrices de design,

des normes de code et autres choses

pour réduire les frictions.

Mais seulement quand c'est nécessaire.

Donc, sur une échelle entre

autoritaires et libéraux

On est définitivement sur

le côté libéral.

Rien de tout ça ne marcherait

si ce n'était pas pour les employés.

Nous avons une culture très forte

de respect mutuel.

J'entends des commentaires comme

mes collègues sont géniaux.

Les gens s'accordent souvent le crédit les uns aux autres

pour un excellent travail et

s'attribuent rarement le mérite.

En considérant combien de talent

nous avons ici

Il y a étonnamment peu d'ego.

Un grand Ah-ha pour les nouvelles recrues

c'est que l'autonomie

est plutôt effrayant au début.

Vous et vos coéquipiers d'escouade

devez trouver

votre propre solution.

Personne ne vous dira

quoi faire.

Mais, il s'avère que

si vous avez demandé de l'aide

vous en recevez beaucoup

et rapidement.

Il y a un respect sincère

pour le fait

qu'on est tous dans ce bateau ensemble.

et qu'on a besoin de s'aider

les uns et les autres a réussir.

Nous nous concentrons beaucoup sur la motivation.

En voici un exemple....

un courriel du responsable des opérations humaines

Bonjour tout le monde,

Notre sondage sur la satisfaction des employés

dit que 91% aiment travailler ici

et 4% non.

Maintenant, ça peut sembler

un taux de satisfaction assez élevé

surtout si l'on considère nos douleurs de croissance.

de 2006 à 2013

nous avons doublé chaque année.

et ont maintenant plus de 1200 personnes.

Mais, alors ça continue

Ceci n'est évidemment pas satisfaisant

et nous voulons le réparer.

Si vous êtes un de ces 4 % malheureux,

veuillez nous contacter.

Nous sommes là pour votre bien,

et rien d'autre.

Donc, assez bien n'est pas

assez bien.

Six mois plus tard

les choses se sont améliorées

et le taux de satisfaction a atteint 94 %.

Cette forte concentration sur la motivation

nous a aidé à construire

une assez bonne réputation

comme lieu de travail.

Mais nous avons encore beaucoup de problèmes

à gérer. Donc, ouais

nous devons continuer à nous améliorer.

Ok, donc nous avons plus de 50 escouades

réparties dans 4 villes.

Une forme de structure est nécessaire.

Actuellement, les escouades sont regroupées

en tribus.

Une tribu, c'est

une matrice légère

Chaque personne est membre d'une escouade

ainsi qu'un chapitre.

L'escouade est une dimension primordiale,

qui se concentre sur la livraison des produits

et la qualité.

Alors que le chapitre est un domaine de compétence.

tels que Quality Assurance, Agile Coaching,...

ou Développement Web.

En tant que membre de l'escouade,

mon responsable de chapitre est mon supérieur hiérarchique officiel

c'est un leader serviteur qui se concentre sur

m'encadrer et me conseiller en tant qu'ingénieur.

Donc, je peux changer d'escouade sans avoir besoin d'un nouveau manager.

C'est une jolie photo, hein?

Sauf que ce n'est pas vraiment vrai.

En réalité, les lignes ne sont pas si droites.

et les choses changent sans cesse.

En voici un exemple concret.

à partir d'un moment donné

pour une tribu.

et c'est différent maintenant.

et c'est pas grave.

La communication la plus précieuse a lieu

via des moyens informels et imprévisibles.

Pour soutenir cela, nous avons aussi des guildes.

Une guilde est une communauté d'intérêts légère.

où les gens de toute l'entreprise se réunissent

et partagent les connaissances dans un domaine spécifique.

Par exemple Leadership, Développement Web,

ou livraison continue.

N'importe qui peut rejoindre ou quitter la Guilde à tout moment.

Les guildes ont généralement une liste de diffusion,

conférences semestrielles, et...

autres méthodes de communication informelles.

La plupart des organigrammes sont des illusions.

Notre priorité est donc la communauté

plutôt que des structures hiérarchiques.

Nous avons découvert qu'une communauté assez forte

peut s'en sortir avec

une structure informelle volatile.

Si vous avez toujours besoin de savoir exactement

qui prend les décisions.

Vous vous trompez.

Une chose qui compte beaucoup pour l'autonomie

c'est à quel point il est facile de déployer notre code en production?

Si le déploiement est difficile,

nous serons tentés de la déployer rarement.

pour éviter la douleur.

Cela signifie que chaque version est plus grande

et donc encore plus dur.

C'est un cercle vicieux.

Mais si le déploiement est facile,

on peut déployer souvent.

Cela signifie que chaque version est plus petite

et donc plus facile.

Pour rester dans cette boucle

et éviter celle-là.

Nous encourageons les déploiements petits et fréquents

et investissons massivement dans l'automatisation des tests

et l'infrastructure de déploiement continue.

Le déploiement devrait être une routine et non un drame.

Parfois, on fait de gros investissements

pour faciliter le déploiement.

Par exemple, le client de bureau d'origine Spotify

était une seule application monolithique.

Dans les premiers temps,

nous n'avions qu'une poignée de développeurs.

C'était très bien.

Mais au fur et à mesure que nous grandissions, ce problème devenait énorme.

Une douzaine d'escouades doivent se synchroniser

les uns avec les autres pour chaque version.

Et ça pourrait prendre des mois pour obtenir

une version stable.

Au lieu de créer beaucoup de processus

et des règles pour gérer ça,

nous avons changé l'architecture

pour rendre possible les déploiement découplés.

On utilise Chromium

le client est maintenant essentiellement un navigateur web

déguisé. Chaque section est composée de

comme un cadre sur le site web

et l'escouade peut déployer

leurs propre code directement.

Dans le cadre de ce changement d'architecture,

nous avons commencé à voir chaque plateforme client

comme une application client

et à développer trois différents types d'escouades.

Escouades d'application client

Escouades de fontionalité

et escouades d'infrastructure.

Une escouade spéciale se concentre sur

une zone caractéristique

comme le moteur de recherche.

Cette escouade va construire, déployer,

et maintenir les fonctions liées à la recherche

pour notre plateforme.

Une escouade d'application client se concentre sur

faciliter les déploiement

sur une plate-forme client spécifique

comme le desktop, iOS ou Android.

Une escouade d'infrastructure se concentre sur

rendant les autres escouades plus efficaces.

Elles fournissent des outils et des routines

pour la livraison continue,

les A/B Tests, l'instrumentation et les opérations.

Quelle que soit la structure actuelle,

nous recherchons toujours un modèle de libre-service.

Une sorte de buffet,

le personnel du restaurant

ne vous servent pas directement.

Ils vous permettent de vous servir vous-même.

Donc, nous évitons les transferts comme la peste.

Par exemple, une escouade d'opération

ou une escouade d'application client n'a pas

à mettre du code en production

pour les gens.

Au lieu de cela, leur travail consiste à faire en sorte que

l'escouade de fonctionnalité puisse mettre

son code en production facilement.

Malgré le modèle de libre-service, nous avons parfois

besoin d'un peu de synchronisation entre les équipes

lors des lancements.

Nous gérons cela en utilisant

des trains de lancement et des configurations.

Chaque application client dispose d'un train de lancement

qui part à un emploi du temps fixe.

Typiquement chaque semaine ou toutes les trois semaines

en fonction du client.

Comme dans le monde physique

en cas de départ fréquent et fiable des trains,

vous n'avez pas besoin de beaucoup de planification.

Venez et prenez le prochain train.

Supposons que ces trois escouades

construisent des trucs et

quand le prochain train arrivera

les fonctions A, B et C sont exécutées

alors que D est toujours en cours.

Le train de lancement comprendra les 4 fonctions,

mais l'inachevée est caché

à l'aide d'une configuration.

Ça peut paraître bizarre

de déployer des fonctionnalités inachevées

et de les cacher.

Mais, c'est sympa parce que

cela expose le problème de l'intégration à un stade précoce

et minimise le besoin de branches de code.

Le code non chargé cache les problèmes

et c'est une forme de dette technique.

Les configurations de fonctionnalités nous permettent de façon dynamique

de montrer et cacher des trucs en test

ainsi qu'en production.

En plus de cacher les travaux inachevés,

nous l'utilisons pour les A/B tests

pour lancer progressivement des fonctionnalités finies.

Tous nos processus de déploiement sont meilleurs

qu'avant.

Mais nous constatons encore de nombreux domaines d'amélioration

donc nous continuerons à expérimenter.

Cela peut sembler un modèle effrayant

laisser chaque escouade déployer son propre code

en production

sans aucun contrôle centralisé formel.

et on foire parfois.

Mais nous avons appris que la confiance

est plus important que le contrôle.

Pourquoi engager quelqu'un

en qui nous n'avons pas confiance.

Agile à l'échelle exige

de la confiance à l'échelle

et ça veut dire qu'il n' y a pas de politique.

Cela signifie aussi qu'il n' y a pas de peur.

La peur ne tue pas seulement la confiance.

Elle tue l'innovation

parce qu'avec la peur d'être puni

les gens n'oseront pas essayer de nouvelles choses.

Parlons donc d'échec.

En fait, non

faisons une pause.

Debout, debout,

prendre un café.

Laissez ce truc décanter un peu.

et puis revenez

quand vous serez prêt pour la 2ème partie. D'accord?