Comment savoir que votre équipe projet n'est pas agile :
Voici les différents comportements à surveiller

Le , par Michael Guilloux, Chroniqueur Actualités
Si les adeptes de l’Agile le vantent d’être une source d’énormes gains de productivité et d’efficacité, sa pratique exige cependant une parfaite collaboration entre différentes équipes.

Qu’il s’agisse des utilisateurs finaux, des développeurs, des consultants ou de l’équipe de management du projet, chacun doit jouer un rôle important pour pouvoir atteindre les résultats attendus. Il s’agit en effet d’une chaîne dont la force sera déterminée par sa capacité à soutenir le maillon le plus faible. D’une défaillance de l’une des parties ou d’un manque de cohésion entre les différentes parties, il pourrait donc en résulter l’échec du projet agile.

Le choix des membres des équipes agiles est donc important, mais bien souvent difficile à évaluer. Au début du projet, il est plus facile de croire qu’on a réuni l’équipe de rêve, mais après le démarrage, certains signes de faiblesse peuvent être observés au niveau des membres de l’équipe projet. Il est donc crucial de les détecter et les corriger le plutôt possible pour garantir le succès du projet agile.

Les signes qui pourront vous indiquer que votre équipe n’est pas agile sont multiples et dans un billet sur le site cio.com, ils ont été regroupés selon qu’il s’agit d’un utilisateur, d’un développeur, d’un consultant ou d’un manager.

Comment savoir qu'un développeur n'est pas agile ?

Chez les développeurs par exemple, il est important de surveiller l’excès de perfectionnisme. Un développeur qui a tendance à faire de la sur-qualité n’est pas le plus approprié pour un projet agile. Il faut également veiller à ce que ce dernier ne soit pas trop axé sur l’architecture et la longévité du logiciel.

Le développeur agile est également quelqu’un qui n’a pas peur des critiques et qui peut donc explorer d’autres pistes pour apporter une valeur ajoutée au projet, explique le billet.

Un programmeur qui est plus enclin à « coder d’abord et poser des questions plus tard » peut également compromettre le projet agile. Un développeur agile doit plutôt poser le plus de questions dès le début pour avoir une vision claire et nette du chemin à suivre. Cela permettra d’éviter de refaire à nouveau tout le travail.

Il doit encore fait preuve d’une capacité d’écoute et avoir de bonnes compétences en communication. Un développeur qui présente des insuffisances en gestion de projet ou qui n’a aucune notion de management serait également un fardeau pour l’équipe agile.

Mais le genre de développeur qu’il faudrait par-dessus tout éviter, serait probablement celui qui déteste ou qui n’a aucune empathie pour les utilisateurs. C’est exactement le genre de développeur qui ne voit pas l’importance d’associer les utilisateurs dans les projets et qui considère ces derniers comme un obstacle à l’avancement du projet.

Comment savoir qu'un utilisateur n'est pas agile ?

Du côté des utilisateurs, ceux qui ne sont ni engagés, ni motivés, qui ne voient pas l’intérêt du projet et qui sont plus préoccupés par leur activité régulière représentent une menace sérieuse pour le bon déroulement du projet. Il en est de même pour ceux qui sont rigides au changement, qui y voient un risque et qui considèrent l’apprentissage comme un problème plutôt que de voir ses avantages.

Vous devez savoir que votre équipe n’est pas agile lorsque vous verrez aussi que les utilisateurs impliqués dans le projet ont tendance à ne pas respecter les délais qui leur sont fixés dans les tâches qu’ils doivent exécuter. C’est le cas notamment lorsqu’il s’agira pour eux de donner leur accord pour la validation de certains documents auxquels ils ne comprennent peut-être pas grandes choses. C’est le genre d’utilisateurs qui ne veulent pas avoir de problème, alors leurs décisions sont extrêmement prudentes. Ils ne prennent aucune décision lorsque les informations à leur disposition sont incomplètes.

Des utilisateurs qui ont également tendance à beaucoup bavarder lors des réunions sans pourtant faire de propositions concluantes sont une menace pour le projet agile. Ces derniers ne réussissent en général qu’à amplifier les problèmes clairement délimités.

Comment savoir qu'un manager n'est pas agile ?

Dans le management également, certains signes peuvent montrer clairement que l’équipe ne fait pas de l’Agile. C’est le cas notamment lorsque vous verrez des responsables qui refusent de participer activement au projet et d’en prendre les rênes. Il en est de même pour un manager toujours prêt à responsabiliser les membres de l’équipe projet sans pourtant leur donner le contrôle des ressources.

Un exemple typique de manager non agile est ce genre de responsables qui nient les réalités du projet. Ils définissent mal les priorités et pensent toujours que les délais fixés sont largement suffisants.

Un manager qui utilise la peur comme un outil de management et qui blâme l’échec publiquement pourrait garantir avec certitude l’échec du projet agile. Le projet serait également compromis si ce dernier est plus axé sur le budget que sur la valeur, et s’il accorde peu d’attention aux principaux objectifs.

Une autre façon pour le manager de faire échouer le projet serait de promouvoir des personnes qui ne savent vraiment rien du domaine et qui ne sont non plus disposées à apprendre.

