Le mythe des Valeurs Agiles

Souvent il est fait référence aux 4 valeurs agiles du Manifeste Agile. Mais cette expression « valeurs agiles » est bien mal venue. Elle freine la compréhension et l’adoption de l’approche agile en lui conférant un statut de dogme. Or l’Agilité est tout sauf un dogme.

« Valeurs Agiles » est un terme dangereux

Dire que l’Agilité repose sur des valeurs génère automatiquement des résistances lors de sa mise en oeuvre.

L’entreprise a ses valeurs. Les individus ont leurs valeurs. En positionnant l’Agilité sur le plan des valeurs, on déclare la guerre aux valeurs existantes, donc aux individus et à la culture des entreprises.

Or l’objectif de l’Agilité n’est pas de révolutionner la culture des entreprises, ni de changer les gens.

Le Manifeste Agile commence par « Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. ». Il est facile de mettre tout le monde d’accord sur cet objectif quelles que soient leurs valeurs…

Un problème de traduction

Dans la traduction officielle du manifeste, on utilise le verbe valoriser et non le mot valeur.

Ces expériences nous ont amenés à valoriser :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

source: http://agilemanifesto.org/iso/fr/manifesto.html

On pourrait dire aussi donner plus d’importance à ceci plutôt que cela. Ce n’est pas une question de valeurs. C’est un choix de priorités.

Préceptes Agiles

Plutôt que de parler de « valeurs agiles », il vaudrait mieux dire les 4 préceptes agiles, c.-à-d. des « recommandations pratiques enseignées par l’expérience » (cf. Larousse).

Pour tous les « anciens développeurs » qui ont connu les méthodes et les processus lourds des années 90, les plannings de Gantt qui ne servent à rien, les spécifications incohérentes ou incomplètes, les projets au forfait qui tournent mal etc., les 4 pseudo-valeurs sont des recommandations pratiques issues des enseignements des erreurs du passé.

Et même si ce ne sont que de simples préceptes, ils s’opposent à la croyance dominante dans le monde de l’Entreprise. Cette croyance héritée du Taylorisme est que les méthodes et les processus seraient la clé de l’efficacité et de la réussite.

En s’opposant à cette croyance si largement admise, les préceptes agiles représentent un changement de paradigme. Ils sont donc déjà une mini-révolution.

En parlant de préceptes agiles plutôt que de valeurs, on redonne à l’Agilité sa nature d’approche pragmatique de recherche d’efficacité qui ne menace pas les valeurs de l’entreprise.

 

Agilité: de l’auto-organisation vers l’auto-gestion

coaching PMA et gestion de projet 2.0La méthode Scrum et l’Agilité sont en train de bouleverser la culture des entreprises avec le principe de self-organizing team: une équipe auto-organisée qui n’a plus de manager et qui gère seule ses tâches. La justification d’une équipe auto-organisée est simple: responsabiliser et donner plus d’autonomie aux équipes.

Pour être tout à fait autonome, pourquoi une équipe projet ne gérerait-elle pas aussi son budget ? Une sorte d’auto-gestion…

Coûts, budget, ROI et rentabilité sont des termes absents des méthodes Agiles. De tous les leviers qui influencent les décisions dans une entreprise, l’aspect financier est sans doute le plus puissant. Il a le pouvoir de vie et de mort sur les projets. L’ignorer, c’est prendre un risque.

La proposition est d’intégrer la gestion des coûts et du budget dans le fonctionnement des équipes agiles. 

Concrètement, en quoi consisterait l’autogestion ?

Pour les équipes auto-organisées, cela consiste simplement à ajouter 2 ou 3 indicateurs financiers à leur « radiateur d’information » et à utiliser ces informations dans leur communication externe et pour la prise de certaines décisions.

Par exemple, avec l’autogestion, le backlog produit Scrum montre une liste de fonctionnalités avec un budget associé – Fonctionnalité X 11500€, Fonctionnalité Y 23200€… – comme pour les options d’une voiture neuve. C’est beaucoup plus concret pour le Product Owner et les utilisateurs que les estimations en Story Points qui sont artificiels et relatifs à cette équipe.

