Agilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeurs 
Deux expériences client contradictoires : 
● Application quasi stricte des cérémoniel...
[REX] 
L’agilité au détriment de l’équipe et du 
projet
Le contexte du projet 
● Intranet d’une grande entreprise 
● 120 000 utilisateurs possibles, 2000 
simultanés 
● En place ...
Coté technique 
● Portail Liferay très customisé 
● Important code legacy 
● Equipe permanente de 3 à 8 développeurs 
sur ...
Agilité 
● Mise en place depuis le début 
● Tous les rôles scrum présents : scrum 
master, product owner, développeurs 
● ...
Et pourtant ... 
● Une équipe frustrée et sous pression 
● Un scrum master démotivé 
● Un turn over important 
● Des retar...
Comment en arrive-t-on là ? 
Les rituels sont importants pour structurer l’ 
équipe et son fonctionnement! 
Mais que se pa...
Le plan 
1. Le Sprint 
2. Le Stand Up 
3. Le Sprint Planning 
4. La Sprint Review 
5. La rétrospective 
6. Conclusion
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 ...
Le sprint 
● La liste d'items est sujette à négociations entre le PO et l'équipe de 
développement. 
L’équipe de développe...
Le plan 
1. Le Sprint 
2. Le Stand Up 
3. Le Sprint Planning 
4. La Sprint Review 
5. La rétrospective 
6. Conclusion
Le stand up 
● Synchronisation de l’équipe 
Les interventions lors du stand up tiennent plus de l’interrogation orale sur ...
Le stand up 
● Collecte d’informations nécessaires à l’auto-organisation 
● Inspection et adaptation 
En cas de problème, ...
Le plan 
1. Le Sprint 
2. Le Stand Up 
3. Le Sprint Planning 
4. La Sprint Review 
5. La rétrospective 
6. Conclusion
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 ...
Le sprint planning 
● L’équipe ne dispose pas du dernier incrément ni de la capacité de 
production du prochain sprint… 
●...
Le plan 
1. Le Sprint 
2. Le Stand Up 
3. Le Sprint Planning 
4. La Sprint Review 
5. La rétrospective 
6. Conclusion
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...
La sprint review 
L’équipe fait ensuite le point sur l’avancement du projet avec toutes les parties 
prenantes, et ajuste ...
Le plan 
1. Le Sprint 
2. Le Stand Up 
3. Le Sprint Planning 
4. La Sprint Review 
5. La rétrospective 
6. Conclusion
La rétrospective 
Au début systématique à la fin de chaque sprint, elle a été abandonnée petit à 
petit sur décision du sc...
La rétrospective 
L’inspection de l’itération précédente pour déterminer les éléments à garder, 
ceux à améliorer. 
● Le S...
La rétrospective 
● Les plans d’actions proposés sont ignorés quand ils concernent la 
hiérarchie de la cellule ou les rel...
Le plan 
1. Le Sprint 
2. Le Stand Up 
3. Le Sprint Planning 
4. La Sprint Review 
5. La rétrospective 
6. Conclusion
Conclusion 
Les valeurs de transparence, d’inspection et d’adaptation 
doivent rester au centre des préoccupations de l’éq...
Questions 
?
[REX] 
L’agilité au service de l’équipe et du projet
Sommaire 
Contexte 
Pourquoi changer ? 
Agilité vue par l’équipe 
Comment initier le changement ? 
De Scrum à ScrumBan 
Qu...
Contexte 
Projet 
Contexte projet 
Équipe 
Configuration de l’équipe 
Cascade 
Pourquoi changer ?
Projet 
Extranet d’une grande entreprise 
En place depuis 2003 
Fonctionnel complexe 
Données confidentielles 
Utilisé à l...
Équipe 
8 personnes 
Équipe polyvalente 
Hiérarchie non impliquée 
Organisation historique 
Interne/Prestataires
Cascade 
Au bout de 10 ans … 
Manque de réflexion 
Dette technique 
Manque de communication 
Équipe frustrée, sous pressio...
Agilité vue par l’équipe 
Agile 
Les valeurs 
Scrum 
Les piliers et les pratiques 
Kanban 
Les principes et les pratiques
Agile 
Rétrospective 
Mobiliser l’équipe 
Communication saine 
Amélioration continue 
Produit 
ÉQUIPE 
PRODUIT 
COLLABORAT...
Scrum 
Pratiques : 
Sprint planning 
Sprint 
Stand Up 
Sprint review 
Sprint retrospective 
DOD, Scope, etc… 
Trop stricte...
Kanban 
Pratiques : 
Visualiser les flux 
Limiter WIP 
Gérer le débit 
Expliciter le processus 
Boucles de rétroaction 
Am...
De Scrum à ScrumBan 
Sprint planning 
Objectif, mise en place, effet 
Sprint 
Stand up 
Sprint review 
Retrospective
Sprint planning 1/3 
L’équipe connaît 
sa capacité et le but à atteindre
Sprint planning 2/3 
Tous les mercredis - Durée : 30 minutes - animée à tour de rôle 
Préparation : 
Renseignement du temp...
Sprint planning 3/3 
Réussites : 
Meilleure visibilité et communication 
Mise en place de tâches d’analyse 
Mise en place ...
De Scrum à ScrumBan 
Sprint planning 
Sprint 
Objectif, mise en place, effet 
Stand up 
Sprint review 
Retrospective
Sprint 1/3 
L’équipe s’auto-organise 
car elle sait ce qu’elle fait 
et pourquoi elle le fait !
Sprint 2/3 
KANBAN 
Expliciter le processus en place 
Issues 
attribuées 
DEV 
IN PROGRESS 
Cycle de recette croisée 
TO B...
Sprint 2/3 
KANBAN 
Gérer les flux 
Issues 
attribuées 
DEV 
IN PROGRESS 
Cycle de recette croisée 
TO BE 
VALIDATED 
VALI...
Sprint 2/3 
KANBAN 
Commencer par ce que vous faîtes maintenant 
Issues 
attribuées 
DEV 
IN PROGRESS 
Cycle de recette cr...
Sprint 2/3 
KANBAN 
Gérer les changements de périmètre 
Issues 
attribuées 
DEV 
IN PROGRESS 
Limit WIP 
Cycle de recette ...
Sprint 3/3 
Réussites : 
L’équipe est devenue auto-organisée 
La CP moins surbookée et donc moins tendue 
Meilleure visibi...
De Scrum à ScrumBan 
Sprint planning 
Sprint 
Stand up 
Objectif, mise en place, effet 
Sprint review 
Retrospective
Stand up 1/3 
Synchronisation de l'équipe et évaluation de l’ 
avancement vers le but de l’itération
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é...
Stand up 3/3 
Réussites : 
Transparence quant à l’avancement des tâches 
Communication informelle mais efficace 
Entraide ...
De Scrum à ScrumBan 
Sprint planning 
Sprint 
Stand up 
Sprint review 
Objectif, mise en place, effet 
Retrospective
Sprint review 1/3 
Collecter le feedback des parties prenantes !
Sprint review 2/3 
Échec 
Que faire lorsque la DEMO se transforme en règlement 
de compte entre les parties prenantes et l...
Sprint review 3/3 
Réussites : 
Une équipe moins exposée donc moins stressée 
Difficultés : 
Une bonne implication mais la...
De Scrum à ScrumBan 
Sprint planning 
Sprint 
Stand up 
Sprint review 
Retrospective 
Objectif, mise en place, effet
Retrospective 1/3 
Amélioration continue 
via la mise en place de boucles de rétroaction
Retrospective 2/3 
Pour nous la rétrospective 
se déroulait en deux temps
Retrospective 2/3 
Petites boucles de rétroaction 
Après chaque sprint avant le sprint planning 
Durée : 30 minutes 
Dérou...
Retrospective 2/3 
Petites boucles de rétroaction 
Réussites : 
Refactoring ciblé grâce aux causes de dépassement 
Identif...
Retrospective 2/3 
Grandes boucles de rétroaction 
Tous les 10 sprints 
Durée : 2 heures 
Préparation individuelle : 
● De...
Retrospective 2/3 
Grandes boucles de rétroaction 
Réussites : 
Matière à réflexion via des indicateurs factuels 
Meilleur...
Retrospective 3/3 
Petites boucles de rétroaction 
Augmenter l’efficacité de l’équipe 
Grandes boucles de rétroaction 
Évi...
Bilan 
ScrumBan 
Du recueil du besoin à la mise en production 
Nos difficultés 
Le principal danger de l’agilité 
Nos réus...
ScrumBan
Nos difficultés 
Au niveau des individus : 
L’agilité met l’humain en avant ce qui peut exacerber les 
conflits existants ...
Nos réussites 
Au niveau de l’équipe 
● Meilleure intégration des nouveaux 
● Veille et refonte technique 
● Transfert de ...
A retenir 
Adopter les valeurs agiles ! 
Adapter continuellement vos pratiques à votre contexte !
Questions 
?
Agilité, n’oublions pas les valeurs
Prochain SlideShare
Chargement dans…5
×

