Les clés de la performance : combiner confiance et contrôle
Je rencontre souvent des managers qui opposent ces deux principes : moins on a confiance en ses partenaires (collaborateurs, subalternes, sous-traitants), plus il est nécessaire de fixer des moyens de contrôle de leur travail.
Je veux les deux : la confiance, parce qu’en équipe c’est une clé de la performance, et le contrôle, parce que c’est une clé de la qualité.
Une équipe agile que j’accompagne vient de prouver qu’on peut conjuguer les deux.
En agile, on dit : le responsable produit doit valider chaque fonctionnalité après une recette. Seulement, dans cette team, la responsable produit est trop occupée par d’autres tâches. C’est un projet top visibilité, et elle est accaparée par le public relation.
Les développeurs ont donc établi une convention : chaque fonctionnalité subit une vérification croisée. L’un développe, un autre recette.
Après une revue rapide (la démonstration de fin d’itération), la responsable produit valide finalement la fonctionnalité, mais sans entrer dans les détails : elle s’en remet totalement à l’équipe. Belle confiance, hein ?
Et les résultats sont là : très peu de régressions, des fonctionnalités toujours nickel au moment d’être livrées, très peu de bugs découverts par la suite. La question n’était donc pas “qui contrôle ?” mais “est-ce contrôlé ?”.
En se faisant confiance et en faisant tourner les rôles, l’équipe impose au logiciel un contrôle bien plus intense que ce qu’une personne seule aurait pu faire.
Conclusion : plus de confiance permet plus de contrôle, et donc plus de qualité.
… D’ailleurs, ça me rappelle ce problème des joueurs qui trichent au dés en jeux de rôles… (à suivre)
[EDIT]
Confiance et contrôle appliqués aux jeux de rôles sur mon blog perso
Peut-on faire un break pour stabiliser le logiciel ?
“On a besoin d’une semaine pour stabiliser ce qu’on a déjà développé, on peut interrompre les itérations et reprendre dans une semaine ?”
Et voilà : l’équipe a laissé trainer quelques bugs graphiques, a ignoré des dysfonctionnements en intégration pour valider quand même. En un mot comme en cent : ils ont voulu avancer vite et fait des compromis avec la qualité. Aujourd’hui, revenir à une situation “propre” demanderait du temps, un temps précieux alors que tenir les prochains jalons est déjà tendu.
Ca arrive à tout le monde, aussi bien intentionné et agiliste soit-il.
Parvenu à ce stade, l’équipe m’a demandé l’autre jour : “est-ce qu’on pourrait faire une pause dans les itérations pour finaliser les fonctionnalités où il manquait deux-trois petzouilles… corriger quelques bugs… stabiliser le logiciel… enfin, tu vois, quoi, rattraper le coup ? Mais juste une semaine, après on reprend les itérations, promis !”
Ne touchez pas au rythme des itérations
Pas de break.
Les itérations fixes permettent de mesurer votre vitesse de développement (la vélocité), c’est un indicateur de base pour piloter le projet (=quand est-ce qu’on peut livrer quoi). Si on met en pause les itérations, on arrête le chrono pour fignoler : on triche avec l’indicateur ; et dès lors l’indicateur ne sert plus à rien.
La vitesse de développement n’est pas pas la vitesse où on crache du code, mais celle que l’équipe prend pour livrer des fonctionnalités finies, fignolées, impecs, nickel, prêtes pour la production. Pour reprendre l’ellipse, des fonctionnalités “stabilisées”.
Si l’équipe stabilise le soft alors qu’elle continue à mesurer sa vélocité, elle constatera une avance moins rapide, mais ce sera sa vitesse réelle : stabilisation comprise, le projet est plus lent qu’on ose le dire. Evidemment, cela demande du courage, mais c’est le rôle d’un indicateur : montrer tout haut ce qu’on a pas le courage de se dire.
Résumé philosophique : l’itération c’est la vie, et la vie ne vous attend pas.
Quand faire les rituels d’itération
Lorsque les équipes de développement démarrent en Scrum, une question arrive automatiquement : quand planifier les rituels ?
Pour les rituels d’itération, 3 dates émergent : le mardi matin, mercredi matin, ou jeudi matin.
Le Lundi, l’équipe a besoin de se remettre dans le bain, de reprendre le rythme après le week-end. Elle n’est pas prête pour une éventuelle démonstration du produit, et n’a plus en tête l’itération écoulée pour mener une rétrospective efficace. J’ajouterai même qu’elle n’est plus dans l’ambiance, et que les problèmes sont souvent occultés.
Le vendredi parait un bon moment, mais c’est un faux ami : les belles idées de la rétrospective font plouf, les plans d’action et même le planning sont un peu oubliés quand on attaque l’itération le Lundi.
Donc : mardi, mercredi, ou jeudi, c’est top. On a le temps de préparer sa démo, la rétrospective est menée “à chaud”, et les action d’amélioration seront menées dans la foulée.
Les faire le matin, c’est juste une question d’énergie, d’éviter la digestion ; essayez et vous verrez.
Comment établir un contact mondain
Dans un événement mondain, on est parfois gêné lorsqu’on cherche à aborder quelqu’un qu’on ne connait pas.
C’était mon cas jusqu’à cette soirée il y a 4 ans où une aide inattendue s’est présentée, alors que j’étais jeune représentant des Rotaract d’Île de France à une soirée du Rotary. Je ne connaissais pratiquement personne, et je devais me faire connaitre afin de positionner le réseau que je représentais.
Pendant la première demi-heure, j’étais coincé dans un coin, un peu paumé, participant timidement à des conversations avec des inconnus. Finalement, un ami rotarien m’a pris par le bras et m’a fait faire le tour de la salle : «tiens, on va te présenter untel, et machin, et machin». Au bout d’une heure, tout le monde me connaissait. Les contacts que j’ai noués ce soir-là m’ont servi de base pour mon action l’année qui a suivi ; je remercie mille-fois ce rotarien.
Aujourd’hui, pour toute prise de contact mondain avec une «cible», je réutilise le même truc : je cherche une connaissance commune et je lui demande de me présenter.
Parfois j’ai l’occasion de rendre à d’autres ce service : aux ScrumDays, j’ai trouvé un gars perdu, attendant qu’une de mes connaissances soit disponible pour lui parler. Je l’ai pris par le bras et je les ai présentés.
Je sais pas si ça fait partie de l’étiquette de jouer les entremetteurs, c’est pourtant le meilleur service qu’on puisse rendre à des nouveaux dans un réseau.
Doit-on résoudre tous les problèmes abordés en rétrospective ?
A la fin d’une itération (une semaine de travail, souvent) une équipe développant en méthode agile se réunit et passe en revue la semaine pour voir comment faire mieux la semaine suivante : on dit qu’elle fait une rétrospective.
Ces rétrospectives sont courtes (1H) et voient souvent des points rester en suspense, des problèmes sans plan d’action. Les équipes demandent alors si elles peuvent résoudre ces problèmes durant la semaine.
La réponse est : oui, bien sûr !
Finalement, la question est plutôt : si on peut se retrouver pour résoudre des problèmes n’importe quand pendant la semaine, pourquoi le faire en rétrospective ?
La rétrospective permet de créer un espace de confiance et de détecter les problèmes de fond. Le rituel, le lieu dédié, incitent les participants à aborder avec plus de profondeur, plus de transparence leurs impression sur la semaine. Souvent, ce temps et cet espace sont nécessaires pour faire sortir les problèmes autres que techniques : les incompréhensions, les tensions, les divergences.
Certaines équipes utilisent la rétrospective simplement pour détecter les problèmes clés, et programmer des points de résolution au cours de l’itération.
Principe du blog
L’auteur
Je m’appelle Guillaume. Je suis coach agile : j’apprends à des équipes ou des organisations développer des logiciels en adoptant des pratiques agile (issues de Scrum, XP, Lean software, etc). Je les forme, je les accompagne au quotidien, puis un peu moins, puis elles n’ont plus besoin de moi ; ensuite, c’est moi qui les observe pour apprendre.
L’agile après l’école
Chaque jour ou presque, on me pose une question qui dépasse la pratique “scolaire” de l’agile (celle qu’on apprend en 2 jours de formation). Les détails méconnus, mal compris, les subtilités dues au contexte, et aussi les pratiques avancées : c’est ce que j’appelle l’agile après l’école.
Le blog
Avec l’expérience, j’ai accumulé des réponses toutes prêtes à un certain nombre de ces questions, mais souvent ce n’est pas le cas. Je réfléchis avec les équipes, je me tourne vers mes confrères agilistes, je cherche dans mes expériences passées, je me creuse la tête ; bref je tâche de fabriquer une réponse. C’est autant un apprentissage pour moi que pour mes clients, c’est là que ça devient passionnant.
Le principe de ce blog, c’est de partager ces apprentissages.