Autre illustration: en mode autogestion, l’équipe sait justifier financièrement auprès du management certains choix :

  • investissement pour gagner en productivité (équipement, logiciel…),
  • choix de faire un développement interne ou l’achat d’un composant sur étagère,
  • appel à un prestataire, à la sous-traitance pour des compétences spécifiques
  • recrutement

Avec un logiciel comme TimePerformance, la gestion financière d’un projet se fait toute seule.

Les bénéfices business

  1. Faire coïncider les enjeux réels de l’entreprise avec ceux des équipes projet, aligner les objectifs du management et des équipes
  2. Sensibiliser les équipes à l’importance de la maîtrise budgétaire et de la rentabilité (notamment pour sociétés de service)
  3. Accélérer les prises de décisions d’investissement pour gagner en productivité
  4. Intégrer les impacts financiers dans les choix techniques

Les obstacles: le management et le tabou de l’argent

Cela ne sera pas facile de faire admettre aux managers qu’ils doivent déléguer une partie de leurs prérogatives, la gestion des coûts et des budgets. Comme nous l’avons dit, l’aspect financier en entreprise est le vrai pouvoir.

Mais un manager intelligent verra dans cette délégation une opportunité pour se défaire de tâches administratives de gestion financière pour se tourner vers des missions à plus forte valeur ajoutée: le pilotage, la recherche d’opportunités, le développement de la vision, l’amélioration de la relation client, la conduite du changement, l’amélioration des processus…

Comment surmonter les obstacles

C’est très simple: faîtes-le. C’est à dire gérez les coûts et le budget même si on ne vous le demande pas. Cela ne demande aucun effort avec un logiciel comme TimePerformance. Et il n’est pas besoin d’avoir des chiffres exacts, car ce qui compte est l’ordre de grandeur.

Puis glissez subrepticement au hasard des conversations ou des réunions quelques indicateurs montrant que vous maîtrisez les aspects financiers du projet. Et peut-être que petit à petit on vous fera confiance et on vous confiera plus de responsabilité.

Sachez enfin que cette délégation de la gestion du budget et des coûts n’a rien d’exceptionnel. En fait, elle est pratiquée partout ailleurs que dans l’Informatique. Un chef de produit Marketing a un budget. Un chef de chantier dans le BTP gère un budget et des coûts. Dans le PMBoK, la gestion financière du projet est indissociable de la gestion de projet.

Il y a fort à parier que si les équipes agiles se mettent à parler budget et rentabilité de leurs projets dans les réunions, l’Agilité ne risquera plus de passer pour un « truc » de développeur auprès du management.

Équipe pluridisciplinaire SCRUM: avantages et inconvénients

La méthode Scrum a introduit le concept d’équipe pluridisciplinaire (cross-functional team).

Une équipe pluridisciplinaire Scrum est une équipe pluridisciplinaire dont les membres sont eux-mêmes pluridisciplinaires.

L’avantage évident est de faciliter la collaboration inter-discipline. Mais cela ne serait pas suffisant pour justifier la contrainte supplémentaire de devoir trouver les « bons profils ».

Quel est l’avantage d’une telle équipe par rapport à une équipe pluridisciplinaire classique où chaque membre à un rôle précis ?

L’avantage souvent méconnu est de pouvoir affecter les personnes à 100% sur un projet.

Continuer la lecture de « Équipe pluridisciplinaire SCRUM: avantages et inconvénients »

La méthode agile SCRUM et le logiciel TimePerformance

Le logiciel de gestion de projet TimePerformance a été conçu pour apporter aux équipes SCRUM  une solution simple de gestion de projet qui respecte les principes de l’Agilité et apporte le top de la gestion traditionnelle pour le management.

Petit rappel sur la méthode SCRUM

analogie de la mêlée de rugby avec la méthode agile Scrum

SCRUM est une Méthode Agile créée en 1996 par Ken Schwaber et Jeff Sutherland, conçue initialement pour le développement logiciel.

