L’une des suppositions les plus répandues et les plus tenaces concernant la réalisation d’un projet selon les approches Agiles consiste en l’absence de spécialisation. On clame haut et fort que les membres de l’équipe doivent être complètement interchangeables. On insiste à outrance sur la pluridisciplinarité et l’interchangeabilité. Ce que les plus ardents défenseurs oublient souvent c’est de clairement faire la distinction entre la réalité et la cible; l’arbitrage entre l’utopie et la binarité.

C’est un peu comme si je voyais mon voisin avoir un malaise cardiaque. Je ne suis pas médecin, ni infirmier. Je n’ai pas suivi de cours de réanimation cardiorespiratoire (je sais, je le devrais; c’est dans mon backlog) et je n’ai surtout pas de défibrillateur à la maison. Je peux bien lui tapoter les joues, le secouer ou l’installer plus confortablement ou je ne sais quoi d’autre. Toutefois, je pourrai le sauver seulement si je commence un massage cardiaque. Oui, je serai maladroit. Oui, je risque de ne pas réussir, mais pour mon voisin, il est critique que j’essaie quelque chose. Le statu quo n’est pas une option. Évidemment, un appel au 911 aidera grandement, mais mon cellulaire n’est pas un défibrillateur. L’appel ne sauvera pas directement mon voisin. Le spécialiste du 911 utilisera l’information que je donnerai (circonstances, environnement, sa taille et son pouls, etc.) pour me guider et poser les gestes nécessaires, pour raffiner ma technique, la puissance de mes mouvements et ainsi maximiser les chances, dans les circonstances, de sauver mon voisin. Une chance qu’il le fait! Imaginez ce qui arriverait s’il me refusait son aide?

Voici la réalité : Un architecte fonctionnel ne connait peut-être pas le langage de programmation choisi. Le spécialiste d’affaires ne connait probablement pas la structure des bases de données. L’équipe consiste donc en une entité construite avec des composants ayant des compétences particulières et pointues. Le fait d’avoir des expertises unidirectionnelles ne nous empêche pas de livrer la marchandise, mais ça nous empêche de la livrer le plus rapidement possible, de nous entraider. Évitons les goulots d’étranglement et travaillons en équipe!

La cible, vous l’aurez compris, c’est de s’entraider, de ne pas attendre, d’essayer à la mesure de nos connaissances ou à l’aide des conseils des spécialistes. Que je sois programmeur, architecte, préposé aux bénéficiaires, livreur de journaux ou avocat importe peu. Je dois sauver mon voisin. Il est donc important de bien cartographier les compétences des équipiers afin de bien connaitre, par analogie, si le préposé au 911 devra expliquer où se situe le cœur dans l’abdomen ou si l’équipe compte quelqu’un d’assez fort pour appliquer la pression adéquate sur la poitrine lors du massage cardiaque.

L’utopie, c’est que tout le monde doive maîtriser toutes les techniques de réanimation cardiorespiratoire et tous les métiers pertinents. Impossible de faire mieux… c’est une utopie. Ça peut rester un objectif, une cible, mais ce n’est certainement pas une réalité utilisable à court terme pour la majorité des organisations.

Planifier, c’est la même chose. L’analyse de la capacité de l’équipe s’effectue sur la base de la capacité globale des individus, mais il est essentiel de garder un œil sur la capacité par corps de métier. Non seulement voulons-nous nous assurer que tout le monde sera occupé durant tout le projet ou tout le sprint, mais nous voulons également maximiser leur utilisation. Discutez de la nature des user stories à livrer. Ayez ce concept à l’esprit quand vous montez votre plan de livraison en équipe et gardez votre carnet de produit en santé. Misez sur l’empirisme de Scrum et utilisez les rétrospectives pour réévaluer vos ratios et estomper de plus en plus les parois des silos des corps de métier.

Dans un deuxième temps

Constater la réalité – Vous connaissez-vous vraiment? Connaissez-vous véritablement votre équipe? Bien sûr, vous connaissez le métier de chacun, mais connaissez-vous leurs expériences passées, leurs aspirations, leurs qualités cachées? Connaissez-vous les situations et conditions qui leur permettent de passer une journée anormalement agréable au travail? Savez-vous ce qui les motive? Constater la réalité va au delà du coffre à outils. Commencez par une cartographie des compétences. Ne vous arrêtez pas à ce que la personne fait, mais insistez sur ce que la personne sait faire, a déjà fait, aimerait refaire ou aimerait essayer. Un programmeur aspire-t-il à devenir un architecte fonctionnel? Un architecte organique a peut-être commencé sa carrière en tant qu’analyste en sécurité informatique? Un spécialiste d’affaires a peut-être été promu au marketing de l’organisation pour profiter de sa maitrise étendue de tous les produits parce qu’il a déjà œuvré au sein de l’équipe de contrôle de la qualité? Bien cartographier ses compétences, c’est reconnaître sa capacité, sa diversité. En ayant une meilleure compréhension de l’aspect « être humain au travail » dans l’équipe, vous serez mieux en mesure de les orienter en prenant le chemin que les équipiers se seront tracé pour eux-mêmes. Le voyage vers cette destination n’en sera que plus facile.

