Vous êtes en fonctionnement agile mais ça ne marche pas ? Vous ne vous servez pas de l’agilité et doutez que ça puisse s’appliquer à votre équipe ? Ce REX est fait pour vous ! Nous vous proposons de retrouver l’esprit de l’agilité en comparant deux expériences client contradictoires. D’un côté l’application quasi stricte des cérémoniels décrits dans la méthode Scrum, de l’autre une application très adaptée des principes de l’agilité. Quels sont les effets observés dans chacun des cas et quels pièges peuvent être évités lors de l’application de la méthode ?

1. Agilité, n’oublions pas les valeurs

2. Agilité, n’oublions pas les valeurs
Deux expériences client contradictoires :
● Application quasi stricte des cérémoniels Scrum
● Application adaptée des principes du manifeste l’agile
Quels sont les effets observés ?
Quels pièges peuvent être évités ?

3. [REX]
L’agilité au détriment de l’équipe et du
projet

4. Le contexte du projet
● Intranet d’une grande entreprise
● 120 000 utilisateurs possibles, 2000
simultanés
● En place depuis 2011
● La cellule de développement vend ses
prestations aux autres divisions du groupe
● Projet développé pour sa première version
en 6 mois

5. Coté technique
● Portail Liferay très customisé
● Important code legacy
● Equipe permanente de 3 à 8 développeurs
sur la partie socle
● 1 à 3 module(s) développés simultanément
avec des équipes réduites (1 à 3
développeur(s))

6. Agilité
● Mise en place depuis le début
● Tous les rôles scrum présents : scrum
master, product owner, développeurs
● Rôles supplémentaires : experts, testeurs,
directeur de projet
● Tous les rituels scrum présents et adaptés
au fonctionnement de la cellule

8. Et pourtant ...
● Une équipe frustrée et sous pression
● Un scrum master démotivé
● Un turn over important
● Des retards de livraison et de nombreux
bugs
● Une PO tendue et surbookée
● Une dette technique croissante et mal
surveillée

9. Comment en arrive-t-on là ?
Les rituels sont importants pour structurer l’
équipe et son fonctionnement!
Mais que se passe-t-il lorsque les valeurs qu’
ils véhiculent sont oubliées en chemin ?

10. Le plan
1. Le Sprint
2. Le Stand Up
3. Le Sprint Planning
4. La Sprint Review
5. La rétrospective
6. Conclusion

11. Le sprint
Le but d’un sprint est de livrer un incrément du produit dans une période de
temps courte afin d’en maîtriser la complexité technique et fonctionnelle. Pour
cela :
● Le but du sprint ne peut être modifié
● La composition de l'équipe reste constante
● La qualité n'est pas négociable
Pendant un an le sonar du projet pointait sur une mauvaise url!
On ne s’en est rendu compte qu’au hasard d’une absence de la PO et
donc d’US dans le sprint : le seul moment où l’équipe a été autorisée à
faire de la qualimétrie… Le score était descendu à 47% de conformation
aux règles !

12. Le sprint
● La liste d'items est sujette à négociations entre le PO et l'équipe de
développement.
L’équipe de développement n’est pas consultée pour le choix des US, ne
connaît pas sa capacité de production et ne connaît pas non plus le but du
sprint quand il commence…
Ce manque de visibilité provoque du stress dans l’équipe qui ne sait
plus comment prioriser et s’organiser !

13. Le plan
1. Le Sprint
2. Le Stand Up
3. Le Sprint Planning
4. La Sprint Review
5. La rétrospective
6. Conclusion

14. Le stand up
● Synchronisation de l’équipe
Les interventions lors du stand up tiennent plus de l’interrogation orale sur
les temps de développement...
● Évaluation de l’avancement vers le but de l’itération
Le chiffrage estimé est le chiffrage obligatoire, le dépasser c’est mettre le
sprint en danger parce qu’il est complet à quasiment 100%
Trop de dépassements provoquent une convocation seul à seul avec le
scrum master...

15. Le stand up
● Collecte d’informations nécessaires à l’auto-organisation
● Inspection et adaptation
En cas de problème, le scrum master exige l’intervention d’un expert
( sorte de pompier qui est supposé sauver le chiffrage et navigue d’un dev
à l’autre toute la journée pour sauver les meubles )
Les devs sont infantilisés et humiliés dans leur façon de travailler, le stress
de dépasser le chiffrage est omniprésent.
L’intervention systématique des experts ralentit l’apprentissage sur les
technos et le produit et réduit l’efficacité de l’équipe !

16. Le plan
1. Le Sprint
2. Le Stand Up
3. Le Sprint Planning
4. La Sprint Review
5. La rétrospective
6. Conclusion