Comment savoir qu'un consultant n'est pas agile ?

Lorsqu’un consultant intervient dans un projet, pour qu’il soit agile, il doit également présenter certaines caractéristiques. Un consultant trop souple, ou trop conforme, ou encore qui est prêt à prendre des engagements qu’il ne peut pas respecter, voilà ce qu’il faut pour mettre le projet en péril.

Le consultant doit être encore capable de transmettre les mauvaises nouvelles le plus tôt possible et efficacement. S’il dit « non », il doit être capable de s’en tenir à cela, et s’il n’est pas disposé à prendre en charge certaines situations incertaines, alors il serait difficile pour lui de faire de l’Agile, explique le billet.

Il faut également éviter les consultants incapables d’écouter et qui ne sont pas en mesure de répondre aux demandes des clients le même jour. Entre autres signes qui caractérisent un consultant non agile, il faut également souligner que celui qui n’est pas disposé à venir sur le site du client est un obstacle à la pratique de l’Agile.

Source : cio.com

Et vous ?

Quelle est votre opinion de ce qui caractérise une équipe agile ou qui ne l'est pas ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de dfiad77pro dfiad77pro - Membre expérimenté https://www.developpez.com
le 13/05/2015 à 8:34
Chez les développeurs par exemple, il est important de surveiller l’excès de perfectionnisme. Un développeur qui a tendance à faire de la sur-qualité n’est pas le plus approprié pour un projet agile. Il faut également veiller à ce que ce dernier ne soit pas trop axé sur l’architecture et la longévité du logiciel.
Pour mon cas personnel, je suis capable des 2, en gros je fais selon le projet. Parfois l'agile passe sur des phases de programmation maquette et d'adaptation avant de revenir sur la qualité de code. Dans ce cas la qualité des développeurs et leur capacité à anticiper et comprendre le métier est primordiale.

Mais le genre de développeur qu’il faudrait par-dessus tout éviter, serait probablement celui qui déteste ou qui n’a aucune empathie pour les utilisateurs. C’est exactement le genre de développeur qui ne voit pas l’importance d’associer les utilisateurs dans les projets et qui considère ces derniers comme un obstacle à l’avancement du projet.
Malheureusement , il y'en a un paquet, je pense qu'agile doit amener la satisfaction de faire plaisir aux utilisateurs.
Cela responsabilise mieux le développeur et lui donne vraiment l'impression d'être au service de l'utilisateur, et pas d'un amas de papier de spec, cela dis on a souvent tendance à négliger les specs...

Dans la réalité c'est plus complexe, car l'implication forte des utilisateurs leurs donne envie d'avoir un paquet de fonctionnalités, et il faut trancher sinon on coule !
Le bon agile doit ( selon moi ) être un bon pédagogue et prendre du plaisir à expliquer le pourquoi du comment !
Avatar de MintWater MintWater - Membre actif https://www.developpez.com
le 13/05/2015 à 8:37
Prendre les concepts agiles à l'envers en expliquant les chemins qu'il ne faut pas emprunter est intéressant mais ce n'est au final que du bon sens.
Nous expliquer que les excès et les insuffisances sont néfastes, ça me parait un peu superficiel.
Dans tous les cas, nous avons une jolie check-list pour déterminer les "person to blame" quand un projet agile foire
Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 13/05/2015 à 10:03
"s’il n’est pas disposé à prendre en charge certaines situations incertaines, alors il serait difficile pour lui de faire de l’Agile"

Celle-là est mignonne. Une situation incertaine est une situation qui peut potentiellement déboucher sur un échec, parce que nous ne sommes pas dans une superproduction hollywoodienne, où quand le héros saute dans le vide, il trouve toujours un truc pour se raccrocher. Prendre ou non le risque va donc dépendre d'abord et avant tout des conséquences d'un échec sur la personne qui a pris ce risque.

Quand Apple a sorti MobileMe en 2008, le logiciel était clairement inachevé. Ce qui veut dire que quelqu'un a accepté de prendre le risque de créer ce logiciel dans un délai trop court. Le résultat ? Un licenciement par Steve Jobs en personne, devant toute son équipe rassemblée. Le prochain qui accepta un "challenge" de ce genre chez Apple avait vraiment du mérite !
Avatar de mverhaeghe mverhaeghe - Membre habitué https://www.developpez.com
le 13/05/2015 à 10:06
..... mais ce n'est au final que du bon sens.
Entièrement d'accord ! Je suis peut être un peu naïf, mais pour moi ça ne concerne pas que la méthode Agile, mais l'ensemble de la gestion de projet.
Si une équipe, quelque soit la méthodologie projet employé, se retrouve dans un ou plusieurs de ces points, ça va forcément coincer.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 13/05/2015 à 11:01
Citation Envoyé par Traroth2 Voir le message
Quand Apple a sorti MobileMe en 2008, le logiciel était clairement inachevé. Ce qui veut dire que quelqu'un a accepté de prendre le risque de créer ce logiciel dans un délai trop court.
Ou que quelqu'un a sorti le résultat trop tôt.

