Indicateurs quantitatifs

Considérons quelques indicateurs (parmi tant d’autres) visant à quantifier le fonctionnement d’un projet agile

• nombre de story points (de user story) réalisés dans une période (une itération, une release) par jour.homme, pour intégrer les variations de capacité de production (vacances, disponibilités partielles). Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Voici le backlog, voici la colonne story points, voici le total, je divise par tel ratio, voici le nombre d’itérations, voici la date d’atterrissage, vous pouvez décaler la release de x mois si on ne change rien.
• nombre d’heures idéales (de tâches) réalisées dans une période (une journée, une itération) par jour.homme. Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Pas évident d’expliquer qu’en une journée on fait 5,8 h idéales et pas 7 ou 8, si ce n’est en le montrant
• % des story points prévus qui ont été effectivement livrés dans l’itération. Pour éviter de trop s’engager à chaque fois et conserver la confiance.
• % des story points prévus et livrés qui ont été finalement inclus dans la release finale, pour évaluer la quantité de changement du périmètre et la rationalité de la priorisation sur laquelle s’est appuyée la planification.
• % des story points des user stories qui ont été ajoutés en cours de release, pour évaluer la stabilité du périmètre. Ok pour accepter le changement, mais ca prend du temps.
• Somme de l’estimation en heures de correction idéales de bugs injectés par itération, pour évaluer la qualité du processus de devt, la surchauffe.
• Etc… (Je n’aborde pas ici l’efficacité directe des rituels, comme la durée du standup ou le temps entre le moment où une idée est évoquée en rétrospective et le moment où elle est prise en compte (ou abandonnée))

L’essence de ces indicateurs est toujours la même. On confronte le projet au réel (demandes du métier, développement et corrections de defects) pour en déduire a posteriori des indicateurs sur le fonctionnement du projet permettant, en s’appuyant sur cet historique des projections sur l’avenir (toutes proportions gardées, le cône d’incertitude se réduisant au fur et à mesure de l’avancement du projet) ou pour identifier des plans d’action (resensibiliser le product owner, améliorer la qualité, …).

Ne pas mesurer le temps passé par les uns et les autres mais bien les progrès effectués par l’équipe.

Inclure des correctifs de la capacité de production quand une personne est absente ou ne l’est pas.

Rester prudent en exploitant ces résultats, les indicateurs ne se stabilisent pas forcément dans le temps. Il faut les assortir d’hypothèses, et assortir les conclusions que l’on en tire de ces mêmes hypothèses.

Le but ultime : annoncer les mauvaises nouvelles dès qu’on les connait pour prendre les mesures qui s’imposent (réduire le périmètre, augmenter l’équipe (à utiliser avec modération), arrêter le projet). Ne pas faire l’économie de l’effort de communication, de préparation du discours (s’appuyer sur des faits et non des impressions). S’attendre à une résistance, un frein à l’action. Personne n’aime annoncer des mauvaises nouvelles ou demander une rallonge.

L’agilité, outil de communication

Peut-être que ce qui me plaît le plus dans l’agilité, c’est d’ouvrir enfin la boîte de pandore de ce que pense réellement l’équipe (développeurs, testeurs) et de mettre le management de projet devant ses responsabilités. On n’impose plus un planning ou une organisation du haut vers le bas (au moins en théorie).

Il y a en particulier la valeur agile du courage.

Courage de dire vers en haut (ou même à son client) : non, il vaut mieux faire comme ça, ou même, non, ça n’est pas faisable.

Courage de dire vers en haut : nous en sommes encore à la première itération, il est très prématuré de nous demander des dates. Attendons la fin de la 3ème pour avoir un début de visibilité sur notre vélocité.

La possibilité d’avoir ce courage vient de sa mise en avant comme valeur, mais aussi de l’accord explicite entre le management et l’équipe d’utiliser les méthodes agiles. On peut dire beaucoup de chose à un client qui adhère au discours agile, même si c’est pour de mauvaises raisons.

