Merci pour votre confiance
Reinventing the way we work
L’équipe autonome
Retours d’expériences
Agile Grenoble 2020
2
Qui sommes nous ?
• Pierre FAUVEL @pierre_fauvel
et Kevin DELFOUR @kevin_delfour
3
Pourquoi cette conférence ?
• Expérience chez eVoyageurs au sein d’une équipe autonome.
• Echanges avec des membres ou ex de Sogilis Lyon, entreprise libérée.
4
Une équipe autonome
• Une équipe autonome, une bulle : une
startup au sein de l’entreprise.
• Une poche d’autonomie dans une
entreprise qui n’est pas libérée.
• Je n’ai jamais vu ça poussé à ce
point
5
Contexte eVoyageurs
• Equipe « autonome » qui réalisait pour la BU marketing
• Un DataLake rassemblant des données de sources variées (3,5 ETP)
• Une « zone Gold » pré-traitant et recoupant ces données (3,5 ETP data engineers)
• Une BI s’appuyant sur cette zone Gold (4 ETP BI engineers)
• Une PO
• Un Scrum Master temps plein. Je l’ai rejointe en Octobre 2019 et quittée
en Avril 2020 (projet arrêté cause Covid)
• Côté data engineers elle a choisit hbase en Octobre 2019 et Delta Lake en
Février 2020
Datalake
Zone Gold
BI
6
Un contrat d’équipe autonome
eVoyageurs
7
Le contrat
• Qu’attend-on d’une équipe
autonome ?
• Construction progressive de l’équipe
• Contrat tacite
J’aurais du le réaffirmer
8
Méthodologie
• A priori Scrum, vélocité, engagements
de sprint
• Animation des cérémonies, notamment
la revue
Chaque équipe pouvait choisir la
meilleure méthodo
9
Roadmap
• Le Product Owner est responsable de
la roadmap
• Le Product Owner définit les releases
successifs
Une vraie product owner
10
KPI
• L’équipe doit définir et mesurer des KPIs mais elle a le
choix:
- KPI business ( nombre de rejets, écart d’un indicateur
avec une autre source, voire impact sur la performance
financière…)
- KPI techniques (durée d’une mise en production,
fréquence et fiabilité des mises en production)
Très positif, responsabilisant, contextuel
11
Architecture
• L’équipe a le choix de l’architecture,
avec le support de la direction
technique
• L’équipe est libre de choisir ses
technologies et de les changer
Très motivant, mais une grande
responsabilité
12
Qualité des développements
• L’équipe est garante de sa maîtrise de ce
qu’elle développe
• L’équipe met en place des tests
automatiques, tests de perf, …
Très motivant, mais une grande
responsabilité
13
Delivery
• L’équipe met en place la CI/CD
• Tout sprint part en production
• L’équipe réalise les mises en
production
Impressionnant de voir une équipe
assumer ça presque seule
14
Exploitation
• Avec le support de l’équipe de suivi
de production, l’équipe assure le
suivi de la production :
• Supervision automatique des services
• Support de niveau 2 et 3
• Gestion des backups et congés
Très responsabilisant : l’équipe
gère son produit jusqu’au bout
15
Contrat
Méthodologie
KPIs
Roadmap
Qualité des devs
Architecture
Exploitation
Delivery
Le contrat
16
Les décisions de la vie d’une équipe
autonome
eVoyageurs
17
La prise de décision
• Points d’équipe (malgré le meeting
bashing)
• Décision collective (à 10)
• Assumer les décisions d’équipe
• Publier les décisions
Ca crée une réelle dynamique
d’équipe, même s’il faut parfois
donner l’impulsion
18
L’exclusion d’un membre
• Le côté « collectif » ne convient pas à
tous
• Personne n’a envie d’avoir « du sang sur
les mains »
• Chacun doit exprimer son ressenti
Un grand gâchis que nous n’avons pas
su éviter au fil de l’eau
19
Le recrutement
• L’équipe est tentée de recruter
moins expérimenté
• Faut-il afficher les défauts du
contexte ?
Un manque de maturité de l’équipe
20
Scission
• Que faire quand il y a deux équipes
dans l’équipe ? Création d’une
équipe Datalake.
Une très bonne décision contraire à
l’avis du management
21
Fusion
• La PO a promu l’idée de regrouper
Zone Gold & BI en une seule
équipe.
Une bonne décision contraire à
mon avis 
22
Les décisions techniques
• La tentation de vouloir se faire
plaisir
Chaque changement est une prise
de risque au niveau roadmap
23
Les décisions d’investissement
• Levier sur la dette technique
Réduire la dette technique
engendre un risque sur la roadmap
24
La fin
• La fin de l’équipe aurait-elle pu être
évitée ?
Membres d’une startup mais pas
fondateurs intéressés au capital.
Si on avait su on aurait pas pris les
mêmes décisions.
25
Les décisions
Prise de décision
Exclusion
Recrutement
Scission
Fusion
Décisions techniques
Décisions d’investissement
La fin
26
L’équipe autonome et la PO, le SM
et le manager.
eVoyageurs
27
Eux et nous
• L’équipe qui voit les strates de
management comme des externes
qui la privent parfois de son
autonomie
• « On a imposé la techno X » vs « On
a imposé de prendre une décision en
Octobre car le temps pressait »
28
Le rôle de la PO
• Le PO assurait la relation avec le
client (le marketing)
• Rôle de représentant « de
commerce » de l’équipe auprès du
client, auprès des autres équipes.
29
Roadmap 1/2
• Le management rappelle les
contraintes au Scrum Master qui fait
émerger une action de l'équipe
• « Je vous fais confiance mais vous
êtes sûrs que ça va ? »
• « On a besoin d'une roadmap »
30
Roadmap 2/2
• Comparer nombre de sprints
budgétés vs nombre de sprint
indispensables pour la MeP.
• Exercice anxiogène de prise de recul
que l'équipe ne fait pas d'elle-même.
Pas le même sentiment d’urgence
31
Le Scrum Master et l’équipe 1/3
• La maturité de l’équipe c’est sa capacité à
tenir le contrat d’autonomie.
• J’ai du résister à mes pulsions de leadership
pour le laisser émerger de l’équipe.
• Parfois un peu de gestion de projet
s’impose (roadmap, crise, première mep)
32
Le Scrum Master et l’équipe 2/3
• Parfois on anticipe à tort que
l'équipe ne va pas jouer le jeu
(cf les prédictions auto-réalisatrices)
1. Je crois qu'ils ne vont pas s'en
occuper
2. Je m'en occupe
3. Ils ne s'en occupent (donc) pas
33
Le Scrum Master et l’équipe 3/3
• J’indiquais un problème et faisais émerger
une solution.
• Parfois j’affirmais une stratégie que l'équipe
conteste pour en proposer une autre.
• Parfois même le problème lui-même était
reformulé
34
Une équipe autonome
sans Scrum Master ni Product Owner ?
• Le Scrum Master fait partie de l’équipe
autonome, comme le Product Owner.
• Certaines équipes matures sollicitaient un
Scrum Master à la demande ou à temps très
partiel (facilitation essentiellement)
• Notion de rôle tournant pour certaines
activités (préparation de la revue)
35
Gérer une équipe autonome
Le rôle de la PO
Eux et nous
La Roadmap
Le SM et
l’équipe
Une équipe autonome
sans SM ni PO ?
36
Conclusion
eVoyageurs
37
Qu’est ce qui était top ?
• Enfin du « vrai » scrum, avec une équipe vraiment auto-organisée, un vrai product owner, …
• Ambiance super responsabilisante, tous étaient naturellement engagés
• Le rôle de SM se déplace vers l’intelligence collective
• Le SM et la PO étaient eux-mêmes très responsabilisés
• Un de mes meilleur souvenirs professionnels
38
Qu’est-ce qui aurait pu être mieux ?
• Un partage explicite et clair du contrat
• La confiance équipe vers le management
• Une meilleure résolution des conflits
• Une équipe qui intègre mieux la contrainte « roadmap »
39
Si c’était à refaire ?
• Je signe sans hésiter et avec joie
• Encore plus de travail sur l’humain, la concorde.
• Je repose le contrat au début et la notion d’équipe « startup » dont chaque membre
est actionnaire, et les fais vivre sur toute la durée.
• Je mets en production plus tôt, quitte à faire ensuite du rework.
40
Dans une entreprise « libérée »
Sogilis
Contexte Sogilis
• Equipe « autonome » au sein d’une structure libérée
• Gestion d’une entreprise sans contrôle ni manager
• Un directeur d’agence (nécessaire pour la gestion de l’entreprise)
• Des décisions communautaires
• Objectif : laisser toute l’autonomie possible
• Responsabiliser au-delà des projets/missions
Une équipe autonome
Sogilis
Organisation
• Pas de management donc le chaos ?
• Fonctionnement Scrumban
• Organisation simple réduit au
nécessaire
Sprints
• Pas de vélocité
• Pas de KPI mais des objectifs par
sprint
• Des objectifs atteints
Architecture
• Ceux qui font, savent ce qu’ils leurs
faut
• Peu de dérive sur des choix de
technologies exotiques ou non
maitrisées
Qualité des développements
• L’équipe est garante de ses
développements
• Qualité avant tout
Delivery
• L’équipe met en place le CI/CD en
accord avec le budget du client
• Jamais d’outil superflu, des coûts
maitrisés
Les décisions dans la vie de cette
équipe autonome
Sogilis
La prise de décision
• Points d’équipes
• Prise d’initiative avec sollicitation d’avis
• Décision collégiale si besoin
• Pas d ’erreur mais que de
l’apprentissage.
• Beaucoup d’apprentissage. Un
cadre déstressant.
Gestion de l’équipe
• Feedback et « Retours 360 »
• Résolution des conflits en 1to1
• Mise en place de médiateur interne à
l’équipe en cas de gros conflits
• Décision collégiale
• Plus d’échanges pour éviter les
conflits qui se gangrènent
Le recrutement
• L’équipe recrute ces futurs co-
équipiers
• Entretien incluant beaucoup de
pédagogie et de transparence
• Transparence totale sur la vie de
l’entreprise et de l’équipe
Gérer une équipe autonome
Sogilis
Constitution de l’équipe
• Des équipes constituées d’ancien
pour leurs XP et de jeunes
• Tout le monde a son mot à dire
• Pas de langue de bois, tout le
monde apporte sa contribution
Le rôle de PO
• Pas de poste de PO
• Mais un rôle Proxy PO tenu par un
membre de l’équipe (pour initier le
client)
• Sensibilisation au dialogue avec
le client
Le rôle de Scrum Master
• Pas de Scrum Master
• Equipe petite, et intéressée par
l’Agilité
• Organisation est pensée Agile
Roadmap
• Uniquement entre le client et
l’équipe
• Rassurer le client sur son budget
(MVP et MeP)
• Rassurer l’équipe sur le futur
Conclusions
Sogilis
Qu'est-ce qui était bien ?
• Autonomie
• Confiance
• Prises d’initiatives
Qu'est-ce qui était moins bien ?
• Taille critique (7-8 personnes) : tout le monde ne peux pas plancher sur le
même problème
• Décisions qui s’enlisent
• Création de sous groupe de travail
Qu’est ce que je changerais
si je devais le refaire ?
• Un peu plus de pédagogie à destination des plus jeunes
• Plus de confiance en l’équipe dés le début
• Pousserais le concept d’autonomisation encore plus loin
The End !
Merci pour votre attention
Au plaisir d’échanger avec vous 😄
https://roti.express/r/ag20-014