La principale motivation de son élaboration est de pouvoir gérer des projets complexes avec de nombreuses inconnues, pour lesquels les méthodes classiques (cycle en V, cascade etc.) sont par nature inadaptées.

Pour gérer ce type de projet, il faut pouvoir s’adapter facilement et rapidement aux changements fréquents. C’est le concept d’Agilité.

L’image de la mêlée de Rugby (SCRUM en anglais) illustre parfaitement le style de cette méthode: progression continue, effort soutenu, importance de la cohésion de l’équipe, faire face ensemble pour surmonter les difficultés…

Management Visuel vs Utilisation d’un Logiciel

Le management visuel avec des post-it sur le mur a des avantages indéniables, notamment de convivialité. Mais il a aussi de nombreux inconvénients.

Garder la cohérence entre les post-it, les backlogs dans Excel et les courbes d’indicateurs est fastidieux.

De plus, un tableau vissé au mur n’est pas très pratique pour les communications vers l’extérieur ou les équipes réparties sur plusieurs sites.

L’utilisation d’un logiciel unique permet aussi l’automatisation de certaines tâches administratives.

La question n’est pas de remplacer le management visuel par un logiciel. Il s’agit de remplacer un ensemble hétéroclite de petits outils ou feuilles de calcul annexes, par un logiciel unique et simple.

Rationalisation de l’outillage, génération en temps réel des indicateurs et des courbes, partage de l’information font partie des bénéfices de l’utilisation de TimePerformance.

SCRUM et le monde de l’Entreprise

Convertir toute l’entreprise à la terminologie Scrum est difficile. Il y a très peu de chance que les story points, le burndown, les backlogs, la vélocité etc. soient un langage compréhensible par tous.

Par ailleurs, le contexte d’une entreprise ajoute des contraintes au niveau de la gestion des projets: suivi budgétaire, contrôle des coûts, suivi des temps… Le reporting de projet requiert de parler en jours-hommes et en euros, notamment pour le service Compta.

La spécificité de TimePerformance est de faire le pont entre agilité et management traditionnel.

Cette capacité est illustrée par les nombreuses vues tantôt agiles tantôt classiques proposées par le logiciel.

Cockpit de projet

Vu de l’équipe, le projet suit la méthode Scrum avec ses outils spécifiques: tableau des tâches, release backlog… Vu de l’extérieur, le projet Scrum est géré « comme les autres » avec un suivi budgétaire, un planning…

En fait, pour le management, le projet Scrum géré avec TimePerformance sera bien mieux géré que les autres projets. En effet, TimePerformance met en oeuvre la technique de la valeur acquise. Cette technique est recommandée par les référentiels professionnels de gestion de projet pour la gestion financière et le calcul de l’avancement.

C’est donc le top de la gestion de projet traditionnelle qui est mis à disposition des équipes agiles. De quoi crédibiliser Scrum auprès du management !

Autres bénéfices

Voici quelques autres apports possibles de TimePerformance pour les équipes.

  1. Intégration avec la gestion des ressources
  2. Historique du projet et possibilité d’analyser ce qui s’est réellement passé.
  3. Mesurer les évolutions de périmètre du projet.
  4. Améliorer les estimations grâce à la mesure des écarts planifié vs réalisé au niveau de chaque user story.
  5. Renforcer la Definition Of Done grâce à la fonctionnalité « Méthode ».

Pour la mise en oeuvre pratique de SCRUM avec TimePerformance, lire l’article Guide pour utiliser TimePerformance avec la méthode agile SCRUM.

5 astuces pour SCRUM et le logiciel TimePerformance

TimePerformance est le logiciel de gestion de projets et d’équipes conçu pour faire de l’Agilité dans un contexte professionnel. Il permet de satisfaire les besoins d’agilité des équipes et les besoins de reporting du management.

Voici les 5 astuces pratiques pour utiliser TimePerformance avec la méthode agile SCRUM.

1- La Terminologie

Comme TimePerformance s’utilise avec d’autres méthodes, la terminologie utilisée diffère légèrement de celle de SCRUM mais tous les artefacts SCRUM y sont. Voici un tableau de correspondances pour retrouver ses marques rapidement.

