Les moyens d'abord, les résultats après

De Wiki Agile
Aller à : navigation, rechercher

Auteur : Stavros Stavru
Source : Means First, Then States (TastyCupcakes.org)
Date : 03/02/2014

Traducteur : Nicolas Brunot (@Nicolasbrunot)
Date : 17/03/2014

Traduction :

Ce jeu introduit et illustre le syndrome « les moyens d’abord, les résultats après » et l’impact négatif que cela peut avoir sur un projet de développement informatique et son exécution ou son résultat. Il nous amène aussi à débattre sur ce qu’est le succès d’un projet informatique et quels facteurs pourraient y contribuer (incluant une évaluation des valeurs et principes du Manifeste Agile). De plus, il souligne l’importance de l’analyse et de la théorie des parties prenantes.

DUREE
100 minutes (mais cela dépend du nombre d’équipe / des discussions tenues). Chaque partie du jeu est rigoureusement timeboxée.

MATERIEL
Papiers, stylos et chronomètre afin de timeboxer.

INTRODUCTION (5 min)
Répartissez les participants en équipes de 3 à 5 personnes. Distribuez des feuilles et des stylos aux équipes en expliquant les règles du jeu décrites ci-dessous (5 min).

ITERATION 1 (30 min)


Partie 1 (20 min)
Donnez à l’équipe 20 minutes pour préparer une liste de facteurs conduisant, selon eux, au succès des projets informatiques. Les facteurs de succès peuvent concerner tout ce qui est en relation avec les personnes, les processus et les produits (si vous préférez, vous pouvez utiliser les 3P / une vision holistique des organisations).
Exemples de facteurs :

  • Personnes : des caractéristiques individuelles, des compétences, responsabilité, créativité, discipline, etc. ou des caractéristiques de groupes ou d’équipes comme la coopération, le respect, l’engagement, l’autorité, etc. Cela peut aussi être un moyen de cibler sur le fait d’avoir des équipes multi-fonctionnelles, auto-organisées ou tout autre « bonne pratique » connue.
  • Processus : une communication efficace, l’utilisation des ressources, la performance, la flexibilité, etc. Des exemples plus concrets peuvent être la formalisation des processus et des techniques de développement logiciel spécifiques, des politiques organisationnelles et des procédures de travail, l’environnement de travail, etc.
  • Produit : la qualité, l’innovation, la simplicité, etc.


Partie 2 (10 min)

Les équipes ont maintenant une liste de facteurs conduisant, selon eux, au succès des projets informatiques. Questionnez chacune des équipes, afin de savoir si elles ont défini ce qu’est un projet informatique réussi ? Aucune, je suppose.
C’est ce que j’appelle le syndrome « les moyens d’abord, les résultats après » (et même aucun résultat parfois), qui pousse les membres d’une équipe à se concentrer sur les moyens, ressources, méthodologies, « chemins » choisis par eux sans qu’ils aient réfléchi à ce qu’était exactement le résultat / l’état du fini (ou ayant fait des suppositions basées sur leurs expériences précédentes, le comportement de leurs pairs, etc.). Cela rejoint la tendance récurrente de certaines personnes à « agir avant de réfléchir ».
Demandez aux équipes comment elles se sentent. J’ai appelé cela le moment du « AHA » lorsque vous comprenez que vous êtes en train d’essayer d’atteindre un résultat sans en connaître réellement les contours, en faisant des suppositions. Quand l’équipe ressent-elle cette notion de « réussite » au cours du projet ?
Si il y a une équipe, qui au cours de l’itération 1, a défini (avant de lister les facteurs de succès) ce qu’était un projet « réussi », alors l’équipe gagne 10 points.

ITERATION 2 (30 min)


Partie 1 (10 min)
Demandez à chaque équipe de préparer une définition d’un projet informatique réussi (définition du succès, en analogie avec les définitions Scrum du fini et du prêt, etc.). Cela peut être un texte libre, une liste de critères (par exemple la / les valeur(s), la satisfaction du consommateur, la performance de l’organisation, la motivation de l’équipe, etc.), qui se base sur le fameux triptyque / triangle managérial (périmètre, durée, coût) ou quoi que ce soit d’autre.
Cela peut aussi être l’occasion de souligner l’importance de la connaissance partagée, la notion d’agilité (notamment au travers de ses pratiques : XP, la notion d’itération et de sprint, la visibilité et la transparence véhiculée par le Kanban).
Partie 2 (20 min)
Maintenant, demandez aux équipes leur définition du succès / du projet informatique réussi. Puis demandez-leur de faire figurer dans cette définition les intérêts de chacune des parties prenantes du projet (tous ceux qui peuvent être affectés ou pourraient être affectés par le projet, ses résultats ou ses retombées) ?
Est-ce que la définition représente les intérêts du consommateur (/ utilisateur) ? Qu’en est-il des actionnaires ? des employés ?
Vous pouvez utiliser ces questions comme base d’échange afin d’initier une discussion sur l’analyse des parties prenantes et son importance dans la définition de ce qu’est un projet informatique réussi.
Afin de vous aider dans cette analyse, et d’affiner la définition du succès, vous pouvez utiliser cette liste (une liste des clients utilisateurs peut aussi faire l’affaire) :

  • Clients (utilisateurs finaux ou clients, organisations commerciales, gouvernement ou organisation du secteur public, etc.)
  • Partenaires (fournisseurs, souscripteurs, sous-traitants, produits, services, etc.)
  • Actionnaires (propriétaires, investisseurs, etc. ou tout détenteur légal d’une part de l’organisation)
  • Employés (top et middle management, manager fonctionnel / projet, personnel, etc.)
  • Associations (ensemble ou groupe de personnes dans une région spécifique, pays, monde entier, qui pourrait être concernées par l’exécution ou l’organisation du projet et de ses résultats).


