Le document traite des rôles et responsabilités du scrum master dans une organisation agile, en mettant en avant son rôle de facilitateurs et de coach pour l'équipe. Il aborde également la complexité des organisations et l'importance d'une approche systémique pour résoudre les problèmes et améliorer la collaboration entre les membres de l'équipe. Enfin, il évoque les défis liés à la mise en œuvre de pratiques agiles et les conflits potentiels qui peuvent survenir au sein de l'équipe.

1. Formation
Principe d’organisation Agile
Mathieu Gandin

2. Agenda
 Posture du Scrum Master
 Comprendre une organisation complexe par l’approche
systémique
 Résolution de conflit
© OCTO 201Z 2

3. Agenda
 Posture du Scrum Master
 Comprendre une organisation complexe par l’approche
systémique
 Résolution de conflit
© OCTO 2012 3

4. Objectif du Scrum Master
 En tant que Scrum Master
 je veille à ce que l'équipe délivre le maximum de valeur maintenant et
dans le futur
 je suis là pour aider à chaque membre de l'équipe à atteindre leur pleine
capacité
© OCTO 2012 4

5. Responsabilités du Scrum Master
 Le Scrum Master est un membre de l'équipe, et il applique les
valeurs agiles tout le temps.
 Le Scrum Master applique les principes et bonnes pratiques
d'ingénierie issues des méthodes agiles
 Le Scrum Master est un facilitateur, un animateur, et permet de
développer et renforcer la communication entre les membres
de l'équipe
 Le Scrum Master a une expérience des projets Agiles
 Le Scrum Master propose du coaching en 1-2-1 aux membres
de l'équipe
© OCTO 2012 5

6. Responsabilités du Scrum Master
 Le Scrum Master identifie les risques et freins de l'équipe et
l'aide à les lever
 Le Scrum Master communique à l'équipe de l'avancement de
son travail
 Le Scrum Master croit en l'intelligence collective de l'équipe :
L'équipe est la seule à même de prendre la meilleure décision
en regard de l'information dont elle a à sa disposition
 Le Scrum Master priorise son travail pour apporter le maximum
de valeur à l'équipe
 Le Scrum Master est sensibilisé à la notion d'amélioration
continue
© OCTO 2012 6

7. Style de management
Directif Explicatif
Adaptatif
Délégatif Participatif
© OCTO 2012 7

8. Agenda
 Posture du Scrum Master
 Comprendre une organisation complexe par l’approche
systémique
 Résolution de conflit
© OCTO 2012 8

9. Un changement ça prend du temps
Idée
transformatrice
Ancien Statu quo Chaos Apprentissage Nouveau Statu quo
© OCTO 2012 9

10. Complexité des organisations
 Système non-linéaire
 Changement paradigme
 « Plus de … », « moins de … »
 Une action peut découler de plusieurs causes différentes et une
action peut engendrer plusieurs conséquence différentes
© OCTO 2012 10

11. Approche systémique
 Dans une approche systémique, un système est un ensemble de
composants qui sont interdépendants les uns des autres
 L’approche systémique s’oppose souvent à une approche
scientifique plus classique qui fait l’hypothèse que tout
problème complexe peut être décomposé en problème plus
simple et indépendant
 Cette hypothèse négligeant les interdépendances, qui vont se
révéler très importantes si on prend l’hypothèse d’une
organisation où chaque personne qui en font partie sont en
relation
 Relire une seconde fois, plus lentement
© OCTO 2012 11

12. Approche systémique
Leader
Feedbacks
ressources Résultats
Système
aléatoire Autres
 Planifier son plan d’action en se posant les questions suivantes : qu’est-
ce que je veux voir arriver ? Comment est-ce que je peux l’obtenir ?
 Puis observer ce qui se passe réellement. Est-ce que ce que j’observe est
stable ? Visible ? Explicite ?
 Comparer ce que j’ai observé avec ce qui était planifié et adapter mon
plan d’action
© OCTO 2012

13. Atelier #1
Le jeu du
Frigo
© OCTO 2012 13

14. Approche systémique
Variable
mesurée
© OCTO 2012 14

15. Approche systémique
Variable
Mesurable
© OCTO 2012 15