Correspondances
SCRUM TimePerformance
Product Backlog Backlog
Backlog Item ou User Stories Livrable
Release Phase
Sprint Étape
Release Backlog Feuille de Route

C’est tout. Pour le reste, c’est la même chose: burndown chart, diagramme de la vélocité, tableau des tâches…

burndown

2- Rôles Scrum et droits applicatifs

Le Product Owner doit avoir les droits « chef de projet » sur le projet dans le logiciel. Cela lui permet de gérer le backlog, de définir et de prioriser les fonctionnalités du produit.

Pour les membres du projet, il y a des droits « membre du projet », qui leur permettront d’accéder à l’ensemble du projet, au « radiateur d’information » et au tableau des tâches.

Le Scrum Master doit aussi avoir les droits « chef de projet » pour la saisie de l’avancement.

3- Les Estimations

TimePerformance laisse beaucoup de liberté dans le mode d’estimation. Pour un projet Scrum, une unité Story Point ou Ideal Day peut être créée. Le logiciel est très souple et permet de définir pleins d’autres modes d’estimation.

Afin de calculer des indicateurs de plan de charge et de coûts, on fournit un coefficient de conversion pour les unités configurables créées. Cette information correspond à la vélocité de l’équipe.

Par exemple, une vélocité de 40 points par sprint de 2 semaines pour une équipe de 5 personnes est équivalent à une conversion de 1 point en 1,25 jours-hommes de charge de travail. En effet, 40 points nécessitent 10 jours de travail * 5 personnes = 50 jours-hommes.

4- Saisie de l’avancement

Le suivi de l’avancement est réalisé au niveau des livrables (i.e. backlog items ou user stories) en saisissant un pourcentage ou à l’aide du reste à faire. Il y a aussi d’autres options pour le suivi de l’avancement.

5- Tableau des tâches

Toute l’équipe a accès au tableau des tâches et peut créer des tâches. Chaque membre peut mettre à jour le tableau pour ses tâches. Le tableau est aussi mis à jour automatiquement à partir des saisies dans les feuilles de temps. (nb: l’utilisation des feuilles de temps est optionnelle)

Tableau des tâches 

C’est tout…

Pour en savoir plus sur les bénéfices de l’utilisation du logiciel pour une équipe SCRUM, lire l’article La méthode agile SCRUM et TimePerformance.

Anti-pattern agile: le manque de transparence

locked folderLa plupart des retours d’expérience à propos de la mise en place de l’Agilité dans les organisations font apparaître un obstacle majeur: la transparence ne fait pas partie de la culture des organisations.

Pire, la transparence est le plus souvent découragée. On préfère faire bonne figure en toute occasion, quitte à minimiser les problèmes, afin de ne pas être injustement classé parmi les messagers porteurs de mauvaises nouvelles. Cela engendre le syndrome du projet pastèque, rouge à l’intérieur et vert à l’extérieur.

Or c’est justement sur la transparence, ou plus exactement sur le marché implicite «confiance contre transparence», que repose la démarche Agile. Grâce à elle, la collaboration entre le Métier et l’équipe de développement est beaucoup plus efficace, car elle est directe, peu formalisée dans des documents ou ralentie par des processus (de validation ou autres).

Pour passer à l’Agilité, il y a un changement de culture à opérer au niveau de l’organisation tout entière.

Les équipes de développement, et les chefs de projet en particulier, doivent désapprendre la crainte de se faire taper sur les doigts à chaque annonce de contre-performance ou de difficulté. Ils doivent trouver un courage nouveau pour communiquer les éventuelles mauvaises nouvelles le plus tôt possible. Cela permet à tous de prendre les bonnes décisions au meilleur moment. Le Management doit encourager cette transparence et associer la contre-performance à de l’apprentissage. 

