Traduction

1. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
Pourquoi ne pas utiliser systématiquement
les méthodes agiles ? Eh bien, même si
cela peut vous choquer ou vous horrifier,
peut-être qu'elles ne sont pas toujours la
meilleure approche en toutes
circonstances ! Alors, comment pouvons-
nous décider quand les utiliser ?
Il est tentant de penser que tous les projets
doivent être gérés selon une démarche
agile. Il est vrai que je suis convaincu que
tous les projets bénéficieraient de
l'encouragement à l'amélioration de la
collaboration et de la communication
spécifiques à l'approche agile.
Néanmoins, la collaboration et la communication ne représentent que deux caractéristiques des
projets agiles et nous devons prendre en considération des paramètres plus larges qui influencent
le succès ou l'échec d'un projet.
Mon hypothèse est que le résultat final que nous recherchons est un projet réussi avec des parties
prenantes satisfaites. Il est donc préférable d'avoir un projet réussi et mené selon une démarche
traditionnelle plutôt qu'un projet raté mené selon une démarche agile. Certains ne seront pas
d'accord mais je les qualifierais de puristes plutôt que de pragmatiques.
Les choix possibles sont A) l'utilisation d'un progiciel qui peut éventuellement exiger le
développement d'un spécifique et son intégration, B) la conduite du projet selon une démarche
traditionnelle (cycle en V en une seule passe) ou C) la conduite du projet selon une démarche
agile.
Alors, comment pouvons-nous identifier et évaluer les caractéristiques de la "forme" d'un projet ? Il
existe heureusement une multitude de recherches fructueuses sur le sujet et dont on peut tirer
parti. Cet article décrit certains des outils les plus populaires et certains autres moins connus en
termes d'estimation de la compatibilité d'un projet avec l'agile :
1. Le curseur
2. Les critères de compatibilité d'un projet selon DSDM
3. La criticité du projet et la taille de l'équipe selon Alistair Cockburn
4. Le radar de Boehm et Turner
5. Les critères agiles selon Dave Cohen
6. Les critères de compatibilité d'une organisation
7. La méthode du marteau
Traduction de Fabrice Aimetti, le 05/01/2011 1/14

2. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
1. Le curseur
Le curseur est un modèle simple que j'ai créé pour illustrer le fait que le choix d'une démarche
agile ou traditionnelle n'est pas nécessairement binaire.
Le modèle est conçu comme une vieille commande de contrôle du chauffage d'une voiture :
• curseur à gauche : pas d'agile du tout,
• curseur entre les deux : un mélange avec de l'agile,
• curseur à droite : à fond agile.
Les caractéristiques qui tireront le curseur dans un sens ou l'autre sont représentées par des
poids :
• Stabilité du projet
• Risque technique faible
• Inertie au changement
• Criticité du projet
• Projet incertain
• Réactivité du client
• Culture de l'innovation
• Colocalisation possible des équipes
Certaines caractéristiques d'un projet telles que des "exigences non stabilisées" et des "utilisateurs
qui demandent tout le temps de nouvelles choses" sont en faveur d'une démarche agile et tireront
le curseur vers la droite. D'autres caractéristiques telles que "des exigences stabilisées" et "l'inertie
au changement" rendront la justification d'une démarche agile plus problématique et seront plutôt
en faveur d'une démarche plus traditionnelle.
Les approches traditionnelle et agile peuvent être combinées avec succès sur des projets
hybrides ou difficile à catégoriser. "Vous pouvez utiliser l'agile à fond de temps en temps et un peu
d'agile tout le temps."
Traduction de Fabrice Aimetti, le 05/01/2011 2/14

3. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
2. Les critères de compatibilité d'un projet selon DSDM
J'ai eu la chance d'être impliqué dans la création de DSDM1
en 1994 et je me suis donc rappelé
les débuts de l'utilisation du Questionnaire sur les critères de compatibilité d'un projet. Il était alors
assez primitif et a subsisté sous la forme d'une simple liste de questions auxquelles il fallait
répondre par Oui ou par Non. L'idée de base est de vérifier si les caractéristiques du projet sont en
faveur d'un développement agile, telles que :
1. Accord sur la philosophie agile avant de commencer à travailler : timeboxing, implication
des utilisateurs, développement itératif, ...
2. Accord sur la délégation du pouvoir de décision aux utilisateurs et développeurs
embarquées dans l'équipe.
3. Engagement du management client pour assurer la disponibilité et la participation
importante de certains utilisateurs finaux.
4. Livraison incrémentale : accord sur le fait que c'est acceptable et souhaitable.
5. Facilité d'accès des développeurs aux utilisateurs finaux et clients sur site.
6. Stabilité de l'équipe : conserver une équipe minimale pour maintenir la connaissance tacite
plutôt que d'exiger de la documentation.
7. Compétences en développement de l'équipe : disposer d'une équipe qualifiée et qui
communique.
8. Taille de l'équipe de développement : de petites équipes pour privilégier les discussions en
face à face et minimiser les coûts de communication et de documentation.
9. Soutien actif des commerciaux : la confiance et la collaboration sont plus importants que la
négociation d'un contrat.
10. Technologie utilisée pour le développement : permet la livraison incrémentale, le
prototypage rapide et le refactoring.
La présence ou l'absence de ces caractéristiques fournissent une très bonne indication sur la
probable adhésion à l'application d'une démarche agile. Des réponses négatives ne signifieront
pas automatiquement que l'agile ne fonctionnera pas, elles mettent plutôt en évidence les risques
potentiels qui devront être gérés. Par exemple, si l'on répond "Non" sur "la disponibilité des
utilisateurs", cela signifiera peut-être que nous avons un risque de faible disponibilité et qu'il faudra
le traiter au démarrage du projet pour essayer de garantir cette disponibilité. Par contre si l'on
répond "Non" à la plupart des questions, une alerte est levée quant à l'emploi d'une démarche
agile. Avec de telles limitations, cela devient rédhibitoire pour le succès du projet.
Vous pouvez télécharger une copie du Questionnaire sur les critères de compatibilité DSDM en
passant par le lien ci-dessous. Répondre à ces questions peut vous fournir des informations
précieuses sur l'emploi de tout type de méthodologie agile.
Télécharger project_suitability_questionnaire.doc
1 DSDM : Dynamic Systems Development Method
Traduction de Fabrice Aimetti, le 05/01/2011 3/14

4. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
3. La criticité du projet et la taille de l'équipe selon Alistair
Cockburn
Les méthodes Crystal créées par Alistair Cockburn sont basées sur la criticité du système et la
taille de l'équipe. Alistair a divisé ses méthodes comme indiqué ci-dessous.
En abscisse, nous trouvons la taille des équipes en commençant à partir de très petites équipes de
1 à 4 personnes pour aller vers des grands projets de plus de 500 personnes. En ordonnée, nous
trouvons la criticité du système exprimée sous la forme des risques encourus. Si un jeu ou un
traitement de texte se bloque alors nous perdons un peu de temps. Si un système de facturation
tombe alors on peut subir des pertes financières substantielles.
Nous pouvons voir que Crystal Clear est une méthodologie agile conçue pour de petites équipes
gérant des projets dont la défaillance du système n'entraînerait que des pertes financières
maîtrisées. La méthode Crystal Red, par contre, impose plus de rigueur et de contrôle et est
destiné aux équipes de 50 à 100 personnes travaillant sur des systèmes dont la défaillance peut
entraîner des pertes financières importantes.
Prendre en compte la taille de l'équipe et la criticité du projet est un bon moyen d'évaluer la
compatibilité du projet avec la démarche agile. Les méthodes agiles ont eu de bons résultats sur
des projets mettant en jeu de grandes équipes voire même sur des systèmes dits très critiques,
mais cela exige beaucoup plus de compétences et d'efforts. Elles sont beaucoup plus faciles à
mettre en œuvre sur de petites applications non critiques.
Traduction de Fabrice Aimetti, le 05/01/2011 4/14

5. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
4. Le radar de Boehm et Turner
Dans leur livre "Balancing Agility and Discipline: A Guide for the Perplexed" (un très bon livre mais
avec un mauvais titre puisque l'agile est discipliné), Barry Boehm et Richard Turner ont trouvé une
manière assez sympatique pour représenter visuellement l'évaluation des caractéristiques d'un
projet qui, selon eux, le rende compatible avec la démarche agile.
L'idée est que le projet est évalué en fonction de cinq caractéristiques et les scores sont reportés
sur le radar. Les scores proches du centre indiquent une bonne compatibilité avec la démarche
agile, alors que les scores éloignés du centre indiquent une meilleure compatibilité avec l'approche
traditionnelle. Les caractéristiques mesurées sont :
Personnel : mesure la compétence des développeurs de l'équipe selon une échelle empruntée à
Alistair Cockburn : Niveau 1 (débutant), Niveau 2 (intermédiaire) et Niveau 3 (expert). Pour que
les projets agiles se passe bien, il est préférable d'avoir une faible proportion de développeurs
débutants et une forte proportion de développeurs de niveaux intermédiaire et expert. Si votre
équipe a un pourcentage plus élevé de débutants (et donc un faible pourcentage de développeurs
plus expérimentés), alors peut-être qu'une approche plus traditionnelle (codage à partir des
spécifications) serait plus facile.
Dynamisme : c'est un terme qui évalue la probabilité des changements. Le projet est-il dynamique
(soumis à des changements), quel est le pourcentage des exigences qui sont susceptibles de
changer au cours du projet ? Si 50% des exigences sont susceptibles de changer alors nous
sommes très proche du centre du graphique dans la zone agile. Si seulement 1% des exigences
sont susceptibles de changer alors nous sommes sur le bord extérieur du graphique dans la zone
traditionnelle. Cela ne veut pas dire que vous ne pouvez pas utiliser une approche agile, mais
peut-être (pour cette caractéristique tout au moins) que planifier le travail puis suivre le planning
fonctionnera mieux sur ce projet.
Culture (chaos vs ordre) : quel est le profil de l'organisation ? Est-ce une organisation qui accueille
facilement voire se nourrit du changement, ou est-ce une organisation reposant sur l'ordre et la
tradition. Vendre l'agile dans un environnement très ordonné peut être difficile avec des idées
Traduction de Fabrice Aimetti, le 05/01/2011 5/14

6. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
telles que les exigences émergentes, les équipes auto-organisées et le leadership-serviteur qui
apparaissent contradictoires par rapport à la culture et les valeurs de l'organisation. Cela peut
encore être réalisé en faisant appel à leur désir de réduire l'incertitude du projet.
Les deux prochaines caractéristiques "Taille de l'équipe" et "Criticité" de Boehm et Turner sont en
fait tirées des méthodes Crystal de Alistair Cockburn.
Taille de l'équipe : les méthodes agiles sont plus faciles à mettre en place, à exécuter et à gérer
avec de petites équipes. Cela ne veut pas dire que les grandes équipes agiles ne peuvent pas
travailler correctement, mais que c'est beaucoup plus difficile à accomplir. Des équipes de moins
de 10 personnes constituent une bonne dimension pour l'agile étant donné que ce nombre est plus
facile à colocaliser, ils peuvent communiquer en face-à-face, ils peuvent gérer des connaissances
informelles (tacites) par le biais des conversations et utiliser des systèmes de suivi très simples et
visuels. Au fur et à mesure que la taille des équipes croît, conserver ces principes agiles requièrent
des techniques supplémentaires pour dimensionner de manière efficace. Cela peut être fait, mais
cela demande plus de travail et de compétence. En revanche, les structures hiérarchiques des
projets traditionnels ont été faites pour gérer des équipes de grande dimension en se basant sur la
prolifération naturelle des comités, de la documentation et des organisations matricielles.
Criticité (la défaillance du système a pour conséquence la perte de ...) : il s'agit de la
caractéristique la plus controversée. Boehm et Turner se sont basés sur le modèle de Alistair
Cockburn et ont affirmé que l'agile est plus approprié pour les applications légères où la
défaillance du système conduit à une perte de confort (comme perdre du temps lorsqu'un jeu se
bloque ou perdre ses modifications lorsque le traitement de texte se plante), mais moins
appropriées pour des applications critiques.
Je peux comprendre d'où cela vient, après avoir travaillé sur des projets militaires ; il y a toujours
une traçabilité forte des tests par rapport aux exigences et des exigences par rapport aux
spécifications qui peuvent être automatiquement vérifiées et dans les deux sens. Les frameworks
de tests agiles récents peuvent fournir de telles fonctionnalités mais de nombreuses approches
agiles ne prescrivent pas ce niveau de détail. Cependant, cela ne veut pas dire que cela ne peut
pas être ajouté, et je recommande une approche itérative agile pour s'attaquer à l'architecture et
tester des fonctionnalités significatives tôt et souvent sur des projets qui consistent à construire
des applications critiques. Commencez par l'agile et ajouter les couches de vérification
supplémentaires exigées par la criticité du système.
Pour illustrer la façon dont le radar est utilisé, je montre l'exemple d'un projet de pharmacie en
ligne que j'ai géré lorsque je travaillais chez Quadrus développement.
Le projet consistait à développer une pharmacie en ligne pour vendre à bas prix des médicaments
canadiens sur ordonnance (principalement) pour des clients américains. La vente de ces
médicaments est un sujet controversé au Canada ainsi qu'aux États-Unis et par conséquent cette
industrie est caractérisée par des changements rapides de la réglementation et une concurrence
féroce. Nous avons donc été confrontés à une extrême volatilité des exigences avec des
changements majeurs semaine après semaine. Nous avons utilisé des itérations très courtes (2
jours) et des livraisons hebdomadaires pour contrecarrer cette fréquence élevée des
changements.
Traduction de Fabrice Aimetti, le 05/01/2011 6/14

7. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
Comme le montre le diagramme, nous avions une équipe expérimentée de développeurs de
niveaux 2 et 3 qui ont travaillé sur des exigences très "dynamiques" avec une culture du
changement élevée, proche du chaos. La taille de l'équipe était petite (5 personnes), mais la
criticité du système assez élevée avec un impact financier fort pour la pharmacie. L'approche a été
très fructueuse et très agile.
Ce qui contraste avec le projet suivant sur lequel j'ai travaillé lorsque j'étais chez IBM Global
Services. C'était un système de messagerie militaire qui fonctionnait depuis déjà 5 ans lorsque j'ai
rejoint l'équipe.
Il y avait des niveaux de compétence assez variés, des exigences verrouillées parce que tout
changement pouvait impacter de nombreux sous-traitants, et la culture était basée sur les
spécifications et le contrôle. Le projet était énorme avec plus de 300 personnes provenant
uniquement d'IBM et la criticité était élevée puisque des informations vitales pouvaient être
Traduction de Fabrice Aimetti, le 05/01/2011 7/14

8. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
transmises. Certaines parties du projet aurait pu être séparées et menées sous forme de projets
agiles, mais la prise d'initiative était difficile au sein de ce monstre monolithique.
Réflexions sur le modèle de Boehm et Turner
De temps en temps, je donne un cours de gestion de projet agile pour l'Université de Calgary et
l'un des exercices que nous faisons est d'essayer d'ajouter des axes supplémentaires au radar. En
d'autres termes, de quels autres facteurs devez-vous tenir compte pour déterminer si le projet est
ou non compatible avec une démarche agile. Une réponse fréquente est "l'Effort de Tests" : si
tester un incrément est coûteux en termes d'effort ou de temps alors vous n'avez probablement
pas les moyens de le faire très souvent. Ou alors vous devez trouver d'autres moyens pour simuler
les tests. Les constructeurs automobiles font des milliers d'essais de collision à partir d'une
conception itérative du véhicule et en utilisant des simulations sur ordinateur plutôt que des tests
sur des véhicules réels. Donc si le test est coûteux en temps ou en effort, nous devons également
trouver un moyen de le rendre plus facile (via des bouchons et des outils de tests automatisés).
Traduction de Fabrice Aimetti, le 05/01/2011 8/14

9. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
5. Les critères agiles selon Dave Cohen
En 2004, Cohen, Lindvall et Costa ont publié une bonne introduction à l'agile dans "Advances in
Computers". Ils ont identifié les critères suivants déterminants dans l'adoption d'une démarche
agile :
1. La culture de l'organisation doit être favorable à la négociation.
2. Les personnes doivent se faire confiance.
3. Peu de personnes, mais très compétentes.
4. Les organisations doivent vivre avec les décisions prises par les développeurs.
5. Les organisations doivent avoir un environnement qui facilite la communication rapide
entre les membres de l'équipe.
Le point 4 peut sembler bizarre et vous pouvez même penser que c'est le métier, au final, qui doit
diriger le développement. Toutefois, lorsque vous lisez l'article, on parle du fait qu'il est nécessaire
de faire confiance aux développeurs compétents et de leur laisser prendre des décisions sur la
conception plutôt que sur les fonctionnalités métiers.
Il s'agit de bons critères et j'apprécie le fait que les facteurs organisationnels aient un poids plus
important dans l'évaluation. Parce que c'est là que je ressens le plus d'influence ou de résistance.
Nous pouvons examiner le projet dans son coin et penser qu'il s'agit d'un excellent candidat pour
l'agile, mais si l'organisation a une culture différente ou des directives opposées, alors nous
passons à côté d'une pièce importante du puzzle.
Traduction de Fabrice Aimetti, le 05/01/2011 9/14

10. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
6. Les critères de compatibilité d'une organisation
Le Consortium DSDM a publié, sous la forme d'un livre blanc, un questionnaire sur les critères de
Compatibilité d'une Organisation. Ce questionnaire va de pair avec le Questionnaire sur les
critères de compatibilité d'un Projet (vu précédemment). Malheureusement, le livre blanc n'a pas
eu le même succès, ce qui est dommage car il fournit des indications utiles sur la façon dont une
organisation doit se structurer lorsqu'elle adopte des pratiques agiles.
Le questionnaire comprend 46 questions réparties dans les catégories suivantes. J'ai listé les
catégories et reformulé l'essentiel des questions ci-dessous :
1. Utilisateurs : avons-nous les bons utilisateurs ? savent-ils de quoi ils parlent ? et peuvent-ils
prendre des décisions ?
2. Gestion des utilisateurs : comprennent-ils le développement itératif ? vont-ils garantir la
disponibilité des personnes ? ont-ils confiance dans ces personnes et vont-ils leur déléguer la prise
des décisions au nom du groupe ?
3. Organisation : est-ce que la technologie informatique lui est familière ? est-elle prête à accepter
un contrat agile ?
4. Culture : y a-t-il une culture d'ouverture ? les gens sont-ils prêts à essayer de nouvelles
approches ? et une première solution réalisée à 80% est-elle acceptable ?
5. Equipe informatique : connaît-elle suffisamment la démarche agile ? peut-elle parler
efficacement aux utilisateurs ? quelle niveau de relation entretient-elle avec la communauté des
utilisateurs ?
6. Management informatique : comprend-il les méthodes agiles ? sont-ils prêts à modifier leurs
normes et standards en termes de gestion de projet ?
7. Management de l'organisation : est-il procédurier ? les parties prenantes seront-elles
disponibles pour participer au projet ? le métier est-il demandeur pour avoir des livraisons
incrémentales ?
8. Technique : y a-t-il un fort historique d'utilisation du cycle en V ? et des outils de builds et de
tests sont-ils disponibles pour appuyer l'environnement technique ?
Je n'ai pas vraiment fait le questionnaire; il offre un bon aperçu des probables risques liés à
l'adoption d'une démarche agile et vous n'en aurez que pour 45 minutes environ. Vous pouvez
télécharger une copie ici :
Télécharger organizational_suitability_questionnaire.doc
Une fois que vous aurez rempli le questionnaire, vous pourrez utiliser la feuille de calcul
d'évaluation ci-jointe pour vous aider à interpréter les résultats.
Télécharger osf_assessment_scoring_example.xls
Traduction de Fabrice Aimetti, le 05/01/2011 10/14

11. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
Dans le radar ci-dessus, on peut voir un exemple de réponse au questionnaire. Le graphique
montre bien les niveaux de risque, plus le score est élevé, plus le risque est important : ici c'est le
cas pour la Gestion des utilisateurs et la Culture où le risque est très élevé.
A l'image des critères de compatibilité d'un projet, les scores élevés ne signifient pas
automatiquement que vous ne pouvez pas utiliser une approche agile. Au contraire, ils identifient
les zones à risque qui doivent être examinées, comprises et réduites. En apprendre plus sur ces
zones à risque est une bonne chose parce que nous pouvons être proactif pour diminuer ces
risques ("un homme averti en vaut deux").
Traduction de Fabrice Aimetti, le 05/01/2011 11/14

12. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
7. La méthode du marteau : facteurs non liés au projet
Ces facteurs organisationnels sont critiques, même si le projet est en théorie idéal pour la
démarche agile. Si le management ou les autres parties prenantes sont contre cette approche,
alors l'application de la démarche agile comporte un risque important. En outre, si le chef de projet
croit que les méthodes agiles ne fonctionne tout simplement pas, alors je suis convaincu qu'il
réussira à prouver qu'il a raison et qu'il échouera dans l'utilisation de la démarche agile. Si votre
cœur n'y est pas, alors les obstacles du projet apparaîtront comme une justification de la
faiblesse du processus, et non comme des défis à surmonter.
C'est ce que j'appelle "Les préjugés sur la méthodologie" et je pense que c'est le facteur le plus
important à évaluer. Si vous voulez, on pourrait appeler ça "Adhésion à la méthodologie", mais
cela cache le côté inconscient du préjugé qui influence nos décisions inconsciemment. Par
exemple, personnellement, je suis par nature pro-agile et j'emploierai les principes agiles sur
différents types de projets sans grande variation. C'est juste mon approche, j'aime construire
progressivement la collaboration et le consensus et j'ai une grande "tolérance aux fautes".
Je visualise "Les préjugés sur la méthodologie" sous la forme du marteau que nous utilisons pour
faire rentrer nos projets dans la méthode de notre choix.
Si une équipe a un fort désir de réussir avec l'approche agile (ou une autre), elle va probablement
trouver des moyens inventifs pour faire fonctionner la méthode. Nous pouvons utiliser des outils
tels que le radar de Boehm et Turner afin de déterminer les caractéristiques idéales d'un projet
agile, mais nous ne devons jamais sous-estimer nos préjugés et notre obstination qui feront que
notre marteau pourra rendre les projets les plus improbables compatibles avec une démarche
agile.
Dans le schéma ci-dessus, le projet A semble un bon choix pour notre marteau Agile, sans trop de
modification, cela devrait être un projet agile assez facilement. Il semble que le projet B puisse
Traduction de Fabrice Aimetti, le 05/01/2011 12/14

13. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
mieux être traité avec une approche traditionnelle. Le projet C est plus problématique, il inclut un
composant progiciel et le reste pourrait être mené selon une démarche traditionnelle ou agile.
Bienvenue dans le monde réel, les choses sont compliquées ; peut-être qu'une approche hybride
est nécessaire ici avec la mise en œuvre du progiciel et le développement traités en parallèle.
Le Projet D semble comporter une partie traditionnelle et une partie agile ; peut-être pouvons-nous
diviser cela en deux sous-projets et les gérer de cette manière ? Il s'agit d'une approche valable
qui est souvent négligé. Sinon, nous pouvons utiliser notre marteau favori et taper dessus
jusqu'à ce que nous nous convainquions nous-mêmes et les autres que le projet est
compatible avec notre méthode préférée.
Traduction de Fabrice Aimetti, le 05/01/2011 13/14

14. Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
Parmi tous ces critères de compatibilité, lesquels utiliser ?
Eh bien, ce ne serait pas très adaptatif ou agile d'imposer une approche unique ou un parcours
d'utilisation unique des différents modèles. Au lieu de cela, je vous suggère de vous familiariser
avec une variété d'entre eux, puis de sélectionner ceux que vous pensez les plus adaptés à votre
environnement.
Soyez tout de même bien conscient que la compatibilité théorique et la compatibilité pratique sont
souvent très différentes. Apprenez à reconnaître la présence du marteau et apprenez à
comprendre la façon dont il influe sur vos choix et donc sur votre réussite. Enfin, n'oubliez pas que
ce ne sont que des outils et qu'ils ne remplaceront pas votre réflexion et votre dialogue avec les
parties prenantes du projet. Plutôt que de les utiliser à part, utilisez-les pour démarrer des
conversations sur la compatibilité avec une démarche agile et bâtissez un consensus autour de la
méthode permettant de faire le bon choix.
.
Traduction de Fabrice Aimetti, le 05/01/2011 14/14