Chaque équipe gagne 2 points pour chaque partie prenante sur la liste dont les intérêts sont pris en compte dans leur définition du succès / du projet informatique réussi.

ITERATION 3 (30 min)


Partie 1 (10 min)
Demandez aux équipes de reprendre leurs listes des facteurs de succès et de définir l’impact de ces facteurs sur leur définition du succès / du projet informatique réussi :

  • Direct : annoter en vert (ou avec une étoile)
  • Indirect : annoter en jaune (ou avec un carré)
  • Aucun impact : annoter en blanc (ou avec un cercle)
  • Impact négatif : annoter en rouge (ou avec un triangle)


Une fois cette analyse réalisée, compter vos points en suivant les critères ci-dessous :

  • Vert / Etoile : +2 points
  • Jaune / Carré : +1 point
  • Blanc / Cercle : -1 point
  • Rouge / Triangle : -2 points


Les facteurs marqués en blanc / cercle correspondent aux déchets (muda - les efforts inutiles / gaspillage), alors que les facteurs marqués en rouge / triangle ont une influence négative sur la définition du succès. Avoir des facteurs annotés en blanc et rouge, est une conséquence directe de ce que j’appelle le syndrome « les moyens d’abord, les résultats après » et démontre à quel point les moyens sont inefficaces et inappropriés s’ils ne sont pas en phase avec l’objectif / le résultat désiré.

Partie 2 (20 min)
Afin d’étayer cette première liste de lecture sur leurs résultats, introduisez le Manifeste Agile et l’état d’esprit qui a animé ses rédacteurs. Pour chaque valeur / principe, demandez à l’équipe s’ils peuvent le / la relier avec l’un des facteurs de succès de leur liste.
Si oui, comment est-il annoté - en vert, jaune, blanc ou rouge ?
Si non, demandez-leur s’ils souhaitent l’ajouter à leur liste de facteurs clés.
Comment l’annoteraient-ils ? Cela représente les intérêts de quelles parties prenantes ?
Lorsque l’ensemble des valeurs / principes du Manifeste Agile ont été passées en revue, demandez à l’équipe s’ils aimeraient ajouter de nouvelles valeurs ou principes au Manifeste. Si les facteurs de succès proposés sont acceptés par l’ensemble de l’équipe, l’équipe proposant ce facteur de succès gagne 5 points. Un maximum de 3 propositions par équipe peut être soumis au vote du groupe.

FIN DU JEU (5 min)


Calculez les scores de chaque équipe en faisant la somme des points gagnés et annoncez le vainqueur.
Eléments d’apprentissage :

  • Initiez une discussion sur ce qu’est un succès pour un projet informatique (définition du succès) et quelles facteurs peuvent conduire à ce succès.
  • Introduisez et illustrez le syndrome « les moyens d’abord, l’objectif ensuite » et les effets néfastes que cela peut avoir sur l’exécution du projet et / ou ses résultats (exemple : introduisez la notion de gaspillage / muda). Cela renforce l’importance d’avoir une connaissance partagée de la définition du fini et du succès du projet en alignant l’ensemble des moyens et processus sur cette vision.
  • Introduisez l’analyse / la théorie des parties prenantes et alertez sur le fait que les intérêts des parties prenantes devraient être pris en compte dans la définition du succès.
  • Introduisez le Manifeste Agile comme une liste de facteurs pouvant conduire à la réussite d’un projet informatique.
  • Renforcez la compréhension et les motivations des participants concernant les valeurs et les principes agiles, et démontrez qu’ils sont basés sur des années de pratiques / d’expérience dans le domaine du développement logiciel.



RESUME

  • Faire une liste des facteurs de succès.
  • Définir ce qu’est le succès.
  • Définir l’impact de ces facteurs sur le succès tel que défini (direct, indirect, neutre, négatif).
  • Introduire le Manifeste Agile pour étayer la grille de lecture.


Jeu(x) agile(s) référencé()s : Presto Manifesto

Traduction française mise à disposition sur le site TastyCupcakes.org

Récupérée de « https://wikiagile.fr/index.php?title=Les_moyens_d%27abord,_les_résultats_après&oldid=13246 »