Quant au Métier, il doit s’associer à l’équipe de développement et quitter le mode de collaboration client-fournisseur. S’associer implique de ne former qu’une seule équipe et de participer à la résolution de tous les problèmes, y compris techniques. Cela passe par une acquisition d’un minimum de connaissances techniques sur le projet et par la recherche active du meilleur compromis entre valeur métier et faisabilité. Un gain supplémentaire non négligeable pour le Métier sera d’en retirer au final une bien meilleure compréhension de son produit ou de son outil.

Les équipes sont-elles prêtes à faire part de mauvaises performances éventuelles ? Le Management pénalise-t-il les mauvaises performances sans distinction ? Le Métier a-t-il envie de s’impliquer dans la technique ? Les réponses à ces questions sont essentielles pour démontrer un environnement propice au développement de la valeur Transparence, indispensable à la démarche Agile.

Quel rôle pour les chefs de projet dans Scrum ?

La méthode Scrum définit 3 rôles. Celui de chef de projet n’en fait pas partie. Beaucoup en déduisent qu’il n’y a plus de chef de projet avec Scrum. Certains s’en inquiètent en se demandant ce que vont devenir les chefs de projet lors du passage à Scrum.

Dans Scrum, le «chef de projet» est le Product Owner

Le chef de projet est la personne à qui on donne une mission, un mandat, pour mener à bien un projet. On lui délègue des pouvoirs, des moyens et la responsabilité du succès du projet.

Mener à bien un projet signifie de livrer de la valeur tout en respectant un budget et des délais.

C’est aussi la mission du product owner.

Le product owner est le responsable du backlog produit. Il priorise les éléments et leur associe une valeur business. Il gère aussi le release backlog qui détermine les délais et le budget du projet. Il a aussi le pouvoir d’arrêter le projet lorsqu’il juge que le ROI est insuffisant. 

Ce qui change avec Scrum

Certaines fonctions dévolues traditionnellement au chef de projet sont déléguées à d’autres personnes.

Il n’y a plus de management d’équipe

Dans Scrum, l’équipe s’auto-organise et s’autogère à l’aide d’un facilitateur, le Scrum Master. Il n’y a donc plus de management hiérarchique.

La gestion de la qualité

Le Scrum Master est responsable du respect du processus de développement et des normes de qualités.

C’est l’équipe toute entière qui est responsable de la qualité du produit.

Le découpage technique du projet et les estimations

L’expertise technique est du ressort de l’équipe. C’est elle qui identifie les tâches et estime la charge de travail.

Les bénéfices de l’approche Scrum

Le fait de déléguer une partie de ses fonctions à d’autres personnes peut être vu comme une très bonne chose.

Le chef de projet est traditionnellement surchargé du fait de ses multiples tâches: gestion de l’équipe, contact client, planification, gestion des coûts, gestion des anomalies…

De plus, certaines responsabilités peuvent amener à des conflits d’intérêt. Par exemple, la recherche de réduction des délais et des coûts peut inciter à sacrifier la qualité du produit.

Enfin, le rôle traditionnel de chef de projet peut exiger des compétences très différentes (communication, expertise technique, négociateur, écoute client, gestionnaire, leadership). C’est pourquoi on trouve souvent des descriptions de poste de chef de projet qui ressemblent à celle d’un mouton à 5 pattes.

Conclusion

La mission essentielle du chef de projet vis-à-vis de l’entreprise est confiée au Product Owner. Il n’est pas le chef d’une équipe mais le titulaire d’un projet ou d’un produit qu’il incarne.

Les chefs de projet qui deviennent product owners verront  leur (sur)charge de travail diminuée et pourront se concentrer sur la création de valeur métier.

Par contre, le management d’équipe disparaît. Le concept de « chef de projet technique » ou de team leader n’a pas d’équivalent dans Scrum. C’est un réel problème pour les personnes avec ce type de profil. Une reconversion en Scrum Master n’est pas forcément possible dans la mesure où cela requiert un type de personnalité très différente de servant leadership et non de chef. Les autres choix sont d’aller vers l’expertise technique, en espérant que celle-ci soit reconnue à sa juste valeur, ou vers le fonctionnel pour devenir product owner.

Le rôle du Product Owner dans SCRUM