L’agile est un objet bien pratique. C’est un bel objet, bien marketé par les signataires du manifeste et leurs héritiers. C’est aussi un objet à géométrie variable, qui s’adapte au contexte.

Il faut du coup du courage au coach, puisqu’il y a des degrés de liberté, pour ne pas se laisser embarquer dans la direction qui convient le mieux au management ou dans celle qui convient le mieux à l’équipe. Il doit pousser gentiment tout le monde dans une bonne direction, où l’on se remet en question, où l’on confronte ses idées au monde réel. Il doit donc communiquer sur l’agilité, sans être non plus dans une orthodoxie trop fermée au spécificités du terrain.

Faire parler tout le monde, tous les corps de métier. Refuser de s’engager indument, mais tenir ses engagement. Savoir dire non. Savoir dire oui.

Ce n’est pas si nouveau que ça, mais c’est devenu plus facile.

PS: Ou bien est-ce juste une question de génération, les ex-développeurs étant maintenant aux manettes, et se souviennent-ils du temps où ils étaient dans la boue ?

La solitude du manager

Le management est un rôle qui va avec une grande solitude. Solitude devant la hiérarchie qui demande des résultats. Solitude devant les collaborateurs qui attendent de vous des réponses, des décisions, de l’efficacité.

Une solution consiste à chercher le contact de ses pairs. Si possible de même niveau mais dans des branches différentes de l’organigramme, sans relation opérationnelle avec soi, histoire d’éviter les conflits d’interet (difficile de négocier avec quelqu’un dont on a sollicité l’aide la veille). Le “supérieur” hiérarchique ne peut jouer ce rôle que partiellement, car il a aussi comme tâche l’évaluation. Passer son temps à poser des questions à quelqu’un sensé vous évaluer n’est pas forcément le mieux (ca dépend des cas, ceci dit)

De ces échanges, le jeune (ou moins jeune) manager pourra retirer des bonnes pratiques, des retours d’expérience, une aide à la réflexion sur un cas concret que l’on n’arrive pas à poser, mais aussi peut-être des éléments sur le fonctionnement de l’entreprise, ce qui est toujours bon à prendre (même si dans les potins il y a aussi parfois du faux). Peut-être aussi des éléments sur le consensus ambiant (par exemple : quelle rémunération donner, sujet parfois tabou pour la hiérarchie ? Les comparaisons en la matière sont toujours instructives)

Et puis le manager doit-il vraiment être seul ?

 ”Parce qu’une seule personne décide au final”. C’est faux : la plupart des décisions de fond sont à défendre et faire valider par l’étage au dessus. Et puis, surtout,  l’agilité montre que la meilleure décision est collégiale.

“Parce qu’une seule personne est objectivée sur le résultat du projet”. Ce n’est pas une nécessité. Un manager éclairé m’avait un jour proposé un variable sur le résultat de mon projet plus une somme à répartir entre les membres de l’équipe.

Peut-être que l’aspect du rôle le plus incarné est celui du sens. Donner du sens. Communiquer une image de l’équipe à l’exterieur. Communiquer une image de l’entreprise aux collaborateurs. Avoir une réponse.

 Il y a aussi le rôle d’annoncer les mauvaises nouvelles. Une équipe scrum, même démocratique, répugnera à prendre un collaborateur dans un coin pour lui dire de changer d’attitude. Il faut quelqu’un pour recadrer, même s’il vaudrait mieux que les membres de l’équipe les plus proches du fautif lui en touchent deux mots, en apparté (l’idéal étant la ‘stéréo’ : le chef + les potes)

Et puis j’apprécie mes entretiens de “performance”, il me faut un interlocuteur. Avoir quelqu’un avec qui se poser, faire un bilan, trouver des axes d’améliorations. Je ne sais pas ce qui se passe dans la tête de mon manager, alors. Je ne peux que l’imaginer en étant dans la situation inverse, à essayer de donner des pistes à mes collaborateurs pour qu’ils s’améliorent, en les secouant parfois, en ne cédant pas forcément à toutes leurs attentes, en essayant de trouver des solutions pour qu’ils poursuivent au mieux leur carrière chez “nous”.