Equipes autonomes

  • 1.
    Merci pour votreconfiance Reinventing the way we work
  • 2.
  • 3.
    Qui sommes nous? • Pierre FAUVEL @pierre_fauvel et Kevin DELFOUR @kevin_delfour 3
  • 4.
    Pourquoi cette conférence? • Expérience chez eVoyageurs au sein d’une équipe autonome. • Echanges avec des membres ou ex de Sogilis Lyon, entreprise libérée. 4
  • 5.
    Une équipe autonome •Une équipe autonome, une bulle : une startup au sein de l’entreprise. • Une poche d’autonomie dans une entreprise qui n’est pas libérée. • Je n’ai jamais vu ça poussé à ce point 5
  • 6.
    Contexte eVoyageurs • Equipe« autonome » qui réalisait pour la BU marketing • Un DataLake rassemblant des données de sources variées (3,5 ETP) • Une « zone Gold » pré-traitant et recoupant ces données (3,5 ETP data engineers) • Une BI s’appuyant sur cette zone Gold (4 ETP BI engineers) • Une PO • Un Scrum Master temps plein. Je l’ai rejointe en Octobre 2019 et quittée en Avril 2020 (projet arrêté cause Covid) • Côté data engineers elle a choisit hbase en Octobre 2019 et Delta Lake en Février 2020 Datalake Zone Gold BI 6
  • 7.
    Un contrat d’équipeautonome eVoyageurs 7
  • 8.
    Le contrat • Qu’attend-ond’une équipe autonome ? • Construction progressive de l’équipe • Contrat tacite J’aurais du le réaffirmer 8
  • 9.
    Méthodologie • A prioriScrum, vélocité, engagements de sprint • Animation des cérémonies, notamment la revue Chaque équipe pouvait choisir la meilleure méthodo 9
  • 10.
    Roadmap • Le ProductOwner est responsable de la roadmap • Le Product Owner définit les releases successifs Une vraie product owner 10
  • 11.
    KPI • L’équipe doitdéfinir et mesurer des KPIs mais elle a le choix: - KPI business ( nombre de rejets, écart d’un indicateur avec une autre source, voire impact sur la performance financière…) - KPI techniques (durée d’une mise en production, fréquence et fiabilité des mises en production) Très positif, responsabilisant, contextuel 11
  • 12.
    Architecture • L’équipe ale choix de l’architecture, avec le support de la direction technique • L’équipe est libre de choisir ses technologies et de les changer Très motivant, mais une grande responsabilité 12
  • 13.
    Qualité des développements •L’équipe est garante de sa maîtrise de ce qu’elle développe • L’équipe met en place des tests automatiques, tests de perf, … Très motivant, mais une grande responsabilité 13
  • 14.
    Delivery • L’équipe meten place la CI/CD • Tout sprint part en production • L’équipe réalise les mises en production Impressionnant de voir une équipe assumer ça presque seule 14
  • 15.
    Exploitation • Avec lesupport de l’équipe de suivi de production, l’équipe assure le suivi de la production : • Supervision automatique des services • Support de niveau 2 et 3 • Gestion des backups et congés Très responsabilisant : l’équipe gère son produit jusqu’au bout 15
  • 16.
  • 17.
    Les décisions dela vie d’une équipe autonome eVoyageurs 17
  • 18.
    La prise dedécision • Points d’équipe (malgré le meeting bashing) • Décision collective (à 10) • Assumer les décisions d’équipe • Publier les décisions Ca crée une réelle dynamique d’équipe, même s’il faut parfois donner l’impulsion 18
  • 19.
    L’exclusion d’un membre •Le côté « collectif » ne convient pas à tous • Personne n’a envie d’avoir « du sang sur les mains » • Chacun doit exprimer son ressenti Un grand gâchis que nous n’avons pas su éviter au fil de l’eau 19
  • 20.
    Le recrutement • L’équipeest tentée de recruter moins expérimenté • Faut-il afficher les défauts du contexte ? Un manque de maturité de l’équipe 20
  • 21.
    Scission • Que fairequand il y a deux équipes dans l’équipe ? Création d’une équipe Datalake. Une très bonne décision contraire à l’avis du management 21
  • 22.
    Fusion • La POa promu l’idée de regrouper Zone Gold & BI en une seule équipe. Une bonne décision contraire à mon avis  22
  • 23.
    Les décisions techniques •La tentation de vouloir se faire plaisir Chaque changement est une prise de risque au niveau roadmap 23
  • 24.
    Les décisions d’investissement •Levier sur la dette technique Réduire la dette technique engendre un risque sur la roadmap 24
  • 25.
    La fin • Lafin de l’équipe aurait-elle pu être évitée ? Membres d’une startup mais pas fondateurs intéressés au capital. Si on avait su on aurait pas pris les mêmes décisions. 25
  • 26.
    Les décisions Prise dedécision Exclusion Recrutement Scission Fusion Décisions techniques Décisions d’investissement La fin 26
  • 27.
    L’équipe autonome etla PO, le SM et le manager. eVoyageurs 27
  • 28.
    Eux et nous •L’équipe qui voit les strates de management comme des externes qui la privent parfois de son autonomie • « On a imposé la techno X » vs « On a imposé de prendre une décision en Octobre car le temps pressait » 28
  • 29.
    Le rôle dela PO • Le PO assurait la relation avec le client (le marketing) • Rôle de représentant « de commerce » de l’équipe auprès du client, auprès des autres équipes. 29
  • 30.
    Roadmap 1/2 • Lemanagement rappelle les contraintes au Scrum Master qui fait émerger une action de l'équipe • « Je vous fais confiance mais vous êtes sûrs que ça va ? » • « On a besoin d'une roadmap » 30
  • 31.
    Roadmap 2/2 • Comparernombre de sprints budgétés vs nombre de sprint indispensables pour la MeP. • Exercice anxiogène de prise de recul que l'équipe ne fait pas d'elle-même. Pas le même sentiment d’urgence 31
  • 32.
    Le Scrum Masteret l’équipe 1/3 • La maturité de l’équipe c’est sa capacité à tenir le contrat d’autonomie. • J’ai du résister à mes pulsions de leadership pour le laisser émerger de l’équipe. • Parfois un peu de gestion de projet s’impose (roadmap, crise, première mep) 32
  • 33.
    Le Scrum Masteret l’équipe 2/3 • Parfois on anticipe à tort que l'équipe ne va pas jouer le jeu (cf les prédictions auto-réalisatrices) 1. Je crois qu'ils ne vont pas s'en occuper 2. Je m'en occupe 3. Ils ne s'en occupent (donc) pas 33
  • 34.
    Le Scrum Masteret l’équipe 3/3 • J’indiquais un problème et faisais émerger une solution. • Parfois j’affirmais une stratégie que l'équipe conteste pour en proposer une autre. • Parfois même le problème lui-même était reformulé 34
  • 35.
    Une équipe autonome sansScrum Master ni Product Owner ? • Le Scrum Master fait partie de l’équipe autonome, comme le Product Owner. • Certaines équipes matures sollicitaient un Scrum Master à la demande ou à temps très partiel (facilitation essentiellement) • Notion de rôle tournant pour certaines activités (préparation de la revue) 35
  • 36.
    Gérer une équipeautonome Le rôle de la PO Eux et nous La Roadmap Le SM et l’équipe Une équipe autonome sans SM ni PO ? 36
  • 37.
  • 38.
    Qu’est ce quiétait top ? • Enfin du « vrai » scrum, avec une équipe vraiment auto-organisée, un vrai product owner, … • Ambiance super responsabilisante, tous étaient naturellement engagés • Le rôle de SM se déplace vers l’intelligence collective • Le SM et la PO étaient eux-mêmes très responsabilisés • Un de mes meilleur souvenirs professionnels 38
  • 39.
    Qu’est-ce qui auraitpu être mieux ? • Un partage explicite et clair du contrat • La confiance équipe vers le management • Une meilleure résolution des conflits • Une équipe qui intègre mieux la contrainte « roadmap » 39
  • 40.
    Si c’était àrefaire ? • Je signe sans hésiter et avec joie • Encore plus de travail sur l’humain, la concorde. • Je repose le contrat au début et la notion d’équipe « startup » dont chaque membre est actionnaire, et les fais vivre sur toute la durée. • Je mets en production plus tôt, quitte à faire ensuite du rework. 40
  • 41.
    Dans une entreprise« libérée » Sogilis
  • 42.
    Contexte Sogilis • Equipe« autonome » au sein d’une structure libérée • Gestion d’une entreprise sans contrôle ni manager • Un directeur d’agence (nécessaire pour la gestion de l’entreprise) • Des décisions communautaires • Objectif : laisser toute l’autonomie possible • Responsabiliser au-delà des projets/missions
  • 43.
  • 44.
    Organisation • Pas demanagement donc le chaos ? • Fonctionnement Scrumban • Organisation simple réduit au nécessaire
  • 45.
    Sprints • Pas devélocité • Pas de KPI mais des objectifs par sprint • Des objectifs atteints
  • 46.
    Architecture • Ceux quifont, savent ce qu’ils leurs faut • Peu de dérive sur des choix de technologies exotiques ou non maitrisées
  • 47.
    Qualité des développements •L’équipe est garante de ses développements • Qualité avant tout
  • 48.
    Delivery • L’équipe meten place le CI/CD en accord avec le budget du client • Jamais d’outil superflu, des coûts maitrisés
  • 49.
    Les décisions dansla vie de cette équipe autonome Sogilis
  • 50.
    La prise dedécision • Points d’équipes • Prise d’initiative avec sollicitation d’avis • Décision collégiale si besoin • Pas d ’erreur mais que de l’apprentissage. • Beaucoup d’apprentissage. Un cadre déstressant.
  • 51.
    Gestion de l’équipe •Feedback et « Retours 360 » • Résolution des conflits en 1to1 • Mise en place de médiateur interne à l’équipe en cas de gros conflits • Décision collégiale • Plus d’échanges pour éviter les conflits qui se gangrènent
  • 52.
    Le recrutement • L’équiperecrute ces futurs co- équipiers • Entretien incluant beaucoup de pédagogie et de transparence • Transparence totale sur la vie de l’entreprise et de l’équipe
  • 53.
    Gérer une équipeautonome Sogilis
  • 54.
    Constitution de l’équipe •Des équipes constituées d’ancien pour leurs XP et de jeunes • Tout le monde a son mot à dire • Pas de langue de bois, tout le monde apporte sa contribution
  • 55.
    Le rôle dePO • Pas de poste de PO • Mais un rôle Proxy PO tenu par un membre de l’équipe (pour initier le client) • Sensibilisation au dialogue avec le client
  • 56.
    Le rôle deScrum Master • Pas de Scrum Master • Equipe petite, et intéressée par l’Agilité • Organisation est pensée Agile
  • 57.
    Roadmap • Uniquement entrele client et l’équipe • Rassurer le client sur son budget (MVP et MeP) • Rassurer l’équipe sur le futur
  • 58.
  • 59.
    Qu'est-ce qui étaitbien ? • Autonomie • Confiance • Prises d’initiatives
  • 60.
    Qu'est-ce qui étaitmoins bien ? • Taille critique (7-8 personnes) : tout le monde ne peux pas plancher sur le même problème • Décisions qui s’enlisent • Création de sous groupe de travail
  • 61.
    Qu’est ce queje changerais si je devais le refaire ? • Un peu plus de pédagogie à destination des plus jeunes • Plus de confiance en l’équipe dés le début • Pousserais le concept d’autonomisation encore plus loin
  • 62.
    The End ! Mercipour votre attention Au plaisir d’échanger avec vous 😄
  • 63.

Notes de l'éditeur