16. Approche systémique
Relation
d’influence
© OCTO 2012 16

17. Approche systémique
Influence
négative
© OCTO 2012 17

18. Approche systémique
Boucle de
renforcement
© OCTO 2012 18

19. Approche systémique
Equilibre
© OCTO 2012 19

20. Approche systémique
Effet de
retard
© OCTO 2012 20

21. Approche systémique
Limite pour
une boucle
[limite=...]
© OCTO 2012 21

22. Atelier #2
Représentation de
diagramme
systémique sur des
situations
© OCTO 2012 22

23. Jérome, chef de projet
Nous travaillons sur un projet stratégique pour une banque en ligne. Daniel (du
Marketing) est le client de ce produit.
Le projet a commencé en mars 2010 avec trois développeurs: Alex, Bruno et
Christian, plus un chef de projet (moi).
On a livré en juin la première version, qui tourne en production. Le client était super
content du résultat.
Il a plein de nouvelles idées et nous a demandé de les implémenter pour la fin de
l'année.
Au vu du nombre de fonctionnalités demandées, j'ai décidé avec mon manager de
faire rentrer cinq développeurs de plus.
Mais maintenant ça fait huit personnes à gérer, et je n'ai plus le temps. On a donc
décidé avec mon manager de faire passer Christian, le tech lead, dans un rôle de
chef de projet (à ma place). Aujourd'hui tout le monde est super occupé: entre les
réunions de coordination et la formation de nouveaux tech leads, Christian me dit
que ça fait déjà trois samedis où il a du réécrire du code. Les nouveaux ne parlent
beaucoup, je ne sais pas s'ils sont très motivés. On est déjà en octobre et pourtant
on est loin d'avoir implémenté la moitié des fonctions demandées Daniel. Il est déjà
revenu à la charge trois fois pour valider le plan de comm' du produit pour la fin de
l'année, mais je ne sais pas si ça va le faire. Help !
© OCTO 2012 23