C’est peut-être ce “nous” qui change tout. Un manager (dès le premier niveau dans l’organigramme) représente l’entreprise. Et l’entreprise souhaite avoir des collaborateurs autonomes. Donc ses représentants doivent l’être, et se débrouiller seul. Ou au moins, en avoir l’air, même si personne n’est complêtement dupe.

Innover dans une SSII

CMMI a pour vocation la capitalisation, l’homogénéisation des pratiques, afin que tous les projets fonctionnent pareil, et afin d’avoir le même niveau de pression sur chaque projet. C’est louable, mais cela me semble un peu limité en terme d’innovation : les chefs de projets appliquent les pratiques officielles, et ne vont pas tous chercher beaucoup plus loin. Les experts diront, à juste titre, que les règles CMMI sont configurables selon le contexte.

Inversement, j’ai récemment répondu à un twitt de @bcourtine qui demandait s’il fallait rentrer dans subversion les fichiers de conf de Eclipse, i.e. s’il fallait que les environnements de tous les membres de l’équipes soient identiques, s’il fallait uniformiser ces environnements de développement. Je pense que oui, je pense que l’équipe doit échanger sur les pratiques et se mettre d’accord (dans le cadre du projet précis qui lui est confié). Je pense aussi que c’est un pré-requis indispensable à la construction de scripts ou d’outils de productivité innovants, parfois propres à chaque projet. Il a très bien détaillé son point de vue sur son blog.

J’en reviens à mon délire sur le personnage de l’Oracle. Il faut que les membres de l’équipe, des équipes, puissent s’exprimer, apprendre, inventer, tester, construire. Pas seulement pour leur motivation, cela importe aussi pour leur éducation et donc leur valeur.  Il faut aussi qu’ils échangent, qu’ils confrontent, qu’ils partagent. Est-il vraiment indispensable de leur offrir de ce fait un ennemi commun, la direction de projet qui n’y connait rien ?

Peut-être cela a-t-il aussi à voir avec l’artisanat logiciel. L’artisant est un expert, mais aussi un designer et quelqu’un qui organise toute sa production pour concilier les pôles de son activité : produire de la valeur et de la qualité, tenir ses engagements de budget et délai, innover car le marché innove.

Croire que l’on peut appliquer pendant des années des pratiques vieilles de plus de trois ans et des socles techniques aussi agés me semble une douce illusion.

CMMI n’est pas incompatible avec l’innovation. Ce qui est incompatible c’est l’idée anti-agile que la nature des innovations ne peut venir que d’en haut. L’innovation vient des échanges et de la confrontation au terrain, ainsi que de la confrontation aux idées passées et présentes. Cela n’est pas possible si chacun bosse dans son coin. Cela n’est pas non plus possible si la direction n’alloue jamais de budget pour tester ou capitaliser un test reussi.

Agilité et 2.0

L’agilité et le web 2.0 ont certaines choses en commun.

Je pense en particulier au renversement des choses. C’est l’équipe qui prend la main sur certains aspects dévolus jusque là au chef de projet. Pour le web 2.0 c’est le visiteur du site (le client) qui alimente une partie du site (commentaires, …). Dans les 2 cas, il y a un courant issu de la base vers le haut.

Il y a par ailleurs une vision très pragmatique des choses, démocratique. On vote pour estimer une user story. On vote pour qualifier l’intérêt de tel ou tel produit.

Maintenant, les sites qui ont du 2.0 ne sont pas que cela. La publicité, le contenu éditorial ou marchand continuent d’exister, mais l’adéquation est plus grande.

De même, le projets agile ont un budget, des sponsors, des contraintes. C’est juste qu’ils se passent mieux, qu’ils atteignent mieux leurs objectifs.

Quand je parle d’agilité à des non informaticiens ils me regardent avec des yeux ronds : comment avez-vous pu imaginer procéder différement si longtemps ?