Agilité, n’oublions pas les valeurs

3 802 vues

Publié le

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 ?

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 802
Sur SlideShare
0
Issues des intégrations
0
Intégrations
815
Actions
Partages
0
Téléchargements
154
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agilité, n’oublions pas les valeurs

  1. 1. Agilité, n’oublions pas les valeurs
  2. 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. 3. [REX] L’agilité au détriment de l’équipe et du projet
  4. 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. 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. 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
  7. 7. 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
  8. 8. 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 ?
  9. 9. Le plan 1. Le Sprint 2. Le Stand Up 3. Le Sprint Planning 4. La Sprint Review 5. La rétrospective 6. Conclusion
  10. 10. 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 !
  11. 11. 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 !
  12. 12. Le plan 1. Le Sprint 2. Le Stand Up 3. Le Sprint Planning 4. La Sprint Review 5. La rétrospective 6. Conclusion
  13. 13. 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...
  14. 14. 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 !
  15. 15. Le plan 1. Le Sprint 2. Le Stand Up 3. Le Sprint Planning 4. La Sprint Review 5. La rétrospective 6. Conclusion
  16. 16. 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
  17. 17. 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é).
  18. 18. Le plan 1. Le Sprint 2. Le Stand Up 3. Le Sprint Planning 4. La Sprint Review 5. La rétrospective 6. Conclusion
  19. 19. 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
  20. 20. 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 !!
  21. 21. Le plan 1. Le Sprint 2. Le Stand Up 3. Le Sprint Planning 4. La Sprint Review 5. La rétrospective 6. Conclusion
  22. 22. 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….
  23. 23. 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 !
  24. 24. 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….
  25. 25. Le plan 1. Le Sprint 2. Le Stand Up 3. Le Sprint Planning 4. La Sprint Review 5. La rétrospective 6. Conclusion
  26. 26. 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é.
  27. 27. Questions ?
  28. 28. [REX] L’agilité au service de l’équipe et du projet
  29. 29. 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...
  30. 30. Contexte Projet Contexte projet Équipe Configuration de l’équipe Cascade Pourquoi changer ?
  31. 31. 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
  32. 32. Équipe 8 personnes Équipe polyvalente Hiérarchie non impliquée Organisation historique Interne/Prestataires
  33. 33. 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
  34. 34. Agilité vue par l’équipe Agile Les valeurs Scrum Les piliers et les pratiques Kanban Les principes et les pratiques
  35. 35. Agile Rétrospective Mobiliser l’équipe Communication saine Amélioration continue Produit ÉQUIPE PRODUIT COLLABORATION ADAPTATION
  36. 36. Scrum Pratiques : Sprint planning Sprint Stand Up Sprint review Sprint retrospective DOD, Scope, etc… Trop stricte ! TRANSPARENCE INSPECTION ADAPTATION
  37. 37. 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
  38. 38. De Scrum à ScrumBan Sprint planning Objectif, mise en place, effet Sprint Stand up Sprint review Retrospective
  39. 39. Sprint planning 1/3 L’équipe connaît sa capacité et le but à atteindre
  40. 40. 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
  41. 41. 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
  42. 42. De Scrum à ScrumBan Sprint planning Sprint Objectif, mise en place, effet Stand up Sprint review Retrospective
  43. 43. Sprint 1/3 L’équipe s’auto-organise car elle sait ce qu’elle fait et pourquoi elle le fait !
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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
  49. 49. De Scrum à ScrumBan Sprint planning Sprint Stand up Objectif, mise en place, effet Sprint review Retrospective
  50. 50. Stand up 1/3 Synchronisation de l'équipe et évaluation de l’ avancement vers le but de l’itération
  51. 51. 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”
  52. 52. 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
  53. 53. De Scrum à ScrumBan Sprint planning Sprint Stand up Sprint review Objectif, mise en place, effet Retrospective
  54. 54. Sprint review 1/3 Collecter le feedback des parties prenantes !
  55. 55. 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
  56. 56. 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...
  57. 57. De Scrum à ScrumBan Sprint planning Sprint Stand up Sprint review Retrospective Objectif, mise en place, effet
  58. 58. Retrospective 1/3 Amélioration continue via la mise en place de boucles de rétroaction
  59. 59. Retrospective 2/3 Pour nous la rétrospective se déroulait en deux temps
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. 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...
  64. 64. 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
  65. 65. 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?
  66. 66. ScrumBan
  67. 67. 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 !
  68. 68. 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
  69. 69. A retenir Adopter les valeurs agiles ! Adapter continuellement vos pratiques à votre contexte !
  70. 70. Questions ?

×