Voici une excellente vidéo de Henrik Kniberg qui explique en 15 minutes le rôle du Product Owner dans Scrum.

Henrik Kniberg est aussi l’auteur de fameux Scrum and XP from the Trenches (téléchargeable gratuitement).

La vidéo est en anglais. Le texte est disponible sur le blog de Crisp.

Agilité et Lean Startup

L’Entreprise 2.0 reste un concept un peu vague bien que le changement soit pressenti comme inévitable.

Le 2.0 est bien plus que de la collaboration informelle. C’est l’ensemble de toutes les réponses aux bouleversements de notre monde actuel.

Il existe une déclinaison concrète du concept d’Entreprise 2.0 pour les startups: la Lean Startup.

Dans la vidéo ci-dessous,  Abby Fitchner nous présente les nombreuses similitudes entre Lean Startup et l’Agilité, qui représente une autre évolution majeure et récente dans le fonctionnement des entreprises.

[vimeo 27797408]

How Lean Startup Pushes Agile to the Next Level from Abby Fichtner, Hacker Chick on Vimeo.

Agilité et suivi des temps, pour quoi faire ?

Le suivi des temps déchaîne rarement l’enthousiasme dans les équipes et bien des managers traditionnels peinent à le mettre en place. Cependant il trouve un nouveau sens et se renouvelle en mode agile en devenant une source précieuse de feedbacks pour toute l’équipe, principe fondamental de l’Agilité.

Feedback et Suivi des temps (Time Tracking)

timetrackingEn matière de gestion de projet, le processus d’estimation reste un exercice difficile et approximatif, alors qu’il est essentiel pour déterminer la viabilité du projet. Et le suivi des temps est le seul moyen d’obtenir un feedback pertinent sur ce processus critique.

Dans le domaine du développement logiciel, les tentatives de rationalisation du processus d’estimation ont abouti à des résultats médiocres malgré la complexité des modèles analytiques développés (points de fonction, Cocomo etc.). En général, estimer un projet reste un processus empirique basé sur l’intuition et l’expérience des équipes, agrémenté de techniques de recherche de consensus. Mais la fiabilité des processus empiriques est soumise à caution et on constate en pratique des marges d’erreur importantes.

En mode Agile, on a la chance de pouvoir vite améliorer le processus d’estimation empirique. Il suffit de fournir à l’équipe le feedback adéquat: les écarts entre les estimations et le temps réellement passé au niveau de chaque item du backlog.

Alimenter en informations chiffrées les rétrospectives (SCRUM) est le premier objectif du suivi des temps en mode Agile. L’équipe fournit un retour qualitatif et humain, le suivi des temps le complète par un feedback quantitatif et objectif.

L’indicateur de Vélocité seul ne permet pas d’identifier les causes des problèmes. En effet, calculé au niveau du Sprint (= itération), c’est un indicateur trop macroscopique influencé par de nombreux facteurs. De plus, la Vélocité n’est pas une mesure mais le paramètre d’un modèle linéaire simple entre complexité et charge de travail.

Le suivi des temps permet aussi d’avoir une mesure précise du facteur de concentration (focus factor) pour ceux qui l’utilisent.

Pour être utile, le feedback doit se faire au même niveau de détails que le processus d’estimation (i.e. backlog item, user story, la fonctionnalité…). C’est à ce niveau que le suivi des temps prend toute sa valeur (et non au niveau des tâches). Il permet de mesurer la fiabilité de chaque estimation, prise séparément. Il est alors possible d’ajuster le processus d’estimation pour prendre en compte d’autres facteurs que ceux du modèle générique.

