IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

142PARTAGES

5  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de 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 !
3  0 
Avatar de Traroth2
Membre émérite 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 !
3  1 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 13/05/2015 à 11:51
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.
Citation Envoyé par Traroth2
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é
2  0 
Avatar de HelpmeMM
Membre éprouvé https://www.developpez.com
Le 13/05/2015 à 12:04
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"
2  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 13/05/2015 à 12:16
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.
2  0 
Avatar de 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
2  1 
Avatar de 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.
1  0 
Avatar de 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.
1  0 
Avatar de Théolude
Membre habitué https://www.developpez.com
Le 21/05/2015 à 12:26
... ça me laisse pantois !!!

Et si la vraie équipe Agile était celle qui savait justement amener tout le monde à suivre ses pratiques, ou pour le moins à ne pas les contrecarrer ?
Cette litanie des insuffisants, incompétents et pénibles potentiels n'a pas de sens et je la trouve très "fascisante", dans n'importe quel projet réel il y aura toute sorte de personne qui rentreront dans cette catégorie, sans qu'il soit nécessaire de les carboniser !!
Le premier levier d'un projet et son management, sa plus grande qualité est sa capacité à faire avec son environnement (et non pas contre à grand coup d'exclusion, de mise à l'index, de coercition, ou que sais je encore).
1  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 21/05/2015 à 19:05
Citation Envoyé par Laurent 1973 Voir le message
Les profiles que l'on nous présente me semble aussi regorger de grandes compétences.
Il ne faut pas chercher à les exclure, on a tous nos petits défauts, mais au contraire les aider à progresser pour que ces défauts puisse aussi se transformer en force pour les projets et les équipes.
Il n'est pas question du "savoir faire" mais de "savoir être"
Le "savoir faire" peut s'acquérir avec de la bonne volonté mais le "savoir être", c'est tout autre chose.
Il est possible de corriger quelques détails à la marge mais la nature revient souvent au galop.

Il ne faut pas oublier que l'Agile est une méthode pour mener un projet à terme, ce n'est pas une thérapie de groupe.
Il y a des jalons à tenir et des livrables à restituer.
Les efforts de l'équipe doivent être orientés vers la réalisation du projet et l'entraide sur les points de comportement d'un membre ne doit pas mobiliser l'attention au détriment du projet.

Tout le monde n'est pas fait pour travailler en Agile.
Cela n'en fait pas du tout de mauvais développeur, loin de là.
Ils sont juste plus à l'aise avec un management plus directif.
Ce n'est pas du tout un jugement, c'est une reconnaissance du tempérament de chacun.

L'Agile n'est pas le but ultime à atteindre qui permet de différencier les "bons" des "mauvais".
C'est une méthode de travail parmi d'autres qui a ses qualités et ses défauts.
1  0