Means First, Then StatesLes moyens d’abord, les résultats après

This exercise introduces and demonstrates the “Means First, Then States Syndrome” and the negative impact it could have on software projects’ execution and/or outcomes. It also drives a meaningful discussion on what success is to software projects and what factors could lead to it (including an evaluation of the values and principles of the agile manifesto). It further emphasizes the importance of stakeholder theory and stakeholder analysis.

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.

Timing
100 mins (but depends on the number of teams / discussions held). Each part of the exercise is strictly timeboxed.

Materials
Papers, pens and timer for timeboxing.

Introduction (5 mins)
Split people into teams of 3 to 5 people. Distribute papers and pens to the teams and explain the rules of the exercise described below (5 mins)

ROUND I (30 mins)

Part I (20 mins)
Give teams 20 minutes to come up with a list of factors that lead to successful software projects. Success factors could be anything related to people, processes and products (if you’d like to use the 3P / holistic view of organizations. Examples for such factors in terms of people might be individual characteristics as competency, accountability, creativity, discipline, etc. or group / team characteristics as cooperation, respect, engagement, authority, etc. They could be way too narrowed as are cross-functional teams, self-organizing teams or any other well-known “best practice” in this regard. Some examples for success factors related to processes might be effective communication, resources utilization, performance, flexibility, etc. More concrete examples could be process formalization and specific software development life-cycles, specific organizational policies and work procedures, working environment, etc. On the product side success factors might be quality, innovation, simplicity, etc.

Part II (10 mins)
Teams now have a list of factors that lead to successful software projects. Ask if any of the teams have defined what a successful software project is? None, I would suppose. This is what I call the “Means First, Then States Syndrome” (or even “No States Syndrome”), where software engineers tend to focus on the means or how-tos before they actually know and completely (and mutually) understand what the desired end states are (or just making assumptions based on their previous experience, peers’ behavior, etc.). It’s also related to the tendency some people have to “Act First, Then Think”.
Ask teams to explain how they feel. I’ve called the “AHA” moment when you understand that you’re trying to be successful without knowing what successful really means as feeling “successfool”. How often do the teams feel “successfool” in their real software projects?

If there’s a team in Round I which had defined their understanding of successful software project (before listing their success factors), the team wins 10 points.

ROUND II (30 mins)

Part I (10 mins)
Ask each team to come up with a definition of a successful software project (Definition of Success in analogy with Scrum Definitions of Done, Ready, etc.). It could be free text, a list of criteria (e.g. business value, customer satisfaction, organizational performance, team motivation, etc.), the well-known project management triangle (scope, time and cost) or anything else. This could be also used to introduce the importance of shared understanding in the agile world (e.g. the practices in XP for shared understanding, the sprint goal / definitions in Scrum, visibility and transparency in Kanban, etc.).

Part II (20 mins)
Now ask teams if their Definition of Success represents the interests of all possible organizational / project stakeholders (all those who might affect or might be affected by organizational / project’s execution and/or outcomes)? Does the definition represent the interests of the customers? What about the shareholders? The employees? This could be used as a basis for a small discussion on stakeholder analysis / theory and its importance in defining what a successful software project is.
The following list of stakeholders might be used to further evaluate the Definition of Success for each team (although a custom list might be used as well):

• Customers (e.g. end users or consumers, business organizations, government or public sector organizations, etc.)
• Partners (e.g. suppliers, contractors, organizations responsible for an outsourced component, product, service, etc.)
• Shareholders (e.g. owners, stockholders, investors, etc. who legally own any part of organizational share)
• Employees (e.g. top / middle-level managers, functional / project managers, functional staff, etc.)
• Society (all or group of people in a specific region, country or worldwide who might affect or might be affected by organizational/project’s execution and/or outcomes)

Each team wins 2 points for each stakeholder on the list whom interests are being represented by their Definition of Success.

ROUND III (30 mins)

Part I (10 mins)
Ask teams to go through their list of success factors and mark only these factors which have direct impact on their Definition of Success (they should mark them either green or put a star sign in front of them). Now ask teams to mark these factors which have indirect impact (mark them either yellow or a square sign), no impact (either white or a circle sign) or negative impact (red or a triangle sign). Calculate the points for each team using the following criteria:

• Green / Star: +2 points
• Yellow / Square: +1 points
• White / Circle: -1 points
• Red / Triangle: -2 points

Whites / circles are waste / muda (e.g. unnecessary / irrelevant efforts) while reds / triangles are negative influences regarding the Definition of Success. Having whites and reds is a direct result of the Means First, Then States Syndrome and shows how ineffective / inappropriate means / how-tos might be if they are not aligned with the actual desired end states.

Part II (20 mins)
Introduce the agile manifesto and the motivation of its signators. For each value / principle ask the teams whether they could link it to some of the success factors on their list. If yes, how it was marked – as green, yellow, white or red? If no, ask them whether they would like to add it as a success factor. How would they mark it? Which stakeholders’ interests do they represent? Once all the values / principles of the agile manifesto are covered ask teams whether they would like to add new values / principles to the manifesto. If the proposed success factor is accepted by all teams, the team proposing the success factor wins 5 points. No more than 3 proposals could be done by one team.

End (5 mins)
Calculate the results by summing up the points gained by each team and announce the winners.

Learning Points

• Drives a meaningful discussion on what success is in software projects (Definition of Success) and what factors could lead to it.
• Introduces and demonstrates the Means First, Then States Syndrome and the negative impact it could have on project’s execution and/or outcomes (e.g. introduce waste / muda). Thus it emphasizes the importance of having a shared understanding of desired end states and aligning project’s means / how-tos to them.
• Introduces stakeholder analysis / theory and alerts that all stakeholders’ interests should be taken into account in the Definition of Success.
• Introduces the agile manifesto as a list of factors which could lead to successful software projects.
• Reinforces agile values and principles as the participants understand the motivation for having them and the fact that they are based on years of hands-on industrial experience.




Original article: https://www.agify.me/means-first-then-states-syndrome/