17. Le sprint planning
Le but de la réunion de planification d’itération est que le PO et l’équipe
trouvent ensemble le but du sprint et son organisation.
L’équipe chiffre les US proposées par le PO à l’aide du backlog priorisé, du
dernier incrément réalisé et de la capacité de production du prochain sprint.
● Le backlog n’est pas priorisé, la PO attend le chiffrage pour faire un choix
budgétaire, pour cela elle rédige une cinquantaine d’US!
○ Elle est fatiguée et tendue en permanence
○ Quand elle est absente, plus rien n’avance
○ Les US sont souvent de qualité très moyenne

18. Le sprint planning
● L’équipe ne dispose pas du dernier incrément ni de la capacité de
production du prochain sprint…
● Au bout de 3 ou 4 heures tout le monde se désintéresse un peu ce qui
impacte fortement la qualité des chiffrages !
L’équipe détermine ensuite le but du sprint et le découpage des tâches pour le
début du sprint.
● Le choix des US traitées dans le sprint est laissé entièrement au choix de
la PO qui le communique souvent 2 à 3 jours après le début du sprint
Ce manque de visibilité stresse l’équipe et le scrum master qui est obligé
de “mendier” les US et de combler les “trous” avec des anomalies datant
souvent de plusieurs mois (backlog séparé).

19. Le plan
1. Le Sprint
2. Le Stand Up
3. Le Sprint Planning
4. La Sprint Review
5. La rétrospective
6. Conclusion

20. La sprint review
Le but de la revue est de présenter les items sélectionnés en début de sprint et
de les valider avec le PO.
● Toutes les US possibles, même non testées sont présentées, l’important
est d’en présenter un MAXIMUM
L’équipe présente les items réalisés puis fait le bilan du sprint avec le PO et
remet à jour le backlog.
● Un grand nombre de bugs et de manques sont soulevés
○ la PO est blasée la plupart du temps, quelquefois en colère
○ le SM a manifestement envie de disparaître sous terre, il soupire tout
le long des démos en notant toutes les remarques

21. La sprint review
L’équipe fait ensuite le point sur l’avancement du projet avec toutes les parties
prenantes, et ajuste la planification du projet en fonction des opportunités
découvertes.
● A la fin de la review aucun bilan n’est fait, le backlog n’est pas présenté…
En réalité tout le monde s’enfuit, satisfait si aucun clash n’a eu lieu…
● Aucune visibilité n’est donnée sur l’évolution du produit. Tout le monde s’
en plaint systématiquement, le directeur de projet en tête … La motivation
d’arriver au bout du sprint suivant baisse baisse baisse….
● Le principe est de noter tous les bugs qui seront corrigés dans la tâche
retour de démo, pour future validation lors d’un sprint de recette. Les
retours de démo ne sont pas comptabilisés dans les US de départ !
Jackpot !!

22. Le plan
1. Le Sprint
2. Le Stand Up
3. Le Sprint Planning
4. La Sprint Review
5. La rétrospective
6. Conclusion

23. La rétrospective
Au début systématique à la fin de chaque sprint, elle a été abandonnée petit à
petit sur décision du scrum master
Elle réunit toute l’équipe, PO compris
● Seule l’équipe de développement, les experts, les testeurs et le scrum
master étaient conviés
● La rétrospective sert en réalité de défouloir aux développeurs, fatigués de
la pression mise sur eux. En particulier à l’encontre du PO et du directeur
de projet… C’est une suite de coups de gueule….

24. La rétrospective
L’inspection de l’itération précédente pour déterminer les éléments à garder,
ceux à améliorer.
● Le SM qui en a marre de se battre contre des moulins à vent, hausse les
épaules la plupart du temps…
Cela conduit à l’élaboration d’un plan d’action d’améliorations pour l’itération
suivante
● C’est un moment d’euphorie passagère pour les devs, certaines fois des
décisions sensées ont même été prises dans un grand élan de bonne
volonté générale !

25. La rétrospective
● Les plans d’actions proposés sont ignorés quand ils concernent la
hiérarchie de la cellule ou les relations avec le client, ce qui conduit à plus
de frustration de l’équipe…!
● Les plans d’action concernant le fonctionnement de l’équipe sont oubliés
après quelques jours en règle générale, et jamais rappelés…. L’équipe est
démotivée, et il n’y a aucun lead sur le sujet : les experts sont concernés
mais trop débordés pour s’en occuper….

26. Le plan
1. Le Sprint
2. Le Stand Up
3. Le Sprint Planning
4. La Sprint Review
5. La rétrospective
6. Conclusion