Le résultat ? Un licenciement par Steve Jobs en personne, devant toute son équipe rassemblée. Le prochain qui accepta un "challenge" de ce genre chez Apple avait vraiment du mérite !
En même temps Jobs était un gros connard arbitraire et sadique et le fait que ce genre d'individu te fasse subir une humiliation publique a davantage à voir avec le fait que c'est un gros connard arbitraire et sadique plutôt qu'avec tes propres manquements et succès.

Pour commencer l'erreur a été de se placer volontairement sous l'autorité de ce genre d'individu.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 13/05/2015 à 11:15
Citation Envoyé par MintWater Voir le message
Dans tous les cas, nous avons une jolie check-list pour déterminer les "person to blame" quand un projet agile foire
Ceci est une parfaite réflexion non agile

Citation Envoyé par Michael Guilloux Voir le message

Un manager qui utilise la peur comme un outil de management et qui blâme l’échec publiquement pourrait garantir avec certitude l’échec du projet agile.


Pour en revenir au topic, ce qui est écrit est assez évident
Personnellement, je préfère me concentrer sur les qualités communes de l'Agile pour tous les profils : communication et coopération
Peu importe le rôle de l'individu dans le projet, s'il possède ces 2 qualités, il sera possible de faire de l'Agile avec
Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 13/05/2015 à 11:22
Citation Envoyé par DonQuiche Voir le message
Ou que quelqu'un a sorti le résultat trop tôt.

En même temps Jobs était un gros connard arbitraire et sadique et le fait que ce genre d'individu te fasse subir une humiliation publique a davantage à voir avec le fait que c'est un gros connard arbitraire et sadique plutôt qu'avec tes propres manquements et succès.

Pour commencer l'erreur a été de se placer volontairement sous l'autorité de ce genre d'individu.
Là n'est pas la question. Le fait est que dans l'environnement Apple de l'époque, accepter de prendre un risque nécessitait un grand courage ou une bonne dose d'inconscience.
Avatar de RyzenOC RyzenOC - Inactif https://www.developpez.com
le 13/05/2015 à 11:23
En gros personne ne fait de l'agile

Chez les développeurs par exemple, il est important de surveiller l’excès de perfectionnisme. Un développeur qui a tendance à faire de la sur-qualité n’est pas le plus approprié pour un projet agile. Il faut également veiller à ce que ce dernier ne soit pas trop axé sur l’architecture et la longévité du logiciel.

Le développeur agile est également quelqu’un qui n’a pas peur des critiques et qui peut donc explorer d’autres pistes pour apporter une valeur ajoutée au projet, explique le billet.

Un programmeur qui est plus enclin à « coder d’abord et poser des questions plus tard » peut également compromettre le projet agile. Un développeur agile doit plutôt poser le plus de questions dès le début pour avoir une vision claire et nette du chemin à suivre. Cela permettra d’éviter de refaire à nouveau tout le travail.

Il doit encore fait preuve d’une capacité d’écoute et avoir de bonnes compétences en communication. Un développeur qui présente des insuffisances en gestion de projet ou qui n’a aucune notion de management serait également un fardeau pour l’équipe agile.

Mais le genre de développeur qu’il faudrait par-dessus tout éviter, serait probablement celui qui déteste ou qui n’a aucune empathie pour les utilisateurs. C’est exactement le genre de développeur qui ne voit pas l’importance d’associer les utilisateurs dans les projets et qui considère ces derniers comme un obstacle à l’avancement du projet.
dsl, mais sa n'existe pas

Quand bien meme toute l'équipe de dev aurait toutes ces qualités, je doutes que le reste suive, les utilisateurs, manager et co.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 13/05/2015 à 11:34
Citation Envoyé par Traroth2 Voir le message
Là n'est pas la question. Le fait est que dans l'environnement Apple de l'époque, accepter de prendre un risque nécessitait un grand courage ou une bonne dose d'inconscience.
Non, justement, l'erreur est de croire que le licenciement est quand même lié à une insuffisance de l'employé.

Quand tu bosses pour un CAS (connard arbitraire et sadique), tu peux ne prendre aucun risque et être le meilleur employé au monde tu pourras quand même te faire virer. Simplement parce que ce jour-là monsieur avait ses règles ou parce que tu es respecté de tes collègues et que ça le fout en rogne, ou parce qu'il doute de ta soumission aveugle et totale, ou parce qu'humilier les autres le fait bander.

Ce jour-là le chef de la secte a ordonné à #454678 de s'auto-incinérer parce qu'il avait échoué à lever une montagne. Ce n'est pas la faute de #454678. Même si ses collègues en sont convaincus.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 13/05/2015 à 11:49
Citation Envoyé par sazearte Voir le message
En gros personne ne fait de l'agile

dsl, mais sa n'existe pas

Quand bien meme toute l'équipe de dev aurait toutes ces qualités, je doutes que le reste suive, les utilisateurs, manager et co.
L'article énumère les défauts et non les qualités

Et au passage, l'Agile est possible, en tout cas dans une certaine mesure (car le Manifeste est un peu extrême, avouons le)
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web