Deux retours d'expériences sur des équipes Scrum très autonomes, une au sein d'une entreprise classique, l'autre au sein d'une entreprise libérée

1. Merci pour votre confiance
Reinventing the way we work

2. L’équipe autonome
Retours d’expériences
Agile Grenoble 2020
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’équipe autonome
eVoyageurs
7

8. Le contrat
• Qu’attend-on d’une équipe
autonome ?
• Construction progressive de l’équipe
• Contrat tacite
J’aurais du le réaffirmer
8

9. 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

10. Roadmap
• Le Product Owner est responsable de
la roadmap
• Le Product Owner définit les releases
successifs
Une vraie product owner
10

11. 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

12. 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

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 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

15. 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

16. Contrat
Méthodologie
KPIs
Roadmap
Qualité des devs
Architecture
Exploitation
Delivery
Le contrat
16

17. Les décisions de la vie d’une équipe
autonome
eVoyageurs
17

18. 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

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’é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

21. 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

22. 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

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
• 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

26. Les décisions
Prise de décision
Exclusion
Recrutement
Scission
Fusion
Décisions techniques
Décisions d’investissement
La fin
26

27. L’équipe autonome et la 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 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. Conclusion
eVoyageurs
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 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

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. Une équipe autonome
Sogilis

44. Organisation
• Pas de management donc le chaos ?
• Fonctionnement Scrumban
• Organisation simple réduit au
nécessaire

45. Sprints
• Pas de vélocité
• Pas de KPI mais des objectifs par
sprint
• Des objectifs atteints

46. Architecture
• Ceux qui font, 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 met en place le CI/CD en
accord avec le budget du client
• Jamais d’outil superflu, des coûts
maitrisés

49. Les décisions dans la vie de cette
équipe autonome
Sogilis

50. 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.

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’é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

53. Gérer une équipe autonome
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 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

56. Le rôle de Scrum Master
• Pas de Scrum Master
• Equipe petite, et intéressée par
l’Agilité
• Organisation est pensée Agile

57. Roadmap
• Uniquement entre le client et
l’équipe
• Rassurer le client sur son budget
(MVP et MeP)
• Rassurer l’équipe sur le futur

58. Conclusions
Sogilis

59. Qu'est-ce qui était bien ?
• Autonomie
• Confiance
• Prises d’initiatives

60. 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

61. 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

62. The End !
Merci pour votre attention
Au plaisir d’échanger avec vous 😄

63. https://roti.express/r/ag20-014