Discussion :

[Michael Guilloux]

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

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 ?

[dfiad77pro]

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 !

[MintWater]

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

[Traroth2]

"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 !

[mverhaeghe]

..... 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.

[DonQuiche]

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.

[Saverok]

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

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

[Traroth2]

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.

[RyzenOC]

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.

[DonQuiche]

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.

[Saverok]

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)

[Laurent 1973]

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.

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 !

Donc, Steve Job n'était pas fait pour l'agilité

[HelpmeMM]

Ce qui est bien avec cette "Etudes" concernant l'agile c'est qu'avec un projet non agile , elles fonctionnent aussi !!!! étonnant non ?

n programmeur qui est plus enclin à « coder d’abord et poser des questions plus tard » peut également compromettre le projet agile

Tu prend toutes ces remarques tu vires agile et sa marche aussi avec un projet classique au passage.

c'est banalité sur banalité , si ton codeur n'aime pas coder c'est le genre de codeur qui peut faire planté ton projet 'Agile"...
Si ton codeur va coder dans une équipe et qu'il n'aime pas travailler en équipe sa va faire capoter ton projet 'Agile"

[Laurent 1973]

Je reviens sur le débat de cet article.

L'important est de se rappeler la définition de l'Agilité.
Pour moi, je me réfère à l'Agile Manifesto (http://agilemanifesto.org): Une équipe est agile si elle applique les 10 principes dans l'esprit des 4 valeurs.

Dans cet article, on identifie les individues qui seraient un frein à cela.
Je pense que l'agilité repose justement sur le fait que nous sommes une équipe, embarquée dans la même aventure et que malgré les défauts de chacun, il faut trouver une solution pour avancer dans le bon sens.

Par exemple:
- un développeur qui serait trop axé sur l’architecture et la longévité du logiciel (=> principe 10 "simplicité") devrait être aider par les autres développeurs pour relativiser son défaut.
- un utilisateur impliqué qui ne s’impliquerait pas assez (=> principe 4 "les utilisateurs") doit manqué de temps de son management ou n'a pas eu la démarche d'accompagnement pour entretenir sa motivation sur le projet.
- un manager qui utilise la peur comme un outil de management (=> principe 5 "personnes motivées") n'a pas été correctement coacher pour comprendre les leviers de motivations des équipes.
- un consultant qui n’est pas disposé à venir sur le site du client (=> principe 1 "satisfaire le client") a eu un manque de formation agile sur le lien client-équipe.

J'aime pas trop cette article dans le sens où on part à une sorte de chasse aux sorcières des anti-agile (sous entendu, qui faut viré), au lieu de trouver des solutions pour enlever tout ces petits grains de sable que chacun peu apporter dans un projet et qui a tendance à le rendre moins agile.

Pourquoi pas entamer cette jolie réflexion en rétrospective (=> principe 12 "moyens de devenir plus efficace") pour aider toutes personnes partie prenantes dans un tel projet d'être de plus en plus agile.

[RyzenOC]

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)

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)

Ce que je veut dire c'est que les méthodes agiles ne sont pas inscrit dans un bouquin, y'a une grosse d'adaptation en fonction du milieu.
Si un développeur a 1 ou 2 défaut cité, c'et pas la fin du monde.

[Traroth2]

Non, justement, l'erreur est de croire que le licenciement est quand même lié à une insuffisance de l'employé.

Je ne vois pas à quel endroit j'aurais dit quelque chose de ce genre.

[DonQuiche]

Je ne vois pas à quel endroit j'aurais dit quelque chose de ce genre.

Tu considères que le problème est lié à la perception du risque et de l'échec dans cette entreprise.
Or cela n'a à voir ni avec le risque, ni avec l'échec, ni avec le succès.

[Invité]

Ce qui est bien avec cette "Etudes" concernant l'agile c'est qu'avec un projet non agile , elles fonctionnent aussi !!!! étonnant non ?



Tu prend toutes ces remarques tu vires agile et sa marche aussi avec un projet classique au passage.

c'est banalité sur banalité , si ton codeur n'aime pas coder c'est le genre de codeur qui peut faire planté ton projet 'Agile"...
Si ton codeur va coder dans une équipe et qu'il n'aime pas travailler en équipe sa va faire capoter ton projet 'Agile"

Tout pareil, je pensais remplacer le mot "Agile" par "Suspect" ou "Clavier orthogonal". Les phrases se tiennent encore.

[Traroth2]

Tu considères que le problème est lié à la perception du risque et de l'échec dans cette entreprise.
Or cela n'a à voir ni avec le risque, ni avec l'échec, ni avec le succès.

Bien sûr que si. MobileMe a bel et bien échoué. Le succès et l'échec ne sont pas nécessairement lié à la compétence personnelle. Ils sont issus d'un contexte global, dont la compétence est un paramètre, mais pas le seul. Le bon fonctionnement hiérarchique en est un autre. La prise de risque, c'est à dire la décision d'accepter ou pas de diriger un projet, a lieu dans ce contexte.

[CodeurPlusPlus]

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.

Une intervention à la sazearte, avec ton manque de nuance habituel...

Je rejoins par ailleurs ceux (et celles ?) qui ont dit qu'on peut supprimer le mot "agile" de l'article.

Cela me conforte dans l'idée que "agile" n'est qu'un buzz word ; n'importe qui impliqué dans n'importe quel projet professionnel doit être souple et réactif, pas la peine d'en faire une religion genre "ceux qui en sont" et "ceux qui restent dehors".

Non, moi non plus je ne suis pas toujours nuancé dans mes propos

Mais il y a plus grave : je ne suis pas forcément d'accord sur certains points de l'article... c'est sans doute pour cela que je suis informaticien au chômage. (et prof pas au chômage en même temps, mais c'est bizarre parce que quand on enseigne il faut aussi être "agile" à fond)

EDIT / PS : on dirait que le(s) auteur(s) de l'article ont bien souffert de leur expérience du travail en équipe pour écrire ce qu'ils ont écrit ! Je compatis.