24. Ghislaine, responsable support du département
relation client pour un site web B2B B2C
Moi je m'occupe du "service après vente" en quelque sorte: avec mon équipe on reçoit
les appels clients et on les enregistre et en fonction de la qualification du problème on
les redispatche via le bugtracker :
- chez nous avec un expert produit qui va assister le client,
- chez les développeurs si c'est un bug,
- chez la prod' si c'est un problème d'infrastructure technique,
- ou au marketing si c'est une demande de nouvelle fonctionnalité.
Je ne sais pas ce qui se passe en ce moment, mais on a de plus en plus de demandes, et
beaucoup d'appels réentrants, c'est à dire quand un client nous relance pour un
problème qu'il a déjà signalé. Mon objectif, c'est qu'un appel client soit résolu le plus
vite possible. Quand j'appelle la prod' à propos d'une fiche que leur ai transmise, ils me
disent qu'ils n'ont pas le temps, parce qu'ils sont occupés à ouvrir de nouveaux
services, et ils me demandent de rediriger la fiche vers l'équipe de développement. Avec
les développeurs, c'est devenu l'enfer; je suis obligé d'attendre une voire deux itérations
pour avoir simplement des nouvelles de ma fiche incident ! Et le scrum master me
recommande d'aller en parler au Marketing. Franchement, l'agile, je suis pas sûre que
c'était une bonne idée. Pouvez-vous m'aider à atteindre mon objectif ? Si vous avez une
idée je pourrais en parler à Gérard, le DSI (c'est un copain) mais il lui faut des arguments
"béton »
© OCTO 2012 24

25. Francis, tech lead sur le projet CRM temps réel
C'est Henri qui vous envoie ? Henri c'est le manager du service et depuis
quelque temps, il fait pas bon le croiser quand il est en colère.
Le problème qu'on a, c'est qu'on est débordé. Henri vient chaque matin
au stand up meeting et nous demande des comptes sur les bugs en
cours de correction. Il faut dire qu'on en a de plus en plus. Depuis un
mois, Henri nous met la pression pour que chaque bug soit corrigé dans
la journée. Je l'ai prévenu que si on doit corriger plus il faudra qu'on
teste moins, mais il ne veut rien savoir. Du coup, on se retrouve avec des
erreurs dûes à des corrections vite fait-mal fait, ou bien des problèmes
qu'on a déja vu plusieurs fois. En voyant ça, Henri a demandé un récap
de chaque heure passées par les développeurs. En ce
moment, l'ambiance est pourrie. Personne ne parle plus au café, et les
gens font les heures minimums, vu qu'on est tous "presta". Si vous
pouvez m'aider à parler à Henri, ça m'arrangerait.
© OCTO 2012 25

26. Paradoxe et résolution de problème

27. Problème
 Premiers développements
 Solutions ! Ca marche
 Prenons une solution déjà utilisé
 « Plus de la même chose »
 Situation d’échec
 Crise …
© OCTO 2012 27

28. Exemple de résolution de problème
 « On a des difficultés pour tester mais on a toujours utilisé des
frameworks pour corriger nos problèmes, alors on teste avec des
frameworks de mocks »
 « Plus je mock, plus le code de mes tests sont complexes »
 « Plus le code des tests sont complexes, plus j’ai des difficultés à
tester »
 « Plus j’ai des difficultés pour tester, plus j’utilise des frameworks … »
 Dans ce cas, essayons de tester avec moins de frameworks
PcRessource pcRessource = new PcRessource() {
@Override
protected URI createURI(RegistredPc pcToRegister) {
try {
return new URI("");
} catch (URISyntaxException e) {
throw new RuntimeException(e);
}
}
};
© OCTO 2012 28

29. Vélocité
On corrige
beaucoup de bugs Augmentation du
pendant l’itération rythme
Retour à un
rythme soutenable
Première étape : Deuxième étape :
Ralentir et arrêter d’accumuler de la Diminution de la dette
dette technique et apports de plus de
valeur métier
Temps
Faire moins de la même chose

30. Agenda
 Posture du Scrum Master
 Comprendre une organisation complexe par l’approche
systémique
 Résolution de conflit
© OCTO 2012 30

31. Vers la dynamique d’équipe
 Dans les équipes agiles, nous retrouvons un ensemble de rôles
prédéfinies (PO, Scrum Master, Développeurs, managers, tech-
lead …)
 Nous observons aussi certains comportements
 L’équipe résiste à de nombreux changements, et continue de
fonctionner comme avant, tout en étant labélisé « équipe agile ».
 Des personnes sont sur la défensive, et évitent certaines conversations
 Certaines personnes peuvent se révéler agressives envers d’autres
 L’équipe rencontre des difficultés pour prendre une décision afin de
résoudre un problème
 Certaines personnes manquent de confiance dans leur travail
 L’équipe recherche de nouveaux objectifs
 …
 L’équipe se forme, trouve ses marques, devient performante …
 Ces étapes sont sources de conflits (qui sont nécessaires)
© OCTO 2012 31

32. Congruence
Les
Soi
autres
Le
contexte

33. « Le blâmeur »
Les
Soi
autres
Le
contexte

34. « La carpette »
Les
Soi
autres
Le
contexte

35. « Le superordinateur »
Les
Soi
autres
Le
contexte

36. « Le distrait »
Les
Soi
autres
Le
contexte

37. Congruence et incongruence
 Reconnaître l’incongruence en soi
 Quatre émotions de base
 Joie, Colère, Tristesse et Peur
 Quelle émotion m’est la plus familière ? Celle avec qui je vis le plus
souvent ?
 Laquelle m’est la plus étrangère ? Celle que je ne connais pas ou peu ?
 Et les deux autres qui restent ? Comment je vis avec ?
 Et pour chacune d’elles : Ca se passe comment dans mon corps ? Quelle
sensation ?
© OCTO 2012 37

38. Pour revenir vers de la congruence
 Fait, Interprétation, Sentiment, Conseil
 « Quand tu dis … »
 « J’interprète … »
 « Je me sens … »
 « Je souhaites … »
 « Peux-tu … ? »
 Exemple :
 «Je viens de voir que le code que tu viens de commiter ne compile pas et
nous devons livrer ce soir et j’ai peur que nous rations cette livraison. Je
souhaiterais que tu arrêtes de développer cette User Story pour corriger
l’erreur de compilation. Peux-tu t’en occuper maintenant ? »
© OCTO 2012 38

39. © OCTO 2012 39