Christophe Addinquy & David Gageot Valtech Technology Services
Agile Project Management février 06
Résumé Les projets agiles mettent l’accent sur l’interaction entre les personnes, l’initiative et la participation active des membres de l’équipe. En cela, l’agilité se démarque fortement des approches plus classiques, où le chef de projet dirige et vérifie le déroulement des tâches et la conformité de ce déroulement par rapport au plan établi. Dans ces nouvelles conditions, on peut même douter de la pertinence du rôle de chef de projet : ne s’estompe-t-il pas jusqu’à devenir insignifiant ? Il n’en est rien. Seulement, dans ce nouvel environnement, le chef de projet doit considérer sa mission d’un angle nouveau : il devient leader, voir facilitateur plutôt que directeur ; il favorise la collaboration au lieu d’affecter les tâches ; il lève les obstacles et s’interpose entre son équipe et les évènements perturbateurs. Finalement, le rôle du chef de projet, bien loin de s’effacer, devient plus complexe, car de contrôleur il devient un élément moteur du projet. Moteur, le chef de projet l’est doublement, car il est garant du rythme du projet et des progrès continu de l’équipe, mais il est également porteur de la vision du projet, point de mire de l’équipe. Complexe, cette nouvelle mission l’est sans aucun doute, car l’on quitte le terrain bien balisé des tâches clairement définies et séquencées pour une approche moins déterministe et plus adaptative. En assurant ce rôle de leader, le chef de projet agile n’oublie pas que les progrès sont réalisés non par lui-même mais par son équipe, et qu’en écartant de son chemin les servitudes perturbatrices, il décuple sa productivité.
1
Table des matières 1. DU GESTIONNAIRE AU LEADER ______________________________________________4 1.1 1.2 1.3
La gestion de projet classique : le chef de projet gestionnaire ............................................... 4 Ce qui ne va pas dans ce modèle........................................................................................... 6 La gestion de projet agile : le chef de projet leader ................................................................ 6
2. DONNER LE RYTHME AU PROJET _____________________________________________8 2.1
Le cycle de l’agilité .................................................................................................................. 8
2.1.1 2.1.2 2.1.3
2.2
Le rythme de l’itération............................................................................................................ 9
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5
2.3
Se préparer à faire ......................................................................................................................... 8 Faire ............................................................................................................................................... 8 Feedback ....................................................................................................................................... 9 Planifier l’itération........................................................................................................................... 9 Tirer les tâches au lieu de les assigner ......................................................................................... 9 Radiateurs d’information .............................................................................................................. 10 Anticiper l’intégration.................................................................................................................... 11 Reflexion et adaptation ................................................................................................................ 12
Le rythme journalier .............................................................................................................. 13
2.3.1 2.3.2 2.3.3
Meeting journalier ........................................................................................................................ 13 Ne pas laisser de fenêtres brisées .............................................................................................. 14 Accepter la responsabilité de tâches ........................................................................................... 14
3. PORTER LA VISION ______________________________________________________14 3.1 3.2 3.3 3.4
Dessiner un futur exaltant ..................................................................................................... 15 Partager les attentes ............................................................................................................. 15 Construire le jalonnement ..................................................................................................... 15 Favoriser les participations ................................................................................................... 15
4. CREER L’ENVIRONNEMENT PROPICE _________________________________________16 4.1 4.2 4.3 4.4
Droits et devoirs .................................................................................................................... 16 L’environnement de travail .................................................................................................... 16 La diffusion de l’information .................................................................................................. 18 La protection de l’équipe ....................................................................................................... 18
5. INSTILLER LA COLLABORATION _____________________________________________19 5.1 5.2
Promouvoir l’apprentissage................................................................................................... 19 Développer des communautés ............................................................................................. 19
6. PLANIFIER, FAIRE, APPRENDRE _____________________________________________19
2
Liste des Figures Figure 1 :
Le classique diagramme de Gantt................................................................................... 5
Figure 2 :
Illustration des itĂŠrations.................................................................................................. 7
Figure 3 :
Le radiateur d'information.............................................................................................. 10
Figure 4 :
Burn down chart ............................................................................................................ 11
Figure 5 :
L'environnement de travail typique................................................................................ 17
3
1. Du gestionnaire au leader Quelle que soit la nature du processus mis en œuvre, le chef de projet est toujours l’un des éléments clés de son bon déroulement, et ce même si des dénominations diverses sont employées pour nommer son rôle : team leader, coach, directeur de projet, etc. Mais ce n’est pas tant le nom qui importe, que les tâches et responsabilités qui lui incombent. Celles-ci diffèrent de façon importante, que l’on se situe dans un processus classique ou dans un processus agile. Nous allons d’abord évoquer le premier cas, puis en identifier les faiblesses avant d’introduire le cas du chef de projet « agile ».
1.1 La gestion de projet classique : le chef de projet gestionnaire « La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch
Les processus classiques s’articulent autour des points suivants : • L’établissement d’un plan. • La mise en œuvre de ce plan. • Le contrôle de la bonne exécution du plan. • La mise en œuvre, si des écarts sont constatés, de mesures correctrices afin de recoller au plan. Cette approche nécessite d’établir en amont du projet une planification rigoureuse, sinon détaillée, des tâches à accomplir et des lots à réaliser. La finalisation des jalons intermédiaire se concrétise souvent par la réalisation de livrables dans un état d’avancement clairement défini. Les tâches sont définies et affectées afin d’occuper au mieux de leurs compétences et de leur temps les membres de l’équipe. La planification s’appuie le plus souvent sur une évaluation des charges réalisée grâce à des méthodologies établies telles que les points de fonction ou COCOMO 2.
4
Figure 1 : Le classique diagramme de Gantt
Le plan ainsi défini est mis en œuvre en affectant les tâches définies aux membres de l’équipe. Afin d’anticiper au mieux tout écart par rapport au plan, une gestion rigoureuse des risques (associée à un plan d’action adapté) traite les tâches dont l’exécution ou les résultats sont les moins prédictifs. Le chef de projet suit ainsi continuellement l’avancement des travaux, traitant les imprévus de façon qu’ils n’affectent pas (ou de manière minimale) le plan établi, et agissant de façon adaptée envers les membres de l’équipe en retard sur le planning ou délivrant des lots dont la qualité est inférieur aux critères déterminés. Ce modèle, que l’on pourrait appeler modèle prédictif, ne semble pas receler de failles. En fait, il a même donné des résultats éprouvés dans de nombreux domaines où il donne pleine satisfaction et où il continue d’être utilisé à juste titre. Dans le domaine logiciel, cette réussite est moins flagrante. Ce manque de réussite est souvent attribué à un manque d’expérience ou de compétence du chef de projet ou de l’équipe. On invoque aussi plus largement la jeunesse du domaine de l’ingénierie logicielle dont le demi-siècle d’existence ne saurait se mesurer aux millénaires d’expérience dont peut se prévaloir le BTP, par exemple. Mais on est également en droit de se poser les questions suivantes : • L’approche prédictive du BTP est-elle adaptée au monde du logiciel ? • Si certains aspects de ce processus échouent de façon récurrente, n’est-ce pas parce que ceux-ci ne sont pas abordés correctement ? • Définir le rôle du chef de projet et le cantonner dans une attitude réactive est-elle la bonne approche ? Qu’en est-il des membres de l’équipe de développement ?
5
1.2 Ce qui ne va pas dans ce modèle « Aucun plan ne survit au contact de l’ennemi » Helmuth Graf von Moltke
L’approche classique semble bien adaptée aux domaines de nature essentiellement prédictive, mais hélas la construction logicielle comporte une part d’inconnue et de découverte importante. C’est en fait la nature même de la plupart des projets informatiques de créer de nouvelles solutions et de couvrir de nouveaux besoins, sans cela, la très grande majorité des projets ne seraient pas lancés. Fondamentalement, la gestion d’un projet en stricte conformité avec un plan ignore la part d’incertitude liée à cette facette exploratoire. Ne pouvant occulter complètement cette part d’inconnu, les projets classiques gèrent celle-ci comme un « risque », comme une part d’inconnue qu’il faut transformer en chose connue et intégrer dans le plan pré-établi. Planifier par tâches, c’est adopter une approche tayloriste du développement logiciel. La première conséquence de cette approche est la déresponsabilisation : les membres de l’équipe acquièrent le sentiment de n’être qu’un engrenage de la machine. Dans un tel état d’esprit, il leur importe plus d’échapper aux reproches en accomplissant les tâches qui leur sont désignées que de contribuer à la réussite globale du projet. On ne peut mobiliser les énergies sans engagement, on ne peut obtenir cet engagement sans participation. La dernière pierre d’achoppement, est que les plannings deviennent faux ! La réalité diffère du plan comme le terrain diffère de la carte. Les plans sont utiles pour avancer dans la bonne direction, mais quand des écarts apparaissent, il est préférable d’adapter le plan. Tenter de recoller au plan quand celui-ci n’est plus pertinent, n’aidera jamais à faire ressembler la réalité au plan, la réalité finit par nous rattraper.
1.3 La gestion de projet agile : le chef de projet leader « To boldly go where no one has gone before » James T. Kirk, Star Trek
Les méthodes agiles ont fait le choix d’axer le déroulement du projet, non pas sur le respect d’un processus ni sur la conformité par rapport à un plan, mais sur la finalité. Cela est fort bien résumé par la charte de l’agile alliance1 : •
Priorité aux individus et à leurs interactions, plutôt qu’aux processus et aux outils.
•
Priorité à la livraison d’un système opérationnel, plutôt qu’à celle d’une documentation exhaustive.
•
Priorité à la collaboration avec le client, plutôt qu’à une négociation contractuelle.
•
Priorité à la réactivité par rapport au changement, plutôt qu’à la conformité par rapport au plan.
Ainsi, le chef de projet agile doit-il changer de perspective : il guide l’équipe vers l’objectif final, il met en avant « ce qui doit être fait » afin d’atteindre cet objectif, il donne une perspective sur les contributions individuelles et fonctionnelles par rapport au produit fini. Cette nouvelle perspective
1
Voir sur le site : http://www.agilealliance.org ;
6
n’est pas très confortable : elle requiert une part importante d’improvisation, en contraste flagrant avec le rôle plus clérical du manager-gestionnaire. Pourtant cette approche lève la plupart des objections que nous venons de mettre en lumière. L’influence principale du leader est de guider, d’influencer le comportement de chacun des membres de l’équipe sous l’angle de la contribution et de la participation au projet en tant qu’individus, et sous l’angle de l’accomplissement en tant qu’équipe. Toutefois, chaque accomplissement qui nous rapproche du but n’est pas une progression en ligne droite, comme voudrait nous le faire croire l’approche guidée par le plan. L’équipe apprend en découvrant et l’utilisateur comprend et affine son besoin au fur et à mesure des livraisons. Ainsi chaque progression, chaque itération rapproche le projet de son aboutissement, non par la réalisation de la prochaine étape prévue par le Plan, mais en réalisant la ou les fonctionnalités les plus utiles pour compléter le système. Ces adaptations demandent une révision continue du plan de la part du manager-leader, les membres de l’équipe attendent de leur chef qu’ils les guident dans la bonne direction.
Figure 2 : Illustration des itérations L'itération possède son propre objectif (jalon) qui est une étape vers l'objectif final. De même l’alpiniste désireux de conquérir un sommet le fait en progressant par étapes intermédiaires et en adaptant sa progression à la praticabilité des voies.
7
Etre leader, c’est aussi mobiliser les forces vives de l’équipe. Plutôt que de pratiquer l’assignement des tâches, le leader expose les objectifs et montre la direction, de façon à ce que les membres de l’équipe acceptent la responsabilité des éléments à réaliser. Il s’agit là d’un élément essentiel pour passer d’un mode directif (ou micro managérial, à l’extrême) à un mode collaboratif et participatif caractérisant les projets agiles. Il est facile de comprendre que la qualité essentielle du leader sera le charisme plus que l’autorité. Bien sûr, cette qualité seule ne suffira pas à faire aller le projet de l’avant, d’autres éléments sont nécessaires. L’un des principaux sera de maintenir au sein de l’équipe, ainsi que par rapport au client et à la direction, la sensation de progrès continu et d’accomplissement régulier : c’est le rythme du projet.
2. Donner le rythme au projet Il n’y a pas un seul rythme au projet, mais une superposition de plusieurs rythmes d’amplitudes différentes. Le projet lui-même constitue le cycle d’un rythme de grande amplitude, mais nous ne considèrerons pas celui-ci. Nous nous focaliserons sur deux rythmes essentiels : •
Le rythme de l’itération, qui définit les étapes de réalisation majeures du projet.
•
Le rythme journalier, qui montre la progression au sein de l’itération.
Ces deux rythmes, chacun à leur échelle, suivent le même type de cycle, que nous nommerons « cycle de l’agilité ».
2.1 Le cycle de l’agilité « Je ne pense pas que les idées les plus prometteuses soient à venir. Elles sont déjà là et le sont depuis des années, mais ne sont pas utilisées convenablement ». David Parnas
Qu’ils soient grands ou petits, ces rythmes suivent la même progression : préparation, réalisation, retour d’expérience et adaptation. Que l’on évoque une itération (d’une à plusieurs semaines) ou une tâche de réalisation (de quelques heures à quelques jours), cette logique s’applique mais à un ordre de grandeur différent. L’attitude du chef de projet durant ces différentes phases ne variera guère non plus. 2.1.1
Se préparer à faire
Que l’on parle d’une itération ou d’une tâche, la première chose à faire est d’établir un plan d’action. Pour cela, il faut : •
Une idée claire (sinon précise) de l’objectif à atteindre.
•
Une façon de vérifier que la réalisation atteint l’objectif.
Cela se traduit par : planifier et identifier la façon de tester ce que l’on va faire. A cet étape, le chef de projet a pour rôle de faire émerger le plan d’action (ou le planning). L’objectif doit parfois être précisé ou revu si il ne permet pas l’établissement d’un plan d’action réaliste. 2.1.2
Faire
A cette étape, le rôle essentiel du chef de projet est de se tenir hors du chemin des membres de l’équipe ! Cela va directement à l’encontre des pratiques de management intrusif (le « micro-
8
management » que nous avons déjà évoqué). La relation entre le chef de projet et le membre de l’équipe se base sur la confiance et la livraison d’un résultat, et non sur le contrôle en continu. Bien sûr, le chef de projet doit aussi surveiller le risque d’enlisement. Fort heureusement, le projet agile dispose d’un moyen naturel, grâce à son « cycle journalier » pour prévenir un tel risque, sans qu’il soit nécessaire de mettre en place une quelconque surveillance. Le manager a quand même un rôle actif durant cette phase : •
Mettre à disposition les moyens humains et matériels pour permettre l’accomplissement des tâches de la façon la plus efficace possible. Cela est parfois un rôle actif, car les personnes concernées n’ont pas toujours la perception de leur besoin.
•
Faire obstacle aux perturbations, afin de consacrer l’énergie des membres de l’équipe au projet. C’est la « manager firewall ». Nous y reviendrons plus tard.
2.1.3
Feedback
Les projets agiles ont intégré dans leur démarche l’incertitude liée aux projets. Le feedback permet d’évaluer les apports réels d’une fonctionnalité implémentée, même en concordance avec la spécification initiale. Le feedback, c’est également comprendre comment le système contribue au métier de l’utilisateur, découvrir de nouvelles opportunités dans l’évolution du système. L’écoute et l’ouverture d’esprit sont les qualités principales du manager à ce moment. Une attitude que le manager agile devra communiquer à son équipe. Le feedback est le mécanisme essentiel qui fait du projet agile un jeu permanent d’apprentissage et d’adaptation.
2.2 Le rythme de l’itération L’itération est le rythme structurant du projet. C’est au moment de son lancement que le chef de projet agile doit laisser son charisme s’exprimer : il faut donner corps à l’accomplissement que représentera cette itération, donner une vision à l’intérieur de la vision, en quelque sorte… 2.2.1
Planifier l’itération
Contrairement aux idées reçues, les projets agiles planifient bel et bien leurs itérations, mais cette planification se fait sur la base de fonctionnalités à compléter, et non sur la base d’étapes de processus. Planifier, c’est découper les fonctionnalités en tâches et les estimer. La planification et l’élaboration du plan d’action sont l’affaire de tous, sans participation active des membres de l’équipe, il ne peut y avoir de prise en charge volontariste des tâches. C’est en facilitateur que doit agir le chef de projet : si l’équipe est expérimenté, il y a fort peu de choses qu’ait à faire le chef de projet. 2.2.2
Tirer les tâches au lieu de les assigner
Il n’y a guère que deux manières de distribuer les tâches à accomplir : • On peut dire aux membres de l’équipe ce qu’ils doivent faire : c’est l’assignement ou « pousser » les tâches vers ces membres. • On peut laisser les membres de l’équipe prendre en charge la tâche la plus prioritaire. Le premier cas de figure fait non seulement du chef de projet un « goulot d’étranglement » du système, mais est très vulnérable aux synchronisations entre tâches et est peu motivant pour les membres de l’équipe, car réduisant d’autant leur marge d’initiative ainsi que nous l’avons évoqué dans les points faibles des méthodes classiques.
9
Les méthodes agiles sont résolument tournées vers le second mode, qui n’est pas sans rappeler le Kanban Japonais. L’information sur les tâches à faire et les tâches complétées est mise à la disposition de tous (ce peut être via des « radiateurs d’information », que nous allons évoquer bientôt). Cette mise à disposition suffit alors à permettre aux membres de l’équipe de prendre en charge les tâches à compléter. La responsabilité du chef de projet est essentiellement de mettre à disposition de façon correcte l’information sur les tâches, et d’intervenir de manière exceptionnelle si une situation de blocage apparaît. Une manière simple et efficace de mettre à disposition ce type d’information est le « radiateur d’information ». 2.2.3
Radiateurs d’information
Le radiateur d’information2 est essentiellement un panneau d’affichage de grande taille, disposé en permanence. Les informations qu’il dispense sont toujours du même type : tâches à faire ou réalisés, tests passés, etc.… Seul le contenu change, on se sert alors de fiche à épingler ou de post-it que l’on peut déplacer sur ce mur d’information.
Figure 3 : Le radiateur d'information
2
Ce terme est dû à Alistair Cockburn. Si l’origine de ce terme n’est pas donnée par l’auteur, on peut toutefois penser qu’il fait référence à la « diffusion d’information » par analogie à la diffusion de chaleur du radiateur…
10
Si ce radiateur d’information peut être efficacement utilisé pour donner une vue générale des tâches, on peut aussi s’en servir pour montrer l’avancement du projet. Si il possible de montrer cette évolution en terme de progression, il est plus efficace encore de montrer cet avancement en « reste à faire », également appelé burn down chart au sein de la communauté agile.
Figure 4 : Burn down chart
Par rapport au classique diagramme en progression, celui-ci indique plus facilement les évolutions de périmètre : • Un pic en montée indique que des fonctionnalités supplémentaires on été ajoutées au système en cours de route. • Une brutale descente indique que des fonctionnalités ont été retranchées. Ainsi, par rapport au classique diagramme de type « earned value tracking » qui se focalise sur ce qui a été implémentée, le burn down chart intègre parallèlement les évolutions de périmètre du système. Les radiateurs d’information ne se limitent pas aux 2 types d’informations ici décrites : tout type d’information qui a besoin d’être partagée et suivie peut l’être sur un radiateur d’information. Il est du ressort du chef de projet d’identifier les lacunes d’information partagées afin de les rendre visible de tous. 2.2.4
Anticiper l’intégration
Les détracteurs du « time boxing »3 objectent souvent que cette pratique est impossible, car on ne peut contrôler la durée des tâches de tests et d’intégration, qui sont les poins prédictibles d’entre toutes. Ces mêmes détracteurs opposent donc le « feature boxing » au « time boxing », comme principe d’itération, celle-ci ayant alors une durée variable et un contenu fixe.
3
Le « time boxing » est le découpage des itérations en tranches de temps de durée fixe. C’est alors le contenu de l’itération qui devient la variable ajustable car la date de fin est, elle, connue à l’avance.
11
Nos détracteurs ont raison. Du moins ont-ils raison sur les symptômes, mais leur solution est erronée. Car le « feature boxing » oublie un élément important du comportement humain : le rythme. Travailler avec des jalons connus est plus rassurant et plus motivant. C’est une méthode éprouvée pour garder un niveau d’énergie élevée. Travailler avec une ligne d’arrivée fuyante, qui s’éloigne lorsque l’on tente de s’en rapprocher ne permet pas de mobiliser les énergies aussi efficacement. Afin de compenser la faiblesse structurelle du cycle itératif « time boxé », les agiliste ont adopté un autre principe complémentaire : l’intégration continue. Grâce à elle, tests et intégration ne sont pas localisés en fin d’itération, mais vérifiés continuellement sur une plateforme dédiée, chaque fois qu’une tâche est terminée. On n’obtient plus le système à livrer par assemblage final en fin d’itération, mais par accrétion continue durant toute l’itération. En fait le système est théoriquement livrable à n’importe quel moment ! A ce niveau le « petit cycle » journalier ou de réalisation des tâches transparaît au sein du cycle de l’itération. La réalisation d’une fonctionnalité se suffit à elle-même, le chef de projet peut, une fois celle-ci terminée, faire passer la fiche de la fonctionnalité de la colonne « à faire » à la colonne « terminée ». La plupart des équipes de développement sont équipées d’un logiciel de gestion des changements (ou de gestion des « faits techniques », ce qui revient au même !), qui rend silencieux ou anodin ces accomplissements. Le chef de projet se doit néanmoins de rendre ces progrès visibles, et répéter la liste des fonctionnalités gérée sous l’outil de gestion des changements sur un tableau blanc ou sur un radiateur d’information est un moyen de donner du poids à ces accomplissements tout en donnant une visibilité large et permanente sur l’avancement de l’itération. 2.2.5
Réflexion et adaptation
La fin d’itération est un moment privilégié pour jeter un regard rétrospectif sur l’itération, sur ce qui a bien marché et ce qui a moins bien marché. De plus, la nature des travaux tend à évoluer au fil du temps : d’abord exploratoire, il se tourne ensuite vers l’habillage de fonctionnalités et la mise en production, bien que ces transitions sont moins marquées que dans les projets classiques. L’équipe doit se poser les 4 questions suivantes : 1. Quelles sont les pratiques qui ont bien marché, que je dois continuer à pratiquer ? 2. Quelles sont les pratiques dont la mise en œuvre a été déficiente, pénalisant ma vélocité ou la qualité du produit livré, sur lesquelles je dois donc m’améliorer ? 3. Quelles sont les pratiques qui m’ont fait défaut et que je devrais adopter ? 4. Quelles sont les pratiques qui n’apportent pas de plus value au projet et que je devrais abandonner ? Parallèlement à ces questions sur les pratiques, l’équipe doit également se poser la question de son agilité : le processus n’est-il pas en train de s’alourdir, l’efficacité et la capacité de travail sont-elles toujours consacrées à l’avancement du projet ? Répondre à ces questions, c’est analyser les propriétés agiles du projet : • Livraisons fréquentes : Nos itérations donnent-elles lieu à des livraisons permettant d’obtenir du feedback sur le système en cours de construction ? L’itération donne-t-elle une sensation de progrès et d’accomplissement à l’équipe ? • Réflexion et amélioration : L’équipe apprend-elle de ses erreurs ? La qualité du produit livré progresse-t-elle au fil des itérations ? L’efficacité du travail et la satisfaction de l’équipe sontelles sur la pente ascendante ? • Sécurité personnelle : Les membres de l’équipe se sentent-ils suffisamment en confiance pour exprimer leur point de vue, faire connaître les difficultés qu’ils rencontrent ? Un climat de confiance règne-t-il dans l’équipe, par exemple lorsqu’un membre de l’équipe a besoin de se faire aider ?
12
• • •
Focalisation : Les membres de l’équipe comprennent-ils leur contribution à l’ensemble ? Son-ils suffisamment protégés des perturbations pour se concentrer sur leurs tâches ? Accès facile aux experts du domaine : Est-il possible d’aller voir directement les experts du domaine ? Peut-on y accéder à tout moment, ou seulement à des moments négociés ? Donnent-ils du feedback régulier et utile sur ce qui est construit ? Environnement technique (avec tests automatique, gestion de configuration et intégration continue) : La plateforme de développement intègre-t-elle tests et gestion de configuration ? L’outillage de test est-il automatisé ?
2.3 Le rythme journalier Si la fin d’une itération est marquée par la livraison interne ou externe d’une version du système, les principes d’intégration continue ont mis en lumière que cette itération n’est qu’une suite d’évolutions continues du système. Un autre rythme s’inscrit au sein de l’itération, de l’ordre du jour ou de quelques jours, celui de la réalisation des tâches. 2.3.1
Meeting journalier
Responsabiliser ne signifie pas ignorer. Nous avons vu précédemment que le manager agile ne pratique pas le contrôle des taches. Au lieu de cela, ce sont les membres de l’équipe qui partagent leur avancement avec l’ensemble de l’équipe, et cela chaque jour. Les vertus recherchées sont : • Les membres de l’équipe, plutôt que de devoir justifier de leur temps passé, font part de leurs progrès à leur façon. • Les membres ont l’opportunité d’échanger des idées ou de requérir de l’aide dès que cela s’avère nécessaire. • L’équipe synchronise son information fréquemment. Le principe du meeting journalier tient en quelques éléments simples : • Il est court (de dix à 15 minutes environ). Il se déroule toujours au même endroit et à la même heure (de préférence en début de journée). • Chaque participant expose simplement ce qu’il a fait le jour précédant, ce qu’il compte faire aujourd’hui. Si nécessaire, il expose les problèmes sur lesquels il bute et peut demander de l’aide. • Les autres membres de l’équipe peuvent réagir à chaque exposé, notamment si l’un d’eux a déjà rencontré sur un problème semblable (et peut faire profiter son collègue de son expérience), ou si il travaille déjà sur un problème semblable (et sur lequel les 2 personnes pourraient collaborer). Attention ! Il est crucial de ne pas faire dériver la réunion en discussion « en profondeur » en face à face. Le manager agile participe sur un pied d’égalité à cette réunion, sans chercher à la dominer. Il présente son avancement de la même façon que les autres membres de l’équipe. Il peut toutefois être amené à intervenir si les interventions dérivent, en suggérant une réunion à part ou une collaboration entre les personnes concernées. Intervenir en « touche légère » est essentiel afin de préserver la sécurité personnelle des participants ;
13
2.3.2
Ne pas laisser de fenêtres brisées4
Nous avons évoquer le principe d’intégration continue nous conduisant à avoir en permanence un système livrable. Ce principe va de pair avec la pratique quotidienne de « réparer avant de continuer ». La qualité doit toujours avoir la préséance sur la fonctionnalité, ce qui permet de limiter en ampleur les opérations de remise en état, car ces réparations sont ainsi limitées. Le chef de projet se doit de surveiller en permanence l’intégration et la qualité de la livraison et rappeler au besoin la nécessité de correction. Le meeting journalier est un moment adéquat pour cela, car cela permet de commencer la journée en effectuant les corrections, avant de poursuivre le développement des fonctionnalités. Si la déficience de qualité est un mal chronique, le chef de projet devra alors rappeler de façon plus forte la priorité établie sur la qualité. Ce rappel peut aussi prendre la forme d’une coupure dans le cycle de développement : le chef de projet peut décider de consacrer une ou quelques journées à la qualité du système. Durant ce laps de temps, l’équipe peut travailler à des correctifs, au renforcement des jeux de tests, à l’identification des types de tests manquants, etc. Les quelques journées ainsi consacrées ont de la valeur à la fois par le temps consacré, et par l’emphase donnée à la qualité en faisant travailler l’ensemble de l’équipe sur ce même sujet. Bien entendu cet épisode doit être suivi dans le temps soit d’un plan d’action ou d’une pratique plus assidue des tests et des réparations. 2.3.3
Accepter la responsabilité de tâches
Enfin, le cycle court que nous avons évoqué jusqu’ici se caractérise par la réalisation des tâches, la substance même du projet ! Les planifications basées sur l’assignement des tâches sont à la fois plus fragiles vis-à-vis du changement (car le chef de projet devient le goulot d’étranglement de la répartition, et celle-ci doit être complètement repensée fréquemment) et moins motivantes pour les membres de l’équipe car elles grèvent l’autonomie de ceux-ci. Dans un mode de management participatif, qui est celui des projets agiles, les membres de l’équipe doivent être libres de prendre en charge la tâche qui présente le plus de valeur par rapport au projet. En faisant un pas dans la direction opposée au micro management, le projet agile s’écarte du mode « contrôle-commande » si souvent reproché par les équipes. A contrario, ces mêmes membres se trouvent investis de l’autonomie et de la responsabilité de choisir leur contribution. Ils peuvent se faire aider dans leur choix, mais au final ils « signent » d’eux-mêmes pour une tâche, il n’est plus question de se cacher derrière l’assignement pour justifier de sa non implication.
3. Porter la vision « I have a dream… » Martin Luther King
L’équipe de développement agile n’arrive pas au travail chaque matin pour implémenter des fonctionnalités. Pour mobiliser son énergie, il lui faut plus. Pour mobiliser son énergie, le chef de projet agile doit métamorphoser un ensemble de fonctionnalités et de caractéristiques en une vision.
4
Ce principe fait référence à la politique « tolérance zéro » instaurée à New York sous l’administration Giuliani, envers les habitants laissant des vitres brisées non remplacées.
14
3.1 Dessiner un futur exaltant Donner corps à la vision, c’est construire une image mentale du système à créer. Cette image doit bien sûr être partagée, comprise et appropriée par l’ensemble de l’équipe, c’est elle qui permettra à l’équipe d’agir à l’unisson. Pour construire une image mentale appréhendable, il est besoin : • d’un ensemble de concepts simples permettant d’embrasser l’essence du système à construire, • d’une ou plusieurs métaphores qui expliquent le comportement du système. Le premier élément permet d’appréhender la vision externe utilisateur du système, tandis que le second sert à appréhender la cinématique et l’organisation interne (c' est-à-dire l’architecture logique) du système. Le corollaire de cette vision, c’est la nécessité de construire un objectif suffisamment hardi pour enthousiasmer l’équipe. Difficile de soulever cet enthousiasme, si le chef de projet communique comme vision de « faire un peu mieux qu’avant », par exemple ! C’est à ses capacités de meneur que le chef de projet devra faire appel pour communiquer cette vision. Cette vision devra d’ailleurs dépasser les frontières de l’équipe. L’un des exemples les plus emblématiques de vision est le célèbre discours de Martin Luther King. Celui-ci est entièrement construit autour d’une image mentale, d’un objectif pour la communauté noire américaine. Martin Luther King place ses attente très haut, car plus haut elles sont placées, plus forte sera la mobilisation.
3.2 Partager les attentes La vision est aussi un élément à partager avec l’utilisateur, afin de fonctionner également en phase avec celui-ci. Celui-ci devra s’approprier la vision fonctionnelle (les concepts) et s’assurer que ses besoins y sont couverts. En réalité, on peut étendre l’utilisation de cette vision à toute personne impliquées d’une manière ou d’une autre dans le projet : projet connexe, sponsor, etc. De par sa nature simple et synthétique, la vision est le vecteur de communication idéal.
3.3 Construire le jalonnement Construire l’image finale n’est que la moitié du chemin pour le chef de projet, il faut encore tracer le chemin qui mènera vers cet objectif. Au sein d’un projet agile, cette route est faite d’itérations. Le manager agile devra diviser cet édifice en briques qui s’assembleront au fur et à mesure des itérations.
3.4 Favoriser les participations Si le manager agile se doit d’être le porteur de la vision, il ne doit jamais être l’unique contributeur de la vision. Ainsi que nous l’avons déjà évoqué, il n’est pas possible d’obtenir l’engagement de l’équipe sans sa contrepartie en terme de participation. La vision sera donc une œuvre collective, le chef de projet doit accepter que l’image mentale obtenue au final diffère en partie de celle qu’il aurait construite si il en avait été le seul contributeur !
15
4. Créer l’environnement propice 4.1 Droits et devoirs Dans le cadre de projets agiles, chacun se voit assigner un ou plusieurs rôles. Le manager fixe les objectifs, l’équipe tente d’attendre ces objectifs dans les délais et le budget impartis par le client. Dans le meilleur des cas, le manager sait qu’il n’est pas juste donneur d’ordre. En plus de donner des objectifs, il doit donner les moyens nécessaires pour que les objectifs soient réalisables par son équipe. Le rôle du manager agile est de casser cette organisation par rôles pour privilégier un partage de valeurs communes caractérisées par des droits et des devoirs. La manager, les membres de l’équipe et le client ont alors des droits ainsi que des devoirs. Quelques exemples : • L’équipe a le droit d’être respectée par le client, • Les membres de l’équipe ont le devoir de collaborer, de transmettre leurs connaissances, • Le manager à le devoir de partager l’information, • Chacun à le devoir de définir et demander les moyens nécessaires à l’atteinte de ces objectifs, • L’équipe et le client ont le droit/devoir de recevoir / fournir des livrables de qualité. Souvent un droit à son pendant dans la liste des devoirs. De façon similaire à ce qui a été évoqué sur l’attribution des tâches (le manager communique la liste de tâches, chacun s’assigne une tâche), cette « inversion de contrôle » responsabilise et valorise chacun dans ces actes. Une confiance mutuelle peut alors s’instaurer plutôt qu’une relation contractuelle souvent tendue (tant entre l’équipe et le client, qu’entre membres de l’équipe) Il est du rôle du manager de communiquer cette charte des droits et des devoirs. L’existence de cette charte lui impose aussi d’agir en ce qui concerne l’environnement de travail, la diffusion de l’information et la protection de son équipe.
4.2 L’environnement de travail Parmi les droits d’une équipe de développement, un des droits les plus fondamentaux est d’avoir un cadre de travail de qualité et participant à l’efficacité. De qualité pour qu’il contribue au bien être et à la motivation de l’équipe, efficace pour faciliter l’atteinte des objectifs et réduire la durée des itérations. Le manager s’assure que le bon équilibre entre ces deux caractéristiques est respecté. En visant à outrance la productivité, on déshumanise le travail et les développeurs ont vite l’impression d’effectuer du travail à la chaîne. Encore ici, il est de la responsabilité de chacun d’exprimer ses besoins en terme d’environnement de travail. Dans l’industrie automobile, les employés proposent des améliorations à leur environnement pour gagner du temps sur la chaîne de production5. Cette liberté est souvent oubliée en informatique. L’achat d’un progiciel, d’un écran 21’’ ou encore d’une plante verte et d’une machine à café vont améliorer le cadre de travail mais comment calculer le
5
C’est l’un des principes du Toyota Production System, qui fait toujours référence dans le domaine et fut le facteur clé de succès de cette entreprise.
16
ROI ? C’est là que le manager agile doit être aussi imaginatif et sélectif. Si l’on compare une équipe de développement à un commando du GIGN, on imagine mal les résultats sans l’outillage (l’équipement) adéquat. Les développeurs XP vont jusqu’à mettre au point des plans de salle pour optimiser le dialogue, le confort, le partage d’information.
Figure 5 : L'environnement de travail typique6
Un autre aspect que le manager agile doit traiter est la gestion de la monotonie du travail. Le travail en équipe avec des rôles bien partagés, dans un processus itératif avec des cycles très courts peut amener une monotonie qui n’est pas sans rappeler le travail à la chaîne. Il faut alors trouver des astuces permettant de rompre cette monotonie :
6
•
Le manager peut proposer de temps en temps une itération de pur refactoring, afin de casser le rythme monotone des itérations. Si les footballeurs s’entraînent à la montagne avant une grande compétition, c’est autant pour se préparer physiquement que pour faire une coupure dans la répétition des entraînements.
•
Echanger les rôles des membres de l’équipe. On améliore au passage la compréhension et le respect de l’autre, la circulation de l’information et le partage des connaissances.
Sur http://www.scissor.com/resources/teamroom/ ;
17
•
Limiter la durée du travail. Les journées « agiles » sont très rythmées, encore plus avec la pratique du pair-programming. Les anglo-saxons s’astreindront à une « 40 hours week » et nous à la semaine de 35 heures. Les progrès se mesurent aux résultats, non à la présence formelle.
4.3 La diffusion de l’information Le partage de l’information est un point des plus importants dans l’expérience agile. Le manager classique suit les dérives de planning sur une feuille Excel personnelle. Le manager agile affiche l’avancement, la productivité aux yeux de tout le monde. Oui, le client a le droit de connaître l’avancement au jour le jour ! Oui, l’équipe a le droit de connaître les changements d’exigences des clients ! Chacun a en tout cas le devoir de communiquer. On joue la transparence et l’égalité d’accès à l’information toujours pour privilégier la communication à la gestion de crise. Les outils qu’un manager peut mettre en place sont : • L’information radiator (vu plus haut) pour communiquer sur l’avancement du projet. C’est la communication vers le bas. • Intégrer l’équipe et le client sur le même site, voir dans la même salle pour les Agile XP. C’est la communication vers l’extérieur. • Mettre en place un standup metting tous les matins pour partager en 5 minutes les soucis et succès de chacun. C’est la communication en interne. Le standup meeting se rapproche du point matinal dans l’hôtellerie. Tous les membres de l’équipe se retrouvent en rond, debout et en cinq minutes, chacun raconte très rapidement ses avancées de la veille, les soucis rencontrés et son plan d’action du jour. Le manager peut alors agir sur l’organisation de l’équipe et chacun peut proposer son aide pour résoudre les problèmes. La communication à proprement parlé autour d’un problème de fait après le stand-up meeting qui doit rester très court et très cadré. Attention aux effets pervers de la sur-communication : si les indicateurs d’avancement stagnent, si le retour du client est mauvais, au manager agile de remotiver l’équipe en mettant en place un plan de gestion de crise.
4.4 La protection de l’équipe On vient d’évoquer un risque à la sur-communication. La forte implication du client et des utilisateurs dans un projet agile est une seconde source de stress pour les équipes. C’est là que le manager Agile prend son rôle (met son masque ?) de manager « firewall ». Le manager firewall est un savant mélange de mère poule et de chien de garde. Il servira de ligne de front vis-à-vis du client pour maintenir un équilibre dans l’équipe. Il est là pour rappeler aux utilisateurs que l’on ne fonctionne plus dans un mode où le client exige mais dans un mode de concertation avec des droits et des devoirs réciproques. Dans un projet agile, le manager met l’accent sur la « sécurité des personnes ». Le cocon dans lequel les équipes travaillent doit être autant physique (conditions de travail) que mental. Ce que chacun demande pour travailler efficacement sur le long terme, c’est :
• •
Comprendre où elle va, pouvoir agir sur la trajectoire. Une équipe motivée est une équipe qui sait où elle va, qui sait comment, qui se sent protégée par un manager firewall. Etre valorisé au sein de l’équipe. Le manager agile place les bonnes personnes aux bons rôles. Cela amènera un sentiment de confiance à chacun de savoir qu’il est utile. De cela découle une meilleure concentration sur les objectifs. Acquérir de l’expérience grâce à un échange constant de compétences et de savoir faire.
18
5. Instiller la collaboration Le manager classique s’entoure d’éléments experts dans un domaine et mise sur ces expertises tout au long du projet pour garantir des livrables de bonne qualité. Enlevez un expert en cours de projet ou augmenter la charge qui pèse sur un expert et le projet risque de prendre du retard. Le manager Agile doit faire face à cette problématique en tirant les compétences de son équipe vers le haut. Il doit avoir deux objectifs : • Doubler (au moins) les expertises pour réduire les risques • Motiver l’équipe grâce à l’acquisition de nouvelles compétences Pour ce faire, un manager Agile s’entoure à la fois de collaborateurs confirmés pouvant jouer le rôle de référents dans leur domaine d’expertise, mais aussi de collaborateurs plus juniors qui amèneront leur énergie en échange de l’apprentissage de nouvelles compétences.
5.1 Promouvoir l’apprentissage XP s’appuie sur le pair programming pour faire collaborer un senior avec un junior. Chacun peut en apprendre à l’autre. Par exemple, un développeur junior maîtrisera peut-être toutes dernières technologies et un développeur senior amènera sa pratique des design pattern et du refactoring. Ce type de fonctionnement à un coût initial plus élevé mais conduit à une équipe plus homogène et plus motivée, tout au long du projet.
5.2 Développer des communautés D’autres artifices organisationnels participent à l’apprentissage et au partage des connaissances. La création de communautés de compétences au sein de l’équipe permet à des experts de jouer le rôle de leader local ou d’animateur. En ce sens, le manager s’efface partiellement pour laisser la place à des manager locaux. Le manager local devient à son tour un manager agile. Cela permet de tirer l’équipe entière vers le haut, de faire circuler l’information et de valoriser les connaissances et les savoir-faire.
6. Planifier, faire, apprendre Les projets agiles sont rythmés par des cycles. Le manager agile en est le chef d’orchestre : En début de cycle, la planification est la projection vers le futur, la construction ou le raffinement de la vision. Le chef de projet est alors le meneur qui entraîne l’équipe vers la direction choisie. Il doit mobiliser les forces. En cours d’itération, le manager agile se fait serviteur : il écarte les perturbations, met les moyens à disposition de l’équipe et laisse l’équipe travailler sereinement. En fin d’itération, le chef de projet agile se fait facilitateur, il permet à l’équipe d’apprendre par le biais du feedback, il guide celle-ci sur la voie de l’adaptation et de l’amélioration.
19