Matrix

Rassurez-vous je ne vais pas faire une n+1ème métaphore sur la base de la pillule bleue (ignorance) et de la pillule rouge (lucidité). Je voudrais évoquer un autre aspect de Matrix, le personnage de l’Oracle.

Elle fait partie du système, mais elle est là pour que les humains s’intègrent au système, pour qu’ils aient la sensation d’avoir leur mot à dire, d’être maîtres de leur destin, tout en revenant dans le giron du système à la fin.

Cet “empowerment” des humains me fait penser à l’agilité, et au rôle du chef de projet dans un contexte agile. Au final, il faut que les choses soient faîtes, que les contraintes soient respectées. Pourtant, les décisions doivent venir de l’équipe.

Cela vaut aussi pour le recrutement ou l’encadrement dans une SSII. Il faut que le collaborateur s’y retrouve, qu’il ait la sensation de progresser. Et pourtant il faut que les choses soient faîtes, que les contraintes soient respectées.

La beauté du personnage de l’Oracle est qu’elle croit sincèrement oeuvrer pour le bien commun, malgré ses contradictions. Et vous ?

Vieux con agile

Comme je l’ai dit tout récemment à un membre d’une équipe que je coache, au risque de passer pour un vieux con, “vous avez de la chance que l’agilité soit à la mode, j’aurais bien aimé qu’elle le soit quand j’étais développeur”. C’est vrai qu’il y aurait eu moins de choses à inventer et surtout moins de choses à essayer de vendre avec difficultés au management. Tant mieux pour les jeunes.

Planning

Paradoxalement, il ne faut pas trop se focaliser sur les dates quand on dresse un planning.

Identifier les tâches, les ressources, les contraintes d’affectation.

Estimer les tâches

Estimer les dépendances (strictes ou pas)

Une fois que c’est clair, la date se calcule toute seule.

Et ce n’est qu’alors que l’on doit la mettre en regard des contraintes de dates, et revoir l’ensemble si ca ne “rentre” pas, en priorisant à la baisse certaines tâches, en acceptant explicitement de prendre le risque d’en paralléliser d’autres, …

L’acte de  planifier en mode agile se fait en équipe, pour que chacun puisse contribuer : contrainte à laquelle on n’a pas pensé, tâche que l’on n’a pas explicitée, …

Ne pas se focaliser non plus sur la tête qu’il aura dans MS-Project, mais bien sur le découpage le plus adéquat, le plus proche du mode de fonctionnement réel.

Et puis, un de mes mentors m’a indiqué qu’il dressait son planning sous excel et n’utilisait MS-Project que pour le communiquer (en ressaisissant les éléments à un niveau de granularité faible).

Le temps qualitatif

Ca m’agace toujours quand j’entends un chef de projet dire à un développeur : pour la tache T23 on avait prévu 2j, tu es déjà à 3j il faut aller plus vite.

Pour moi, on ne peut pas dissocier le temps (3j) de ce à quoi il est consacré. Ca change tout de savoir que :

• pour cette tache on a du faire un refactoring de toute l’application
• pour cette tâche on a du changer de version de composant …

La vraie question c’est plutôt :

• fallait-il ou non faire ces tâches annexes ?
• quel niveau de qualité fallait-il se fixer ?
• Ces choses ont-elles été décidées officiellement ?

Ensuite, il faut rappeler un point : le problème n’est pas que le chef de projet avait prévu 2j, on peut aussi bien passer 4j.

Le problème c’est que l’on a vendu 2j (de budget) ou une date.

Sur la base de quoi ?

Avait-on fait une analyse profonde des caractéristiques des tâches, des tâches sous-jacentes ?

Dans CMMI on capitalise un modèle de charge à passer (en moyenne), mais il n’est pas toujours assez finement paramétré par le niveau d’exigence du client ou les spécificités du projet.