27. Conclusion
Les valeurs de transparence, d’inspection et d’adaptation
doivent rester au centre des préoccupations de l’équipe.
Le but des rituels est de rappeler ces valeurs et de les
remettre au coeur du processus du développement à
chaque moment clé. Ils n’ont pas de valeur intrinsèque!
Ce que montre l’expérience chez mon client c’est que
lorsqu’on cesse de s’adapter, de surveiller, et de
communiquer, malgré les rituels, on ne fait pas d’agilité.

28. Questions
?

29. [REX]
L’agilité au service de l’équipe et du projet

30. Sommaire
Contexte
Pourquoi changer ?
Agilité vue par l’équipe
Comment initier le changement ?
De Scrum à ScrumBan
Quelles sont les adaptations apportées ?
Bilan
Nos difficultés, nos réussites...

31. Contexte
Projet
Contexte projet
Équipe
Configuration de l’équipe
Cascade
Pourquoi changer ?

32. Projet
Extranet d’une grande entreprise
En place depuis 2003
Fonctionnel complexe
Données confidentielles
Utilisé à l’échelle internationale
Point de communication (clients/internes)
Victime de son succès

33. Équipe
8 personnes
Équipe polyvalente
Hiérarchie non impliquée
Organisation historique
Interne/Prestataires

34. Cascade
Au bout de 10 ans …
Manque de réflexion
Dette technique
Manque de communication
Équipe frustrée, sous pression
Échec mal vécu
Des retards de livraisons
Turn over non maîtrisé
CP surbookée et tendue

35. Agilité vue par l’équipe
Agile
Les valeurs
Scrum
Les piliers et les pratiques
Kanban
Les principes et les pratiques

36. Agile
Rétrospective
Mobiliser l’équipe
Communication saine
Amélioration continue
Produit
ÉQUIPE
PRODUIT
COLLABORATION
ADAPTATION

37. Scrum
Pratiques :
Sprint planning
Sprint
Stand Up
Sprint review
Sprint retrospective
DOD, Scope, etc…
Trop stricte !
TRANSPARENCE
INSPECTION
ADAPTATION

38. Kanban
Pratiques :
Visualiser les flux
Limiter WIP
Gérer le débit
Expliciter le processus
Boucles de rétroaction
Améliorer la collaboration
Évoluer expérimentalement
Trop souple !
TRAVAIL EN COURS
CHANGEMENT
RESPECTER
LEADERSHIP

39. De Scrum à ScrumBan
Sprint planning
Objectif, mise en place, effet
Sprint
Stand up
Sprint review
Retrospective

40. Sprint planning 1/3
L’équipe connaît
sa capacité et le but à atteindre

41. Sprint planning 2/3
Tous les mercredis - Durée : 30 minutes - animée à tour de rôle
Préparation :
Renseignement du temps hors développement
Déroulement :
PO présente les fonctionnalités
Mise à jour des indicateurs de complexités
Chiffrage collectif en jour homme idéal
L’équipe ajoute une à une les “issues” au Sprint
Lancement du sprint

42. Sprint planning 3/3
Réussites :
Meilleure visibilité et communication
Mise en place de tâches d’analyse
Mise en place de pair programming
Maîtrise des risques et des complexités
Difficultés :
Problème du chiffrage en jour homme
Débordements maîtrisés par le maître du temps

43. De Scrum à ScrumBan
Sprint planning
Sprint
Objectif, mise en place, effet
Stand up
Sprint review
Retrospective

44. Sprint 1/3
L’équipe s’auto-organise
car elle sait ce qu’elle fait
et pourquoi elle le fait !

45. Sprint 2/3
KANBAN
Expliciter le processus en place
Issues
attribuées
DEV
IN PROGRESS
Cycle de recette croisée
TO BE
VALIDATED
VALIDATION
OPEN BLOCKED
DONE
IN PROGRESS REOPENED

46. Sprint 2/3
KANBAN
Gérer les flux
Issues
attribuées
DEV
IN PROGRESS
Cycle de recette croisée
TO BE
VALIDATED
VALIDATION
OPEN BLOCKED
DONE
IN PROGRESS REOPENED Issues
non
attribuées
Issues
non attribuées
(sauf si
reopened)
Issues
attribuées

47. Sprint 2/3
KANBAN
Commencer par ce que vous faîtes maintenant
Issues
attribuées
DEV
IN PROGRESS
Cycle de recette croisée
TO BE
VALIDATED
VALIDATION
OPEN BLOCKED
DONE
IN PROGRESS REOPENED Issues
non
attribuées
Issues
non attribuées
(sauf si
reopened)
Issues
attribuées
+
- +
PRIORITY
PRIORITY