Voici quelques leçons apprises chez Time Performance grâce au suivi des temps avec TimePerformance:

  • Nous passons environ 30% du temps sur des sujets qui ne font pas partie de la feuille de route du produit.

    Dans ces 30%, on retrouve les refactorings, les corrections d’anomalies, les petites améliorations, les tests utilisateurs…

    Le suivi des temps nous a permis de budgéter pour les itérations suivantes ce qui n’était pas dans la feuille de route.

  • Les tâches les plus complexes ne sont pas celles qui relativement prennent le plus de temps.

    Certaines tâches sont très simples techniquement mais prennent néanmoins du temps. Et la relation entre complexité technique et charge de travail n’est pas linéaire.

    Par exemple, il peut être nécessaire de faire de nombreuses retouches avec des allers-retours avec les utilisateurs. Il y a aussi des «coûts fixes», car même pour une fonctionnalité simple, il faut écrire des tests et de la documentation.

    Attention donc à ne pas sous-estimer le temps nécessaire sous prétexte que c’est simple techniquement.

  • Notre perception du temps est très subjective, bien plus qu’on ne le pense.

    Certaines heures paraissent être des minutes et certaines minutes paraissent durer des heures. Tout dépend si ce qu’on fait nous plaît ou non.

    Par exemple, certains se font une montagne de devoir remplir une feuille de temps alors que cela ne prend que quelques minutes par semaine. Et on retrouve les mêmes à la machine à café en train de discuter depuis 45 minutes sur le temps qu’il fait. L’exemple fonctionne aussi avec l’écriture des tests, de la documentation… Tout le monde se reconnaîtra, nous les premiers.

    Le suivi des temps peut permettre à chaque individu d’objectiver le temps qu’il passe réellement sur les tâches.

  • Notre marge d’erreur sur les estimations était plus importante sur les nouvelles fonctionnalités que sur les évolutions.

    En y réfléchissant, c’est assez logique. D’abord le risque est plus important pour une fonctionnalité importante et totalement nouvelle. La solution imaginée au moment de l’estimation peut ne pas marcher et nécessiter plusieurs ajustements. Les impacts sont aussi plus importants et des refactorings du code et des tests existants sont très probables.

Un suivi des temps efficace est absolument essentiel pour les équipes agiles pour maîtriser leur processus d’estimation. Cela mérite bien qu’on y passe quelques minutes par semaine.

Suivi des temps et gestion du projet

Traditionnellement, la feuille de temps sert principalement à suivre les coûts réels du projet en comptabilisant le nombre de jours travaillés.

En mode Agile, il est recommandé des équipes stables et des affectations à plein temps, ce qui rend la feuille de temps inutile.

Cependant la réalité des entreprises est souvent bien différente du cas idéal:

  • les personnes participent à la vie de l’entreprise (réunion de service, aider un collègue, veille, réorganisation…);
  • les personnes travaillent sur le projet mais peuvent être appelées en urgence sur d’autres sujets;
  • la spécialisation d’une personne ne permet pas une affectation à plein temps;
  • Une compétence rare est réclamée par de nombreux projets …

En pratique, le suivi des temps est indispensable pour connaître le temps réellement passé sur le projet. Il permet notamment de constater un écart entre affectation prévue et affectation réelle, qui explique dans de nombreux cas les retards dans les projets.

Même en mode Agile, le suivi des temps est en général nécessaire pour gérer le projet.

Vaincre les résistances

La mise en place du suivi des temps dans une équipe est un moment délicat où il faut faire preuve de leadership pour porter la vision.

Voici les 3 clés pour réussir la mise en place du suivi des temps:

  1. Donner du sens. C’est l’objet de cet article et la principale mission du manager ou du SCRUM Master.
  2. Faciliter la saisie par l’équipe. C’est ce que nous avons fait chez Time Performance avec notre logiciel TimePerformance en proposant 2 moyens complémentaires pour suivre facilement  son temps: une feuille de temps (déclaration a posteriori) et une liste de tâches avec une fonction type «chronomètre» (suivi au fil de l’eau).
  3. Montrer des résultats, c.-à-d. exploiter les informations et communiquer les résultats à l’équipe. C’est sans doute le plus important et ce qui permettra de convaincre les plus sceptiques.

Il y a encore quelques années, écrire des tests ou documenter le code n’étaient pas plus populaires que le suivi de temps parmi les développeurs. Aujourd’hui, c’est le quotidien des équipes agiles qui s’en font une fierté. Dans quelques années, un bon suivi des temps pourrait devenir le signe de maturité et d’autogestion d’une équipe…