Dans les méthodes agiles, il y a la “definition of done”, mais elle est générale (pour qu’une tâche soit finie, il faut avoir mis à jour la javadoc, passé tous les tests, …) alors que les décisions à prendre sont “locales” : ai-je besoin du même niveau d’exigence ergonomique pour les écrans d’administration, …

Bref, il est surtout urgent se concerter, de faire valider par le décideur (chef de projet ou product owner).

Et s’il faut utiliser des statistiques, d’utiliser des statistiques portant sur le projet en cours (velocité), si tant est qu’il n’ait pas évolué dans la nature de ses tâches (architecture technique stabilisée, bugs suite à mise en production, …).

La révolte agile

Il s’agit bien d’une révolte d’une catégorie de la population contre son oppresseur.

Des développeurs contre les chefs de projet et les méthodologues qui prétendent leur dire comment faire ou comment penser ou comment s’organiser. De l’abolition de la hiérarchie au sein d’un projet, en mettant tout le monde sur le même plan. Du raz le bol des développeurs qui n’aiment pas rédiger de la documentation ou suivre un plan et une attribution des tâches.

Mais aussi des chefs de projets à leur tour contre les managers de Business Unit et les contrats au forfait.

Tout ceci a un côté très lutte de classes. La direction me semble bonne, mais il ne faudrait pas jeter le bébé avec l’eau du bain.

Meneur de jeu

Avant les méthodes agiles, les rôles étaient établis.

Il y avait le développeur, le team leader, l’architecte, le chef de projet…

Chacun s’occupait de sa paroisse. L’architecte de la qualité des devts. Le chef de projet des délais. Le team leader du moral des troupes. Etc…

Maintenant que l’équipe s’organise comme elle le souhaite, les choses sont plus fluctuantes.

Tant mieux.

A condition que les débats s’organisent tous seuls autour des vrais axes. Arbitrage entre qualité et budget. Arbitrage entre veille techno et impératifs de délai.  Entre impératif pour l’équipe et formation des uns et des autres. Etc…

Peut-être faut-il quand même toujours un meneur de jeu, qui vérifie que l’on continue à se poser les questions (sans y répondre).

Le meilleur meneur de jeu étant celui qui s’efface, une fois son travail de mise en situation fait, derrière les joueurs et leur interprétation, les laissant libres et créatifs…

Chef de projet ou d’équipe

Quelques aspects demandé à un chef de projet ou d’équipe :

• respecter ses engagements : budget (charge), délai, qualité, périmètre, dans l’ordre de priorité défini pour le projet
• défendre son périmètre et les intérêts de son équipe, quitte à demander un arbitrage à l’étage au dessus. Etre un premier filtre pour les sollicitations extérieures (comme un Scrum Master)
• gérer les risques (anticiper, prévenir, soigner)
• ne pas faire ce qu’on aurait pu éviter de faire
• faire les choses par ordre d’importance (imaginer que l’on puisse tout arrêter avant la fin)
• prendre les décisions en temps utile en s’appuyant sur des évaluations chiffrées (et obtenir au préalable ces évaluations, de manière stable et prédictive)
• éviter que son équipe ne soit en famine ou en surcharge. Idem pour les équipes dépendantes ou sources
• répartir les responsabilités de façon à ce que tout sujet ait au moins un et au plus un responsable (y compris la prise en compte des nouveaux sujets)
• donner de la visibilité à l’étage au dessus
• optimiser le fonctionnement de l’équipe, collecter les suggestions, être force de proposition
• lever le stylo, prendre du recul parfois pour établir une stratégie, pour comparer, ordonnancer
• communiquer avec l’exterieur, faire passer les messages, convaincre, négocier
• s’informer sur la situation, créer les canaux qui permettront cette information
• collecter un historique (qualitatif et quantitatif) pour pouvoir s’appuyer sur le passé pour prédire l’avenir, tant en terme de charge qu’en terme de liste des tâches
• anticiper les problèmes pour que les décisions puissent être prises à temps (on peut dépasser un peu le budget, si ca permet de tenir les dates, …)
• contrôler la couverture du besoin, l’exhaustivité des sujets traités