La planification – Le ratio des compétences requises varie au cours de la réalisation du projet. Au début d’un projet, on assiste souvent à une « préparation du terrain ». Réaliser les premières fonctionnalités ou user stories requiert souvent un peu plus de travail de fond. Les estimations et la complexité des tâches à réaliser sont généralement plus élevées que lorsque l’équipe a atteint son rythme de croisière. L’équipe doit relever le défi d’une architecture émergente (à lire : article très intéressant sur le rôle de l’architecte). Ensuite, les ratios se stabilisent pour finalement changer de nouveau vers la fin du projet (moins d’architecture requise). Une équipe clairement cartographiée aura tous les éléments en main pour réagir rapidement et pour trouver les déficits de compétence. Lorsque vous discuterez des user stories lors de l’établissement de votre carnet de produit, plan de livraison ou carnet de sprint, gardez ces concepts à l’esprit. Certaines équipes vont même jusqu’à évaluer l’ampleur des chantiers par corps de métier à l’aide du Planning Poker®, par exemple. D’autres identifient plus grossièrement (petit, moyen, gros). Tout dépend de la diversité de la compétence des équipiers, de la culture de l’organisation, de la volonté et de la capacité à s’entraider. Il devient alors crucial de ne pas tomber dans l’exercice de maintenir et confirmer les silos, mais bien de constater la réalité pour la faire évoluer.

En cours de sprint, le temps passe, c’est incontournable. Le nombre d’heures réelles diminue à chaque journée du sprint. Il est donc facile d’illustrer graphiquement ce temps qui passe. C’est un fait. Après chaque journée, la capacité diminue de 7 ou 8 heures, moins, si on assume un pourcentage de non-productivité. C’est la capacité. Il peut être alors très intéressant de suivre la capacité par métier et de la comparer sur le reste à faire par métier, avec un sprint burndown chart légèrement modifié, par exemple.

Le reste à faire est variable. Il dépend du travail à faire et des tâches à réaliser. Illustrer la différence entre la capacité et le reste à faire permet de répondre à la question « Est-ce qu’il reste assez d’heures pour nous (me) permettre de réaliser notre (mon) reste à faire? » L’équipe et l’équipier tiennent un rythme soutenu et soutenable, sans heures supplémentaires. L’équipe veut s’assurer de fermer le maximum de chantiers afin de créer de la vélocité et de livrer le plus de valeur possible à chaque sprint. Elle veut créer de la visibilité pour s’aider à réaliser ses objectifs. Donc, si elle manque de capacité, elle est en mesure de mieux prioriser ses travaux.

Le graphique ci-contre met en lumière les silos constatés dans une équipe. Dans cet exemple, les architectes de l’équipe sont capables de programmer et font partie du silo de développement avec les programmeurs. Les autres silos identifiés pour cette équipe regroupent les tâches liées aux donnéesaux essais et à la documentation. Pour cette équipe, la compétence relative à l’architecture est couverte plus qu’adéquatement. Ce n’est pas un enjeu. Si ça l’était, il y aurait un silo de plus sur le graphique.

Ce diagramme illustre donc de façon très précise la capacité manquante (trop de reste à faire pour le temps qu’il reste) ou les excédents (beaucoup de jeu) selon chaque journée du sprint, et ce, pour chacun des silos. Il permet d’analyser plus précisément et de rendre visible les risques liés du métier et les défis de réalisation. Il permet à l’équipe de se questionner en temps réel et de changer son discours pour passer de « Tu es sûr que je ne peux pas t’aider? » à « Comment puis-je aider? On n’arrive pas… »

D’autres équipes préfèrent utiliser un tableau de style Kanban apposé sur un mur avec des post-its de couleur pour représenter les corps de métier et les silos. L’équipe se conforte visuellement avec cette approche un peu plus macroscopique. Peut-être cette équipe est-elle plus pluridisciplinaire qu’une autre? Peut-être que ses membres ont mieux assimilé les enjeux et implications du concept d’équipe? Peu importe, pour eux, cette approche à ce moment précis est suffisante et efficiente.

Et c’est ça le but : trouvez votre voie, faites confiance à l’équipe, expérimentez et évoluez. Faites-vous confiance et faites appel à un coach d’équipe si vous en éprouvez le besoin. Peu importe la façon que vous choisirez, l’objectif c’est de prendre conscience des silos et d’agir. De quitter sa réalité actuelle et de viser la cible, de se définir une nouvelle réalité, de sauver le voisin.

Et vous, comment vous y prenez-vous actuellement pour sauver votre voisin?

Quelles pistes allez-vous explorer?

pyxis

Pyxis est présente en Amérique du Nord, en Europe et en Asie.

Nos conseillers Agiles vous aident à concrétiser réellement les avantages de l’Agilité : accroître la fréquence des livraisons et la vélocité des équipes; collaborer avec les clients en s’alignant sur leurs besoins; maîtriser les risques et les changements en cours de livraison et encourager la concentration, la rigueur et l’énergie au sein des équipes. Communiquez avec nos coaches, formateurs, Scrum Masters et développeurs pour en apprendre davantage sur nous.

Billet précédent

Soirée dévoilement de Pyxis

Billet suivant

Sauvez votre voisin! (suite)

2 Commentaires

  1. cma.pmp@gmail.com'
    Jean
    05/07/2013 at 00:33 — Répondre

    Chez nous il y a de la réticence à sortir de sa zone de responsabilité. Nous essayons mais c’est difficile… J’ai bien hâte de voir vos réflexions additionnelles sur le sujet.

    • 05/07/2013 at 12:45 — Répondre

      Merci pour le commentaire Jean.
      Souvent, les petites entreprises ont un cloisonnement métier beaucoup moins présent. C’est compréhensible, l’entreprise n’a pas nécéssairement les ressources financières et humaines pour se procurer certaines expertises. Elle doit compenser autrement.

      Dans les grandes organisations, souvent plus agées, le cloisonnement fait presque partie de l’ADN. Il est alors plus difficile de changer les paradigmes de fonctionnement. L’humain y trouve aussi une certaine valorisation à travers sa rémunération, sa reconnaissance découlant de la rareté (ou non) de son expertise, etc. C’est tout le volet culture de l’organisation qui résiste, pas juste les individus – à garder en tête dans vos interventions!

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.