agilité, n’oublions pas les valeurs
DESCRIPTION
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 ?TRANSCRIPT
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 ?
Agilité, n’oublions pas les valeurs
[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 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
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))
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
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
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 ?
Le plan
1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. 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 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 !
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 !
Le plan
1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion
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...
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 !
Le plan
1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. 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 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
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é).
Le plan
1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. 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 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
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 !!
Le plan
1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. 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 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….
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 !
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….
Le plan
1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion
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é.
Questions
?
[REX] L’agilité au service de l’équipe et du projet
Sommaire
ContextePourquoi changer ?
Agilité vue par l’équipeComment initier le changement ?
De Scrum à ScrumBanQuelles sont les adaptations apportées ?
BilanNos difficultés, nos réussites...
Contexte
ProjetContexte projet
ÉquipeConfiguration de l’équipe
CascadePourquoi changer ?
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
É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 pression
Échec mal vécu
Des retards de livraisons
Turn over non maîtrisé
CP surbookée et tendue
Agilité vue par l’équipe
AgileLes valeurs
ScrumLes piliers et les pratiques
KanbanLes principes et les pratiques
Agile
Rétrospective
Mobiliser l’équipe
Communication saine
Amélioration continue
Produit
ÉQUIPE
PRODUIT
COLLABORATION
ADAPTATION
Scrum
Pratiques :Sprint planning
Sprint
Stand Up
Sprint review
Sprint retrospective
DOD, Scope, etc…
Trop stricte !
TRANSPARENCE
INSPECTION
ADAPTATION
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
De Scrum à ScrumBan
Sprint planningObjectif, 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 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
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
De Scrum à ScrumBan
Sprint planning
SprintObjectif, 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
DEVIN PROGRESS
TO BE VALIDATED
VALIDATION IN PROGRESS REOPENED DONEOPEN
Cycle de recette croisée
BLOCKED
Sprint 2/3
KANBAN
Gérer les flux
Issues attribuées
DEVIN PROGRESS
TO BE VALIDATED
VALIDATION IN PROGRESS REOPENED DONEOPEN
Cycle de recette croisée
BLOCKED
Issues non
attribuées
Issues non attribuées
(sauf sireopened)
Issues attribuées
Sprint 2/3
KANBAN
Commencer par ce que vous faîtes maintenant
Issues attribuées
DEVIN PROGRESS
TO BE VALIDATED
VALIDATION IN PROGRESS REOPENED DONEOPEN
Cycle de recette croisée
BLOCKED
Issues non
attribuées
Issues non attribuées
(sauf sireopened)
Issues attribuées
- +
+
PRIORITY
PRIO
RIT
Y
Sprint 2/3
KANBAN
Gérer les changements de périmètre
Issues attribuées
DEVIN PROGRESS
TO BE VALIDATED
VALIDATION IN PROGRESS REOPENED DONEOPEN
Cycle de recette croisée
BLOCKED
Issues non
attribuées
Issues non attribuées
(sauf sireopened)
Issues attribuées
- +
+
PRIORITY
PRIO
RIT
Y
Versions Mineures
Version Majeures
Limit WIP
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
De Scrum à ScrumBan
Sprint planning
Sprint
Stand upObjectif, 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érémonie ?
Pas de daily standup
Transparence :
Tous les jours, chacun renseigne son temps passé
Board % d’avancement des “issues”
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
De Scrum à ScrumBan
Sprint planning
Sprint
Stand up
Sprint reviewObjectif, 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 les POs ?
Pas de DEMO
Protéger l’équipe
Definition Of Done
Cycle de recette croisée intégrée dans le sprint
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...
De Scrum à ScrumBan
Sprint planning
Sprint
Stand up
Sprint review
RetrospectiveObjectif, 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étroactionAprè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
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
Retrospective 2/3
Grandes boucles de rétroactionTous 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
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...
Retrospective 3/3
Petites boucles de rétroactionAugmenter l’efficacité de l’équipe
Grandes boucles de rétroactionÉviter l'essoufflement de l’équipe
Bilan
ScrumBanDu recueil du besoin à la mise en production
Nos difficultésLe principal danger de l’agilité
Nos réussitesLes bienfaits de l’agilité
A retenirS’il n’y avait qu’une chose à retenir que serait-elle?
ScrumBan
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 !
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
A retenir
Adopter les valeurs agiles !
Adapter continuellement vos pratiques à votre contexte !
Questions
?