48. Sprint 2/3
KANBAN
Gérer les changements de périmètre
Issues
attribuées
DEV
IN PROGRESS
Limit WIP
Cycle de recette croisée
TO BE
VALIDATED
VALIDATION
OPEN BLOCKED
DONE
IN PROGRESS REOPENED Issues
non
attribuées
Issues
non attribuées
(sauf si
reopened)
Issues
attribuées
+
- +
PRIORITY
PRIORITY
Versions Mineures
Version Majeures

49. Sprint 3/3
Réussites :
L’équipe est devenue auto-organisée
La CP moins surbookée et donc moins tendue
Meilleure visibilité des flux
Émergence d’une dynamique d’équipe
Difficultés :
Goulots d’étranglements résiduels

50. De Scrum à ScrumBan
Sprint planning
Sprint
Stand up
Objectif, mise en place, effet
Sprint review
Retrospective

51. Stand up 1/3
Synchronisation de l'équipe et évaluation de l’
avancement vers le but de l’itération

52. Stand up 2/3
Point de vu émergeant :
S'intéresser au travail de l’équipe doit être normal donc
pourquoi en faire une cérémonie ?
Pas de daily standup
Transparence :
Tous les jours, chacun renseigne son temps passé
Board % d’avancement des “issues”

53. Stand up 3/3
Réussites :
Transparence quant à l’avancement des tâches
Communication informelle mais efficace
Entraide et réduction des dépassements
Difficultés :
Manque d'intérêt de la part de certains membres

54. De Scrum à ScrumBan
Sprint planning
Sprint
Stand up
Sprint review
Objectif, mise en place, effet
Retrospective

55. Sprint review 1/3
Collecter le feedback des parties prenantes !

56. Sprint review 2/3
Échec
Que faire lorsque la DEMO se transforme en règlement
de compte entre les parties prenantes et les POs ?
Pas de DEMO
Protéger l’équipe
Definition Of Done
Cycle de recette croisée intégrée dans le sprint

57. Sprint review 3/3
Réussites :
Une équipe moins exposée donc moins stressée
Difficultés :
Une bonne implication mais la perte de l’engagement...

58. De Scrum à ScrumBan
Sprint planning
Sprint
Stand up
Sprint review
Retrospective
Objectif, mise en place, effet

59. Retrospective 1/3
Amélioration continue
via la mise en place de boucles de rétroaction

60. Retrospective 2/3
Pour nous la rétrospective
se déroulait en deux temps

61. Retrospective 2/3
Petites boucles de rétroaction
Après chaque sprint avant le sprint planning
Durée : 30 minutes
Déroulement :
● Vérification du temps renseigné par l’équipe
● Point sur la vélocité de l’équipe
● Revue de toutes les “issues”
● Revue des causes de dépassement
● Mise en place d’actions concrètes

62. Retrospective 2/3
Petites boucles de rétroaction
Réussites :
Refactoring ciblé grâce aux causes de dépassement
Identification des points forts et faibles de chacun
Facilitation du transfert de compétences
Meilleure maîtrise des risques
Difficultés :
Débordements => Timebox 5min/issue

63. Retrospective 2/3
Grandes boucles de rétroaction
Tous les 10 sprints
Durée : 2 heures
Préparation individuelle :
● Des indicateurs quantitatifs, qualitatifs, collaboratifs,
temporels et de vélocité
Déroulement collectif :
● Soumission et vote des thèmes soumis
● Revue de chacun des thèmes
● Définition de plans d’actions

64. Retrospective 2/3
Grandes boucles de rétroaction
Réussites :
Matière à réflexion via des indicateurs factuels
Meilleure capacité à prendre du recul
Meilleure maîtrise des sujets dont on ignore les métriques
Difficultés :
Trop d’indicateurs pour être pleinement exploités...

65. Retrospective 3/3
Petites boucles de rétroaction
Augmenter l’efficacité de l’équipe
Grandes boucles de rétroaction
Éviter l'essoufflement de l’équipe

66. Bilan
ScrumBan
Du recueil du besoin à la mise en production
Nos difficultés
Le principal danger de l’agilité
Nos réussites
Les bienfaits de l’agilité
A retenir
S’il n’y avait qu’une chose à retenir que serait-elle?

67. ScrumBan

68. Nos difficultés
Au niveau des individus :
L’agilité met l’humain en avant ce qui peut exacerber les
conflits existants entre les individus !
Les valeurs agiles :
L’équipe doit puiser ses forces dans les valeurs agiles
afin de mettre de coté les conflits en faveur de l’équipe et
du produit !

69. Nos réussites
Au niveau de l’équipe
● Meilleure intégration des nouveaux
● Veille et refonte technique
● Transfert de compétences
Au niveau du produit
● Livraisons plus fréquentes
● Meilleure vision du fonctionnel

70. A retenir
Adopter les valeurs agiles !
Adapter continuellement vos pratiques à votre contexte !

71. Questions
?