le portefeuille d’etudes · le portefeuille apporte à chaque manager ou cadre en informatique,...
TRANSCRIPT
TRANSFORMATION DU TRAVAIL
PIZZA TEAM
Réussir une bulle agile
Table des matières 3
Résumé décideurs 5
Enjeu et plan 7
1. Vue d’ensemble 9
2. Le socle de compétences 15
3. La liberté 21
4. Le débat 29
5. L’itération 37
6. L’engagement 45
7. Annexe : exemples 49
Le Portefeuille d’EtudesLes solutions sur les sujets de fond à l’attention des décideurs, managers et cadres
Recherche appliquée indépendante MOe et MOa en informatique d’entreprise
Yphise Nous voulons réussir le défi de l’informatique agile
Transformationdu travail
Investissementagile
Transformationdevops
Transformationdigitale
Gouvernanceinformatique
Nous avons le plaisir de mettre cette étude à
votre disposition afin que vous ayez l’opportunité
d’apprécier notre travail à votre intention.
Sont insérés en début une présentation du
Portefeuille d’Etudes Yphise et son bon de
commande (4 pages).
Bonne lecture
L’équipe Yphise
« Je suis fascinée par la puissance de ce quin’a pas de forme : le vent, l’eau et la pensée »
Anita Conti
Anita Conti est à la fois aventurière, océnanographe et femme de lettres du XXème siècle.
Toute organisation est confrontée à des enjeux de changement qu’elle a du mal à réaliser, tant
freinent le quotidien, les habitudes, les situations établies, l’usure du temps et les craintes.
Pour réussir l’action, il faut d’abord une pensée qui établit une vision et réfléchit les moyens de sa
concrétisation.
Anita Conti nous rappelle à juste titre à quel point une pensée puissante peut faire bouger les choses.
Elle nous suggère aussi que sans cette pensée, l’effort sera vain ; que comme le vent et la mer
peuvent aussi ravager, la pensée mal construite détruit.
Une pensée forte et construite, qui sait articuler en intelligence fins et moyens, est une condition
indispensable à la réussite de l'action en entreprise.
A l’inverse, une pensée stéréotypée n’est pas étrangère à nombre de difficultés.
Construire cette pensée nécessite du recul et du temps, largement inaccessibles au décideur,
manager ou cadre dans l’exigence de l’opérationnel. Le Portefeuille d’Etudes vous accompagne en
réalisant pour vous ce travail.
Ce que nous essayons de faire à chaque étude tient en quatre points.
− La réflexion de fond dont les managers et cadres ont besoin, sans avoir le temps de la mener.
− Les messages et solutions les plus simples, sans être plus simples que la complexité du réel.
− L’action opérationnelle en entreprise, sans débat théorique ou conceptuel inutile.
− Une dynamique de collaboration entre MOe et MOa, et entre les métiers d’une MOe.
www.yphise.com > le Portefeuille d’EtudesDirecteur : Xavier Flez
60 rue de la Folie Regnault - 75011 Paris - [email protected]
Janvier 2019
Yphise Nous voulons réussir le défi de l’informatique agile
En ces temps difficiles, avec des contraintes
budgétaires fortes, il faut avancer sur les
compétences, l’efficacité collective et les leviers de la
motivation.
Le Portefeuille est dédié à cet objectif de recul pour
reprendre la main sur la compétitivité de
l’informatique.
Le Portefeuille d’EtudesLes solutions sur les sujets de fond à l’attention des décideurs, managers et cadres
Recherche appliquée indépendante MOe et MOa en informatique d’entreprise
Transformationdu travail
Investissementagile
Transformationdevops
Transformationdigitale
Gouvernanceinformatique
1. Le temps de la réflexion
La grande difficulté pour un manager ou cadre est de ne pas se laisser enfermer par l’opérationnel.
Il faut du recul, de l’air, pour ne pas se trouver à un moment ou à un autre dans une impasse parce qu’un
risque, une tendance ou un sujet d’action n’a pas été apprécié à temps.
A une époque de sur communication qui part dans tous les sens, il faut pouvoir aller sur une
compréhension de fond de ce qui arrive. C’est indispensable pour donner du sens à l’action et la réussir.
Le Portefeuille apporte à chaque manager ou cadre en informatique, MOe ou aMOa, la réflexion de fond
indispensable à la réussite collective et à son développement professionnel.
Il construit et rend accessible une pensée qui est la condition de la capacité à agir et à prendre en main
son avenir. Il constitue ainsi un outil sans équivalent pour sécuriser la décision et l’action.
2. La pertinence de chaque étude
Le Portefeuille est une base d’expertise constituée d’études : chacune traite en 30 pages un enjeu
sélectionné pour son importance dans la maitrise stratégique ou opérationnelle de l’informatique.
Ce que nous essayons de faire à chaque étude tient en quatre points.
− La réflexion de fond dont vous avez besoin, sans avoir le temps de la mener.
− Les messages et solutions les plus simples, sans être plus simples que la complexité du réel.
− L’action opérationnelle en entreprise, sans débat théorique ou conceptuel inutile.
− Une dynamique de collaboration entre MOe et aMOa, et entre les métiers d’une maitrise d’oeuvre.
© Yphise
3. Le mode d’emploi du Portefeuille
L’utilisation du Portefeuille est très simple, selon 3 manières complémentaires.
− Le recul sur l’opérationnel. Chaque étude distingue une partie qui permet en quelques minutes de
comprendre les points clés à surveiller ou qui doivent alerter chaque manager ou cadre.
− Sécuriser l’action. Chaque étude est conçue pour passer à l’action. Elle montre la cible, comment
l’atteindre, les erreurs à éviter. Elle permet de dynamiser la réflexion et le consensus.
− L’autoformation. Chaque étude est rédigée pour s’adresser à tout manager ou cadre, MOe ou aMOa,
indépendamment de sa spécialité ou de sa responsabilité. Chacun peut s’autoformer à son rythme.
4. La licence : votre réussite pour le prix de quelques heures d’un ingénieur
Le Portefeuille s’utilise librement sur licence annuelle qui donne accès sur www.yphise.com :
− à toutes les études disponibles + les 6 publiées pendant les 12 mois à venir,
− à tous les collaborateurs souhaités de votre entreprise.
La licence pour 12 mois coûte seulement 1400 euros HT
Le prix est fait pour que tout manager ou cadre puisse en bénéficier. Il est marginal au regard du coût de
réalisation d'une seule étude ; sans compter qu'il faut une indépendance et un recul difficiles en interne.
En ces temps où il ne faut pas se tromper, le Portefeuille est votre fidèle compagnon. Notre indépendance
depuis 1985, grâce à la fidélité des managers qui nous font confiance, est votre meilleure garantie.
5. Les études disponibles
La trentaine d’études du Portefeuille est classée sur www.yphise.com en cinq objectifs.
Réussir l’engagement, la motivation et l’efficacité collective en informatique.Transformation du travail
Transformation digitale
Investissement agile
Transformation devops
Gouvernance informatique
Réussir la transformation digitale.
Réussir l'agilité de l'investissement sur les systèmes d'information.
Réussir l'agilité de l'industrialisation et les engagements en production.
Réussir la compétitivité des activités informatiques.
Le Portefeuille d’Etudes
Le Portefeuille d’Etudes Yphise
Le temps de la réflexion des décideurs, managers et cadres, MOe ou aMOa
72 rue Damrémont 75018 PARIS - T 01 42 78 20 59 - [email protected]
Bon de commande
Société
Représentée par (nom /fonction)
Email Tel
Réf commande
Adresse
Paiement par virement bancaire à 30 jours date de facture établie à la livraison.
� Oui, je prends le forfait d'accès à toutes les études du Portefeuille
Accès pendant un an sur www.yphise.com à toutes les études disponibles + les 6 à paraître sur les 12
mois à venir, à chaque collaborateur de mon choix dans mon entreprise
1400 Eur HT soit 1680,00 Eur TTC (20.0%)
� Oui, j'ai droit à la réduction DSI ou prestataire < 30 collaborateurs : -30%
1070 Eur HT soit 1284,00 Eur TTC
Liste des études disponibles au verso.
Liste des collaborateurs qui ont accès au Portefeuille
Nom Email
L’email constitue l’identifiant sur www.yphise.com auquel nous attachons les droits d’accès.
Pas de souci si vous ne savez pas à ce jour qu’elle sera cette liste. Celle-ci est modifiable sans frais et à tout
moment pendant les 12 mois de validité de votre forfait. Il suffit de nous envoyer un email.
Date - Signature
Les études disponibles
Titre (nombre de pages et date de parution mois/année)
Le défi de l’informatique agile (49p 07/17) �
Pizza team (50p 01/19) �
Bien utiliser ISO 9001:2015 en informatique (40p 02/16) �
Plateformes d’alliances (35p 11/18) �
Intelligence artificielle (46p 09/18) �
Blockchains : comprendre la séquence (26p 02/18) �
Blockchains : comprendre l’essentiel (69p 03/18) �
Big data (43p 09/18) �
Des projets rigides à l’agilité de l’investissement (41p 09/17) �
Piloter la compétitivité d’un SI : Partie 1 : l’aMOa stratégique (41p 03/14) �
Piloter la compétitivité d’un SI : Partie 2 : l’alignement (51p 04/14) �
Piloter la compétitivité d’un SI : Partie 3 : la gouvernance (48p 05/14) �
Responsable de business case : Partie 1 : la dynamique (40p 05/18) �
Responsable de business case : Partie 2 : les pratiques (46p 06/18) �
L’expérience utilisateur : Partie 1 : guide de réflexion (30p 05/18) �
L’expérience utilisateur : Partie 2 : guide pratique (36p 05/18) �
Préparer un projet (51p 05/18) �
Chiffrer un projet en amont : Partie 1 : guide de réflexion (47p 08/15) �
Chiffrer un projet en amont : Partie 2 : guide pratique (49p 09/15) �
Logiciel ou progiciel ? (56p 06/15) �
Le mode projet : Partie 1 : l’agilité des projets (45p 11/17) �
Le mode projet : Partie 2 : guide pratique (43p 12/17) �
Le bon usage de Scrum : Partie 1 : guide de réflexion (37p 01/17) �
Le bon usage de Scrum : Partie 2 : complément (37p 01/17) �
Transformation devops : Partie 1 : comprendre (39p 03/17) �
Transformation devops : Partie 2 : agir (53p 05/17) �
L’agilité des centres de compétences (45p 03/19) �
Conception à temps (42p 05/19) �
Plan de reprise agile d’un SI : Partie 1 : guide de réflexion (47p 06/16) �
Plan de reprise agile d’un SI : Partie 2 : guide pratique (59p 08/16) �
Bien utiliser le cloud (55p 12/18) �
Compétitivité de l’informatique : principe d’organisation (30p 10/18) �
Table des matières
Classement principal sur www.yphise.com
Transformationdu travail
Résumé décideurs 5
Enjeu et plan 7
1. Vue d’ensemble
1.1 Description 10
1.2 Finalité 11
1.3 Une bulle agile 12
1.4 Le fonctionnement 13
1.5 Réussir 14
2. Le socle de compétences
2.1 Mémento 16
2.2 Le débat 17
2.3 La liberté 18
2.4 L’itération 19
2.5 L’engagement 20
3. La liberté
3.1 Les pratiques 22
3.2 Le raisonnement économique 24
3.3 L’objectif de valeur 26
3.4 Les scénarios d’usage 28
4. Le débat
4.1 Les pratiques 30
4.2 La pensée de groupe 31
4.3 Le débat contradictoire 33
4.4 Le travail en atelier 35
5. L’itération
5.1 Les pratiques 38
5.2 La combinaison chaud et froid 39
5.3 Les boites de temps 40
5.4 Le centrage des itérations 42
.../...
6. L’engagement
6.1 Les pratiques 46
6.2 Les facteurs d’engagement 47
6.3 Les protocoles de points d’engagement 48
7. Annexe : exemples 49
Chaque étude est rédigée pour être accessible à tout cadre, manager ou décideur en informatique, maitrise
d’œuvre (MOe) ou d’ouvrage (MOa), indépendamment de sa spécialité ou de sa responsabilité du moment.
Cette ouverture est une clé du développement professionnel de chacun et de la réussite collective.
Synopsis thématique
Principaux sujets abordés et niveau.
Pizza team Guide pratique.
Nous recommandons de ressortir cette étude sur www.yphise.com en cas d’utilisation
plusieurs mois après sa date de parution : elle peut avoir fait l’objet de corrections ou
de petites modifications, notamment liées à des évolutions du Portefeuille.
Version 1.0
5 © Yphise
Résumé décideurs
L’agilité de l’informatique nécessite de savoir monter des équipes capables de trouver une
solution sur un objectif de valeur en quelques séances ou semaines de travail ; solution
nécessitant la collaboration de compétences diversifiées, avec un besoin d’équilibres ou
de compromis à trouver.
On appelle ces équipes des pizza teams. On peut ou non apprécier le terme, et donc en
choisir un autre ; il est néanmoins intéressant parce qu’il constitue une image simple :
une équipe qui se partage une pizza.
Le besoin de pizza teams est un peu partout en informatique : amélioration lean en
gestion de problème ; décision de mise en production de changements ; conduite d’un
sprint de développement ; construction d’un business case ; construction d’une
expression de besoin ; élaboration d’exigences de reprise ; qualification des opportunités
ou besoins d’investir sur un système d’information ; etc.
Une pizza team est ainsi un mode de travail agile, dont on peut avoir besoin dans des
processus fonctionnant ailleurs selon un mode administré : il faut alors être capable de
ne pas étouffer cette agilité.
Le point fondamental est que l’agilité de l’informatique amène à ce que TOUT
professionnel soit à l’aise avec ce mode de travail : il se concrétise par un socle de
compétences transverses qui est une condition (non suffisante) de l’agilité. Nous
insistons : l’erreur à éviter est ici de considérer que la réussite d’une pizza team est
affaire de bonne volonté des participants ; le sujet est de compétences, et donc de
gestion d’une montée en compétences.
Ce socle de compétences comporte quatre ingrédients - la liberté, le débat, l’itération et
l’engagement - qu’il faut savoir combiner en une règle du jeu qui permet la dynamique
d’engagement collectif adaptée à la finalité ; par différence avec une méthode qui définit
des tâches, des modes opératoires et des livrables.
L’essentiel concerne le débat et la liberté. Une pizza team doit trouver des équilibres ou
compromis. Il faut donc que les participants puissent et sachent débattre. Ce qui
nécessite une double liberté. D’abord sur la solution à obtenir : il faut que tout ne soit
pas figé au départ. Ensuite de chaque participant vis-à-vis de la discipline de
l’informatique ou du métier qu’il représente : il faut que chacun ait une certaine
autonomie de décision lui permettant de trouver des équilibres ou des compromis en
ligne avec l’objectif de valeur. Ces points structurent la faisabilité ou non d’une pizza
team et le choix des participants.
Les compétences d’agilité posent un problème de formalisation : on cherche une
dynamique d’équipe, cela ne se fait pas en écrivant des méthodes. Mais à l’inverse, cela
ne veut pas dire que ces compétences sont insaisissables ; elles s’appuient au contraire
sur des connaissances et des techniques précises. On est dans la situation d’une équipe
jouant un match d’un sport collectif : chaque match est différent, mais la réussite
nécessite la maitrise de techniques et de configurations de jeu permettant de mener ce
jeu et de réagir en toute situation.
6 © Yphise
La bonne formalisation de compétences d’agilité doit pour cela être centrée sur la
compréhension de fond et les pratiques essentielles, sans viser à tout détailler : il s’agit
de dégager le juste nécessaire pour « jouer le match ». Vous verrez que nous essayons
de nous tenir sur ce « juste nécessaire ».
Cette étude est importante car elle approfondit la transformation du travail qui est une
condition forte du numérique. Elle est une partie de la réponse au défi de l’informatique
agile1 ; à la fois incontournable et mature. Il faut en outre toujours faire attention quand
il s’agit d’agilité : les approximations donnent des résultats décevants et sont même
souvent contre productifs ; on ne s’en sort jamais par de la recette qui dispenserait d’une
compréhension de fond.
C’est pourquoi nous souhaitons que cette étude puisse vous aider à développer,
maintenir ou recentrer le socle de compétences permettant ce mode de travail agile, dont
on a besoin un peu partout pour réussir le défi de l’informatique agile.
Bonne lecture.
Yphise
Janvier 2019
1 Etude « Le défi de l’informatique agile ».
7 © Yphise
Enjeu et plan
Enjeu
L’agilité de l’informatique nécessite de savoir monter des équipes capables de trouver une
solution sur un objectif de valeur en quelques séances ou semaines de travail ; solution
nécessitant la collaboration de compétences diversifiées, avec un besoin d’équilibres ou
de compromis à trouver.
On appelle ces équipes des pizza teams. On peut ou non apprécier le terme, et donc en
choisir un autre ; il est néanmoins intéressant parce qu’il constitue une image simple :
une équipe qui se partage une pizza.
Résultat
Une pizza team est ainsi un mode de travail agile dont le besoin est un peu partout en
informatique : on ne peut pas réussir la transformation digitale sans sa maitrise ; l’agilité
de l’informatique amène à ce que TOUT professionnel de l‘informatique soit à l’aise avec
ce mode de travail.
L’erreur à éviter est de considérer que la réussite d’une pizza team est affaire de bonne
volonté des participants ; le sujet est de compétences précises, et donc de gestion d’une
montée en compétences.
C’est pourquoi cette étude dégage le socle de compétences nécessaires à un niveau de
pratiques permettant une formation.
Elle comporte deux niveaux de lecture : d’abord une compréhension synthétique du socle
de compétences, puis un exposé des pratiques (ou techniques).
La compréhension synthétique distingue une vue d’ensemble du socle de compétences
(1. Vue d’ensemble) et une présentation organique de chacune (2. Le socle de
compétences). Une annexe propose une liste d’usages d’une pizza team, montrant que
le besoin se trouve dans toutes les disciplines de l’informatique.
L’exposé des pratiques est organisé en quatre parties concrétisant les compétences au
niveau opérationnel adapté à un mode de travail agile (3. La liberté, 4. Le débat, 5.
L’itération, 6. L’engagement).
Une pizza team est un dispositif opérationnel d’agilité. Son bon usage nécessite de le
situer plus largement dans l’agilité de l’informatique : nous recommandons une
compréhension de fond du défi de l’informatique agile avant d’entrer dans la présente
étude2.
2 Etude « Le défi de l’informatique agile ».
8 © Yphise
Les résultats de cette étude sont présentés de sorte à faire immédiatement ressortir
l’essentiel pour l’opérationnel. Nous avons beaucoup travaillé la simplicité et la rapidité
d’accès aux résultats par l’utilisation systématique de schémas (21 schémas) et un texte
à lire réduit ; un résumé synthétique (encadré rouge) permet un accès immédiat aux
points importants et aux pratiques (16 encadrés rouges).
Cette étude constitue ainsi un guide pratique destiné à tout professionnel de
l’informatique, maitrise d’œuvre ou d’ouvrage, quelle que soit sa discipline.
Elle s’adresse aux professionnels des méthodes de l’informatique qui doivent apporter le
formalisme et le support nécessaires pour assurer la montée en compétences.
Elle fournit aux décideurs et managers la compréhension de fond leur permettant de bien
situer et utiliser ce mode de travail agile dans toute situation où il est nécessaire.
9 © Yphise
1. Vue d’ensemble
1.1 Description
1.2 Finalité
1.3 Une bulle agile
1.4 Le fonctionnement
1.5 Réussir
LibertéRègle du jeu Débat= + + +
Un socle de compétences transverses
EngagementItération
Pizza team = une équipe qui se partage une pizza
Pour trouver rapidement UNE solution, pas forcément
LA solution, permettant d’atteindre un objectif de valeur
10 © Yphise
1. Vue d’ensemble
1.1 Description
Pizza team = une équipe qui se partage une pizza
Une image pour dire plusieurs points.
− Une petite équipe : pouvant se partager une pizza.
− Temporaire : le temps de manger la pizza.
− Entre égaux : la pizza est partagée en parts égales.
− Tout le monde : le partage d’une pizza n’est pas une cérémonie élitiste.
− A tout moment : le partage d’une pizza ne nécessite pas toute une organisation.
On peut ou non apprécier le terme, et donc en choisir un autre. Il est néanmoins
intéressant parce qu’il constitue une image simple.
11 © Yphise
1. Vue d’ensemble
1.2 Finalité
Pizza team = une équipe qui se partage une pizza
Pour trouver rapidement UNE solution, pas forcément
LA solution, permettant d’atteindre un objectif de valeur
Une pizza team est pertinente lorsqu’il faut trouver des équilibres ou compromis en raison de
contraintes difficiles ou d’enjeux contradictoires.
On a besoin de donner une liberté d’initiative et de décision aux participants, afin d’arriver à
trouver rapidement UNE solution concrétisant un objectif de valeur.
Par différence avec un travail qui se conduit avec méthode, au sens où on sait spécifier
précisément LA solution (« parfaite » et « définitive »), et définir le mode opératoire à suivre pour
la réaliser.
Une pizza team est un mode de travail agile.
Il faut arriver à une solution qui est nécessairement un équilibre ou un compromis en
raison des contraintes ou d’enjeux contradictoires.
Il y a donc des incertitudes sur la solution ou la manière de l’obtenir. Ceci rend
impossible un travail en mode administré, c’est-à-dire qui spécifie cette solution puis
planifie les tâches pour la réaliser.
Chaque participant amène une expérience, des techniques, des contraintes, des
exigences ou des enjeux. Il faut réussir une collaboration forte entre ces participants pour
sortir rapidement une solution concrétisant un objectif de valeur.
Le besoin de pizza teams est un peu partout en informatique : amélioration lean en
gestion de problème ; décision de mise en production de changements ; conduite d’un
sprint de développement ; construction d’un business case ; construction d’une
expression de besoin ; élaboration d’exigences de reprise ; qualification des opportunités
ou besoins d’investir sur un système d’information ; etc.3.
3 Chapitre ‘7. Annexe : exemples’.
12 © Yphise
1. Vue d’ensemble
1.3 Une bulle agile
Une pizza team est une bulle agile, temporaire et fragile, qu’il faut savoir utiliser à bon escient ;
en particulier dans un environnement de processus concrétisant par ailleurs un mode de travail
administré.
Pizza teamProcessus
Une pizza team est un dispositif d’agilité.
Ce dispositif a son utilité dans des processus qui concrétisent par ailleurs un mode de
travail administré : on a un besoin local d’un mode de travail agile dans un système de
processus qui fonctionne ailleurs selon une logique de planification4. Il faut alors être
capable de ne pas étouffer cette agilité.
A l’inverse, il ne faut pas confondre agilité et pizza team. C’est UN dispositif d’agilité,
ayant des usages nombreux et variés, mais il n’est pas en lui-même suffisant pour
assurer l’agilité de l’informatique5.
Tout professionnel en informatique, quelle que soit sa spécialité ou sa responsabilité, doit
donc être familier avec ce dispositif.
4 Etude « Le défi de l’informatique agile ».
5 Id.
13 © Yphise
1. Vue d’ensemble
1.4 Le fonctionnement
LibertéRègle du jeu EngagementItérationDébat= + + +
La réussite d’une pizza team a besoin de quatre ingrédients.
− Il faut que les participants aient une certaine liberté sur la solution à obtenir.
− Il faut qu’ils sachent débattre entre eux de sorte à trouver des équilibres ou compromis
permettant d’aboutir à une solution dans le cadre des contraintes et des enjeux
contradictoires.
− Il faut qu’il sachent avancer progressivement, par itération, de sorte à toujours obtenir
rapidement une solution.
− Il faut qu’ils sachent s’engager dans un contexte où on ne sait pas planifier d’avance.
Comment s’y prendre pour réussir ce dispositif d’agilité ?
C’est-à-dire comment faire pour trouver une solution qui répond à un objectif de valeur,
en quelques séances ou semaines de travail, nécessitant la collaboration de compétences
diversifiées, avec un besoin d’équilibres ou de compromis à trouver ?
Il faut la bonne combinaison de quatre ingrédients.
− Liberté : il faut que l’équipe ait une certaine liberté de manoeuvre et d’initiative sur la
solution attendue ; et que les participants sachent utiliser cette liberté ;
− Débat : il faut que les participants sachent discuter de manière constructive sur les
sujets qui nécessitent de trouver des équilibres ou compromis ;
− Itération : il faut que les participants sachent avancer pas à pas, de manière itérative,
au regard d’un objectif de valeur à atteindre.
− Engagement : il faut que les participants sachent s’organiser pour tenir l’engagement
de résultat de l’équipe.
La bonne combinaison est celle qui permet à l’équipe de réussir en la circonstance : c’est
une règle du jeu qui permet la dynamique d’engagement collectif ; par différence avec
une méthode qui définit des tâches, des modes opératoires et des livrables6.
6 Etude « Le défi de l’informatique agile ».
14 © Yphise
1. Vue d’ensemble
1.5 Réussir
LibertéRègle du jeu Débat= + + +
Les quatre ingrédients de la réussite d’une pizza team forment un socle de compétences
transverses avec lequel tout professionnel en informatique doit être à l’aise.
Un socle de compétences transverses
EngagementItération
Nous venons de voir que la réussite nécessite quatre ingrédients qui s’expriment en
termes de « savoir faire quelque chose », c’est-à-dire de compétences.
Il faut donc distinguer ce socle de compétences.
Nous insistons sur ce sujet : nous sommes sur un socle de compétences transverses,
dont TOUT professionnel en informatique a besoin pour travailler en agilité. L’agilité de
l’informatique requiert une maturité suffisante et banalisée sur ce socle7.
Dit autrement, il faut éviter l’erreur consistant à estimer que la réussite d’une pizza team
est affaire de bonne volonté ou de dispositions culturelles des participants. Le sujet est
de compétences, qui se concrétisent donc dans une gestion des compétences.
Une difficulté des compétences d’agilité est leur bonne formalisation. On cherche une
dynamique d’équipe, cela ne se fait pas en écrivant des méthodes qui multiplient les
procédures, les tâches, les livrables et les « qui fait quoi ». Mais à l’inverse, cela ne veut
pas dire que ces compétences sont insaisissables ; elles s’appuient au contraire sur des
connaissances et des techniques précises. On est dans la situation d’une équipe jouant un
match d’un sport collectif : chaque match est différent, mais la réussite nécessite la
maitrise de techniques et de configurations de jeu permettant de mener ce jeu et de
réagir en toute situation8.
La bonne formalisation de compétences d’agilité doit être centrée sur la compréhension
de fond et les pratiques essentielles, sans viser à tout détailler9 : il s’agit de dégager le
juste nécessaire pour « jouer le match ». Il faut donc toujours descendre prudemment
dans les pratiques, en ne perdant jamais de vue la construction d’ensemble qui les
justifie.
C’est pourquoi la suite de cette étude est en deux temps : d’abord une vue d’ensemble
synthétique du socle de compétences, puis des chapitres descendant dans l’exposé de
pratiques (ou techniques).
7 C’est une condition nécessaire, non suffisante : étude « Le défi de l’informatique agile ».
8 Cette difficulté de formalisation est une raison qui fait que les DRH ont du mal à se saisir des compétences
du travail en agilité, pourtant essentielles en informatique.
9 Puisqu’on est précisément sur un mode de travail pour des situations incertaines, qui ne peuvent pas être
traitées par une logique de planification.
15 © Yphise
2. Le socle de compétences
2.1 Mémento
2.2 Le débat
2.3 La liberté
2.4 L’itération
2.5 L’engagement
Règle du jeu = + + +Liberté
Définition du résultat par un objectif de valeur
Indépendance de chacun vis-à-vis de sa hiérarchie
Expérience de chacun sur sa discipline
Liberté
Débat
Débat
Communication fluide, intense, transparente
Maitrise des dangers de la pensée de groupe
Conduite de débats contradictoires
Travail en atelier
Engagement
Itération
Construction itérative de la solution
Travail par boites de temps
Equipe à plat, entre égaux
Protocole de points d’engagement
EngagementItération
16 © Yphise
2. Le socle de compétences
2.1 Mémento
Règle du jeu = + + +Liberté
Définition du résultat par un objectif de valeur
Indépendance de chacun vis-à-vis de sa hiérarchie
Expérience de chacun sur sa discipline
Liberté
Débat
Débat
Communication fluide, intense, transparente
Maitrise des dangers de la pensée de groupe
Conduite de débats contradictoires
Travail en atelier
Engagement
Itération
Construction itérative de la solution
Travail par boites de temps
Equipe à plat, entre égaux
Protocole de points d’engagement
Un socle de compétences transverses
EngagementItération
Voici notre proposition de vue d’ensemble synthétique du socle de compétences pour
réussir le mode de travail agile que constitue une pizza team.
Les différents thèmes abordés forment un tout. Ils ne sont cependant pas homogènes
dans leur contenu, en particulier dans leur possibilité de concrétisation par des
pratiques10.
La bonne nouvelle est qu’il n’y a rien d’extraordinaire dans tout cela. Mais cela ne signifie
pas l’évidence de chaque thème : on est bien sur une problématique de compétences,
donc d’identification et de gestion d’une montée en maturité.
L’ordre de présentation qui suit répond à un objectif de compréhension de la logique de
construction de ce socle (vue organique).
10 Chapitres 3. à 6.
17 © Yphise
2. Le socle de compétences
2.2 Le débat
LibertéRègle du jeu EngagementItérationDébat= + + +
Communication fluide, intense, transparente
Maitrise des dangers de la pensée de groupe
Conduite de débats contradictoires
Travail en atelier
Les participants viennent de différentes disciplines de l’informatique ou métiers de
l’entreprise.
Si chacun arrive en disant « voici les contraintes, les exigences ou les règles de l’art de
ma discipline ou du métier que je représente : c’est à prendre ou à laisser », l’équipe ne
peut pas avancer.
Il va falloir débattre, trouver des équilibres ou des compromis, sans se buter sur des
positions fondées mais irréalistes en la circonstance.
Ceci repose d’abord sur une communication fluide, intense, transparente entre les
participants sur toute la durée de vie de la pizza team ; y compris sur les sujets qui
fâchent.
Au delà, il faut savoir mener les discussions sur chaque sujet nécessitant de trouver un
équilibre ou un compromis. Ceci nécessite de comprendre les dangers de la pensée de
groupe qui font que les décisions prises sont mauvaises malgré la bonne volonté et la
compétence de chacun.
La bonne organisation des discussions amène un savoir-faire de travail en atelier.
18 © Yphise
2. Le socle de compétences
2.3 La liberté
Règle du jeu EngagementItérationDébat= + + +
Trouver une solution concrétisant
un objectif de valeur
SOLUTION DELIVREEOBJECTIF DE VALEUR
Liberté
Définition du résultat par un objectif de valeur
Indépendance de chacun vis-à-vis de sa hiérarchie
Expérience de chacun sur sa discipline
La capacité à trouver des équilibres ou des compromis nécessite une DOUBLE liberté.
La première concerne la solution à obtenir. Il faut que tout ne soit pas figé au départ ; il
faut au contraire des degrés de liberté : le résultat est défini par un objectif de valeur.
La seconde concerne la délégation. Chaque participant représente une discipline de
l’informatique ou un métier de l‘entreprise : si chacun arrive en disant « de toute façon,
je n’ai aucune liberté de la part de ma hiérarchie », l’équipe ne peut pas avancer. Il faut
donc un réel détachement, une autonomie de décision, de chaque participant lui
permettant de trouver des équilibres ou des compromis en ligne avec l’objectif de valeur.
Une conséquence de ce besoin de liberté est que chaque participant doit avoir une
expérience ou une expertise suffisante de son domaine pour pouvoir être force de
propositions et d’idées concrètes pour avancer au mieux sur l’objectif de valeur11.
11 On parle parfois de craftmanship (compétence de l’artisan).
19 © Yphise
2. Le socle de compétences
2.4 L’itération
Construction itérative de la valeur
par combinaison de boites de temps
v1 v2 v3
SOLUTION DELIVREE
v4
OBJECTIF DE VALEUR
Recul à froid sur le résultat intermédiaire
LibertéRègle du jeu EngagementItérationDébat= + + +
Construction itérative de la solution
Travail par boites de temps
A ce stade de l'exposé, les participants ont la liberté nécessaire et savent débattre et se
mettre d’accord. Ces conditions sont nécessaires, mais elles ne suffisent pas pour avancer
de manière sûre vers une bonne solution.
Si chacun arrive en disant « nous comprenons bien l’objectif de valeur, mais ne voyons
pas comment le concrétiser correctement avec les contraintes que nous avons », l’équipe
ne peut pas avancer.
LE principe fondamental pour trouver une solution définie par un objectif de valeur est
d’avancer pas à pas, de manière itérative. On ne voit pas très bien comment passer des
grandes idées au concret avec ses contraintes : il faut une construction itérative.
Cette construction itérative est une démarche expérimentale : on fait, on prend du recul
et on réagit ; par différence avec une logique de planification qui vise à décrire
précisément la solution puis à établir le mode opératoire pour l’obtenir.
Une construction itérative donne la possibilité de revenir en arrière lorsque cela est
nécessaire. Le problème est de ne pas tourner en rond : il faut un savoir-faire de
conduite des itérations de sorte à assurer une convergence rapide vers une bonne
solution.
L’avancement par un objectif de valeur amène en particulier à savoir travailler en se
donnant un temps donné pour discuter un sujet ou faire quelque chose. L’objectif peut en
effet être sans fin ou son atteinte nécessiter des moyens en temps ou en ressources que
l’on n’a pas. L’enjeu est alors de toujours trouver UNE solution satisfaisante en la
circonstance ; et pas forcément LA solution, peut-être intellectuellement plus
satisfaisante, mais irréaliste. La maitrise de l’avancement repose sur un travail
systématique par boites de temps (time boxing).
20 © Yphise
2. Le socle de compétences
2.5 L’engagement
Règle du jeu ItérationDébat= + + +Liberté Engagement
Equipe à plat, entre égaux
Protocole de points d’engagement
Equipe à plat
Point d’engagement
Si chacun arrive en disant « je n’ai pas fait ce qui était prévu car je n’ai pas eu le
temps », l’équipe ne peut pas avancer.
L’importance de ce dernier ingrédient varie selon que la pizza team a pour objectif de
produire une réflexion (ex. une expression de besoin par une suite d’ateliers) ou une
réalisation (ex. un code par un sprint). Il prend toute son importance lorsque chaque
participant porte la responsabilité de tâches à faire.
Il n’y a pas de problème lorsqu’on sait planifier ces tâches et que le responsable de
chacune la mène conformément à cette planification... ce qui est une situation
exceptionnelle pour une pizza team. Deux raisons à cela.
La première est que les participants ne sont pas forcément dédiés à temps plein. C’est
souhaitable, mais pas toujours pertinent ou possible.
La seconde est structurelle à ce qu’on attend d’une pizza team : avancer sur un objectif
de valeur, avec un besoin d’équilibres ou de compromis à trouver nécessitant la
collaboration de compétences diversifiées. On avance plutôt sur des sables mouvants que
sur une terre ferme. C’est pourquoi la logique de planification ne fonctionne pas ; il faut
passer à une dynamique d’engagement au fur et à mesure des événements.
La maitrise de cette dynamique d’engagement nécessite de comprendre les facteurs qui
font qu’un participant est à même de réussir ou non dans un environnement incertain.
Ces facteurs amènent à penser l’équipe à plat, sans hiérarchie interne et s’organisant
librement au fil des événements. Cette liberté d’organisation se gère par un protocole de
points d’engagement.
21 © Yphise
3. La liberté
3.1 Les pratiques
3.2 Le raisonnement économique
3.3 L’objectif de valeur
3.4 Les scénarios d’usage
Règle du jeu EngagementItérationDébat= + + +Liberté
22 © Yphise
3. La liberté
3.1 Les pratiques
Trouver une solution concrétisant
un objectif de valeur
SOLUTION DELIVREEOBJECTIF DE VALEUR
Liberté
Définition du résultat par un objectif de valeur
Indépendance de chacun vis-à-vis de sa hiérarchie
Expérience de chacun sur sa discipline
! La difficulté de la liberté
La liberté est l’ingrédient le plus délicat à manipuler d’un mode de travail agile.
De manière schématique, un mode de travail agile c’est :
− PLUS de liberté qu’un mode de travail administré pour PLUS d’intelligence collective,
− afin de trouver UNE solution satisfaisante en la circonstance, avec ses contraintes et
ses enjeux contradictoires, même si ce n’est pas LA solution idéale ou définitive.
L’agilité signifie une certaine autonomie d’initiative et de décision de chaque participant.
Et surtout la capacité à l’utiliser à bon escient, ce qui est toujours un challenge difficile
car elle amène pour chacun une certaine prise de risque personnel et donc du stress12. Il
faut en effet trouver des équilibres ou des compromis, c’est-à-dire accepter que son point
de vue ou son exigence légitime ne soit pas totalement respecté.
Ceci a trois conséquences fortes immédiates.
La première est que l’organisation doit savoir accepter l’échec lié à la recherche
d’équilibres ou de compromis. Si l’option retenue par l’équipe sur une exigence portée par
une discipline ou un métier se révèle être après coup problématique, il ne faut pas que la
hiérarchie en rende a priori responsable le participant qui porte cette exigence : il ne
suffit pas de s’arrêter au résultat, il faut aussi considérer ce qui était faisable ou pertinent
de faire par l’équipe.
La seconde est que chaque participant doit avoir une bonne expérience de sa discipline
ou de son métier. Il ne faut pas qu’il soit novice, mais qu’il ait au contraire une
expérience suffisante pour être en situation de proposition et de prise de recul dans des
discussions et des décisions pouvant être difficiles.
12 Ex. stress d’un comité d’investissement ou d’un CAB de mise en production.
23 © Yphise
La troisième est que cela concerne tous les participants : si l’un d’entre eux n’a pas
l’autonomie, l’expérience ou la posture adéquate, alors l’équipe se trouve en incapacité
de travailler correctement.
L’exigence de liberté est donc structurante sur la possibilité ou non de monter une pizza
team et sur le choix des participants.
Une fois établie cette faisabilité, reste à être capable d’avancer en situation de liberté,
c’est-à-dire de résultat répondant à un objectif de valeur. Ceci se fait en maitrisant trois
lots de pratiques :
− comprendre le raisonnement économique,
− formuler un objectif de valeur,
− avancer par les scénarios d’usage.
24 © Yphise
3. La liberté
3.2 Le raisonnement économique
Une pizza team sert à trouver des équilibres ou compromis ; en situation où on ne peut pas
satisfaire toutes les exigences.
Chaque participant doit savoir accepter des limites à son point de vue : la pizza team est une
équipe fondée par un objectif de valeur qui dépasse ces points de vue.
Dit autrement, la pizza team « joue collectif » : elle rejette les comportements individualistes.
100%
e1 e2 e3
Respect de eX
0%
100%
e1 e2 e3
Respect de eX
0%
100%
e1 e2 e3
Respect de eX
0%
3 participants, chacun portant un lot d’exigences (enjeux, contraintes) eX
LA solution = le respect
de toutes les exigences
UNE bonne solution = un optimum relatif
Le choix de la bonne solution en la circonstance nécessite
de donner à l’équipe un OBJECTIF DE VALEUR à atteindre
1 2 3
La solution parfaite et définitive respecte toutes les exigences (1). Il n’y a donc pas besoin de
trouver des équilibres ou compromis : un mode de travail agile est inutile.
Un mode de travail agile est nécessaire dans le cas contraire. On passe alors d’une situation où
il y a une meilleure solution à une pouvant comporter plusieurs bonnes solutions : (2) et (3).
Une bonne solution est un optimum relatif : l’amélioration d’une exigence en dégrade d’autres :
ex. l’amélioration de e3 (2) dégrade e1 et e2 (3).
Il est courant qu’il existe plusieurs optimums relatifs : ex. (2) et (3). L’arbitrage nécessite pour
l’équipe de se référer à un objectif de valeur qui lui est donné : ex. le choix entre les deux
équilibres possibles que sont (2) et (3) a besoin de l’éclairage d’un objectif de valeur
permettant de les départager.
Un objectif de valeur EST INDISPENSABLE. En particulier un vote majoritaire des participants
ne peut pas convenir : ex. la solution (3) peut être meilleure que la (2), alors que (2) satisfait
davantage deux des trois participants (les porteurs de e1 et e2, versus le porteur de e3).
Il faut donc que l’objectif de valeur soit compris et accepté de TOUS les participants : il fonde
l’équipe.
Trouver un équilibre ou compromis en situation de contraintes ou d’enjeux contradictoires
consiste à mener un raisonnement économique13.
Un raisonnement économique vise à trouver la solution optimale RELATIVE, en la
circonstance. On est dans une situation où il n’y a pas UNE solution permettant le respect
de toutes les exigences, mais des solutions qui s’en approchent plus ou moins. Parmi ces
solutions, sont intéressantes celles qui constituent un optimum relatif 14.
13 Un raisonnement économique prend en compte l’ensemble des facteurs et des flux qui produisent ou
consomment de la valeur. Il ne se réduit pas au financier.
14 Solution dite aussi pareto optimale (optimale au sens de pareto).
25 © Yphise
Un optimum relatif signifie que l’amélioration du respect d’une exigence en dégrade
d’autres : il faut alors arbitrer entre différents équilibres ou compromis. Cet arbitrage
nécessite une référence donnée à l’équipe : l’objectif de valeur à atteindre.
Une pizza team est fondée par cet objectif de valeur : on attend d’elle la capacité à
trouver les optimums relatifs intéressants et à arbitrer entre eux au regard d’un objectif
de valeur compris et accepté par TOUS les participants.
Ceci permet de cadrer la posture de chaque participant d’une pizza team. Chacun vise le
respect des contraintes, exigences ou règles de l’art de sa discipline ou de son métier ;
MAIS il n’est pas là pour imposer coûte que coûte son point de vue. Il y a une seconde
réalité qui est l’EQUIPE, porteuse d’un objectif de valeur : la réussite est COLLECTIVE ; il
s’agit de trouver le meilleur équilibre ou compromis sur l’objectif de valeur.
Nous insistons sur ce sujet : on n’a pas besoin d’un mode de travail agile s’il existe une
solution qui satisfait chacun des participants : une pizza team n’est pas un simple groupe
de travail réunissant des participants, mais une EQUIPE autonome qui assume une
responsabilité COLLECTIVE. La pizza team « joue collectif » : elle rejette les
comportements individualistes.
26 © Yphise
3. La liberté
3.3 L’objectif de valeur
L’objectif de valeur est un cadre qui donne de la liberté sur la solution ; qui permet de challenger
la réflexion et l’action.
Une pizza team ne peut pas avancer correctement sans un objectif de valeur compris et accepté.
− Finalité : une qualité, un gain, un coût ou autres = la référence ou la direction ultime pour
penser, agir et arbitrer : on parle parfois de la finalité ultime.
− Caractéristiques essentielles : un petit nombre de propriétés à rechercher ou de
contraintes à respecter portant sur la solution délivrée = ce qui fait la valeur de cette
solution : on parle parfois de la proposition de valeur.
OBJECTIF DE VALEUR = une finalité + quelques caractéristiques essentielles de la solution
Caractéristiques
essentielles
Finalité
Propriété à rechercher Contrainte à respecter ou piège à éviter
Trouver une solution concrétisant
un objectif de valeur
SOLUTION DELIVREEOBJECTIF DE VALEUR
Nous venons de voir que l’objectif de valeur fonde la pizza team : il n’y a pas de pizza
team sans objectif de valeur compris et accepté. Une pizza team ne doit pas commencer
à travailler sans objectif de valeur.
Nous précisons ici la formulation d’un objectif de valeur, mais il faut faire attention. Cette
formulation dépend du besoin amenant une pizza team. Il ne faut donc pas trop serrer la
manière de faire, mais comprendre l’essentiel.
L’essentiel est de donner de la liberté sur la solution, au moyen d’un cadre qui permet de
challenger la réflexion et l’action.
Un bon cadre est à deux niveaux.
1. On vise une finalité qui s’énonce de manière simple ; elle exprime ce à quoi il faut
toujours revenir pour avancer de manière sûre et trouver de bons arbitrages.
27 © Yphise
2. Cette finalité est précisée par les caractéristiques essentielles que doit respecter la
solution. Elles peuvent exprimer des propriétés à rechercher ou au contraire des
contraintes à respecter15.
15 Scrum fonctionne ainsi : 1. finalité d’un sprint = sprint goal ; 2. caractéristiques de la solution = sprint
backlog : contrainte à respecter = une spécification impérative (ex. règle de gestion à implémenter), propriété
à rechercher = une qualité portant sur une fonction (ex. simplicité pour l’utilisateur voulant faire telle action).
28 © Yphise
3. La liberté
3.4 Les scénarios d’usage
L’avancement sur un objectif de valeur nécessite de savoir le concrétiser.
Le meilleur moyen est de réfléchir en terme de scénarios d’usage (stories) de la solution ; c’est-à-
dire en se plaçant du point de vue du ou des acteurs directement concernés (user-centric).
Trouver une solution concrétisant
un objectif de valeur
SOLUTION DELIVREEOBJECTIF DE VALEUR
SOLUTION
La valeur est
concrétisée sur les
stories /scénarios
d’usage de la solution
Caractéristiques
essentiellesFinalité
Nous avons un objectif de valeur. La question est alors de savoir comment s’y prendre
pour avancer à partir de cet objectif de valeur ; c’est-à-dire pour le concrétiser en la
circonstance, en trouvant les idées, équilibres et compromis adaptés.
La manière de s’y prendre dépend là encore du besoin amenant une pizza team. Il y a
cependant une pratique à connaître car son utilisation est fréquente.
Il s’agit de réfléchir en terme de scénarios d’usage (stories) de la solution ; c’est-à-dire
de concrétisation de la valeur en se plaçant du point de vue du ou des acteurs
directement concernés. Ceci permet un centrage de la réflexion sur des personnes, avec
leurs attentes et capacités : c’est le meilleur moyen pour arriver à un résultat qui soit
effectivement satisfaisant.
La construction d’une expression de besoin par une suite d’ateliers fonctionne ainsi :
l’avancement se fait par l’étude des scénarios, en se posant sur chacun la question du
bon niveau de concrétisation de la valeur pour le ou les acteurs concernés. De même, la
bonne résolution d’un problème par une amélioration lean se fait en considérant la
situation concrète des acteurs touchés. Egalement, la bonne pratique en Scrum est de
concrétiser l’objectif de valeur (sprint goal) par une formulation de ce qu’il faut faire sous
forme de stories (items du sprint backlog).
Ces exemples montrent bien qu’on retrouve un même principe, qui peut être décliné sous
de multiples formes selon la situation.
29 © Yphise
4. Le débat
4.1 Les pratiques
4.2 La pensée de groupe
4.3 Le débat contradictoire
4.4 Le travail en atelier
LibertéRègle du jeu EngagementItérationDébat= + + +
30 © Yphise
4. Le débat
4.1 Les pratiques
Débat
Communication fluide, intense, transparente
Maitrise des dangers de la pensée de groupe
Conduite de débats contradictoires
Travail en atelier
! Les dangers de la pensée de groupe
LE sujet est les dangers de la pensée de groupe.
La maitrise repose sur trois lots de pratiques :
− comprendre les dangers de la pensée de groupe,
− mener un débat contradictoire,
− travailler en atelier.
31 © Yphise
4. Le débat
4.2 La pensée de groupe
Les dangers de la pensée de groupe
− Non dit. Faux consensus sur un sujet par non dit ; parce que considéré à tord comme
évident, faisant l’objet d’incompréhensions ou en raison d’informations trompeuses ou
fausses pour cacher quelque chose.
− Rejet du conflit. Non présentation d’un point, un argument ou un désaccord pour éviter un
conflit ou, plus simplement, par bienséance.
− Soumission. Acceptation de fait d’une opinion, parce qu’elle émane d’un ou plusieurs
participants considérés comme leaders ou représentant un pouvoir établi.
− Cristallisation. Toute discussion amène une phase de cristallisation de l’opinion : elle se
fige définitivement, souvent de manière brutale et rapide. Une fois passé ce point de
cristallisation, le groupe se met à utiliser tout fait nouveau pour conforter cette opinion ; il
se met à négliger ou déformer les informations qui pourraient la contrarier. Le danger est
lorsque cette opinion est erronée.
− Polarisation. Après discussion, un groupe a tendance à prendre des décisions plus
risquées ou radicales qu’avant ; les minoritaires ont tendance à se ranger à l’avis des
majoritaires.
! Les dangers de la pensée de groupe
Rejet du conflit SoumissionNon dit Cristallisation Polarisation
La réduction du risque
− La compréhension et la sensibilité de chaque participant aux travers de la pensée de groupe.
− Le fonctionnement à plat, entre égaux, de l’équipe ; et le détachement, une autonomie de
décision, de chaque participant vis-à-vis de sa hiérarchie.
− L’organisation de débats contradictoires permettant de factualiser et pousser la réflexion sur
les sujets amenant des équilibres ou des compromis sur lesquels il ne faut pas se tromper.
Une communication fluide, intense, transparente et des discussions pour trouver un
équilibre ou un compromis peuvent conduire à de mauvaises décisions, malgré la bonne
volonté et la compétence de chacun. On parle parfois de décision absurde16. C’est un
paradoxe qui a amené de nombreux travaux17.
Le réflexe courant est alors de dire que « il faut communiquer davantage », ce qui est
insuffisant et peut faire pire que mieux en renforçant les travers de la pensée de groupe.
Une pizza team est particulièrement fragile aux dangers de la pensée de groupe par sa
finalité et sa composition. Il faut avancer sur un objectif, ce qui amène des décisions qui
16 Christian Morel ‘Les décisions absurdes I et II’ Gallimard 2002 et 2012.
17 Depuis Milgram (1960) concernant la soumission à un pouvoir établi, puis Janis (1972) cherchant à
comprendre les erreurs de décision de l’armée américaine en différentes situations (Vietnam, Cuba, Pearl
harbour) par des groupes réunissant des experts reconnus pour leur compétence.
32 © Yphise
sont des équilibres ou des compromis pour les différents participants : la peur du conflit
et l’acceptation du point de vue de celui qui parle le plus fort peuvent faire des ravages18.
L’évitement des travers de la pensée de groupe est en trois points.
Le premier est la bonne compréhension et la sensibilité des participants, leur permettant
une prise de recul sur ce qui se joue dans tel échange ou discussion, ou au contraire
absence d’échange ou de discussion.
Le second concerne le fonctionnement et la liberté de l’équipe de sorte à éviter le risque
d’alignement sur l’opinion d’un leader ou d’un pouvoir établi. Le fonctionnement à plat,
entre égaux, et le détachement des participants, avec une certaine autonomie de décision
vis-à-vis de leur hiérarchie, sont essentiels pour ne pas induire un biais de pouvoir
dangereux19.
Le troisième est la capacité à organiser des débats contradictoires sur les sujets amenant
un risque de mauvaise décision. Ce qui amène un lot spécifique de pratiques...
18 C’est un travers que l’on constate dans un sprint de développement Scrum : la solution développée peut
comporter des faiblesses étonnantes malgré un bon objectif de sprint et une équipe compétente ; l’analyse
montre alors des travers dans les décisions prises liées à la pensée de groupe.
19 Chapitre ‘3. La liberté’.
33 © Yphise
4. Le débat
4.3 Le débat contradictoire
Les techniques du débat contradictoire pour pousser la réflexion
Il s’agit de prendre du recul sur un choix (ou option) amenant une décision pour le sécuriser ou au
contraire le reconsidérer.
− La question disputée. Faire rechercher par TOUS les arguments ‘pour’, puis ‘contre’.
Attention : il ne s’agit pas de faire parler ceux qui sont pour, puis ceux qui sont contre ; mais
de forcer une réflexion qui évite de se focaliser sur des questions de personne.
Avec, si nécessaire, la combinaison de différents points de vue sur ce choix.
− La mise à plat des conséquences. Faire rechercher par tous toutes les conséquences y
compris éloignées (dans le temps, le système d’information, l’organisation, etc.).
− La discussion de point d’inflexion. Faire rechercher par tous les éléments ou les
événements qui pourraient inverser le choix envisagé ; puis apprécier la probabilité ou la
plausabilité de ces éléments ou événements.
− L’étude des signaux faibles, c’est-à-dire les points qui jusqu’ici sont apparus comme
mineurs ou secondaires. Se poser la question : ne seraient-ils pas des signaux faibles
d’éléments ou d’événements significatifs à brève échéance amenant à reconsidérer le choix
envisagé ?
Débat contradictoire
La débat contradictoire vise à pousser la réflexion collective de sorte à ne pas prendre
une mauvaise décision liée aux dangers de la pensée de groupe.
On force l’expression de tous les arguments pour ou contre un choix (ou option) ; en
faisant en sorte que cette expression ne soit pas entachée d’un biais de pouvoir.
Pour cela, un débat contradictoire n’est pas un vote : il ne s’agit pas pour ceux qui sont
‘pour’ de donner leurs arguments, et de même pour ceux qui sont ‘contre’. Il s’agit de
demander à TOUS d’exprimer les arguments ‘pour’, puis à TOUS les ‘contre’. On n’oppose
pas les participants entre eux : on les met en situation collective de trouver et expliciter
tous les arguments ‘pour’ et ‘contre’. On organise ce qu’on appelle une question disputée.
Dans ce principe de question disputée, le succès repose sur la capacité à exprimer tous
les arguments pertinents. Il faut pour cela savoir aller au fond du sujet, c’est-à-dire ne
pas se contenter des arguments évidents ou établis. Il s’agit de dynamiser la réflexion
pour aller en profondeur. Ce qui se fait en la centrant lorsqu’utile sur la mise à plat des
conséquences éloignées, la discussion de point d’inflexion ou l’étude des signaux faibles.
34 © Yphise
Un débat contradictoire bien mené amène un consensus aisé à trouver, à condition que le
fonctionnement de l’équipe soit entre égaux avec une certaine autonomie de décision de
chaque participant vis-à-vis de sa hiérarchie.
Un débat contradictoire peut s’organiser à distance, sur une certaine durée, avec
consignation des arguments dans un registre numérique. Il est cependant préférable de
réunir les participants en atelier, ce qui amène un lot spécifique de pratiques...
35 © Yphise
4. Le débat
4.4 Le travail en atelier
Principe
Séance de travail approfondie (min 1/2 jour, plutôt 1 j ou +) réunissant l’équipe.
Finalité de trouver un bon résultat en poussant la réflexion par le débat, la confrontation des
points de vue, le questionnement de l’un par l’autre, afin de discerner l’essentiel du secondaire et
de favoriser de bons équilibres ou compromis.
Réussite
− Conduite en boites de temps de sorte à sortir la valeur utile en la circonstance ; même si on ne
va pas au bout de ce qui serait envisageable.
− Garantir l’expression par des tours de table ; garantir la compréhension, le consensus et
l’absence de non dit par l’utilisation intensive d’un tableau permettant une visualisation
partagée.
− Lorsque l’atelier amène plusieurs séances (v1, v2, etc.), centrer chacune sur le sujet dominant
pour assurer la convergence.
Atelier
Débat contradictoire
Un atelier est une séance de travail qui réunit l’équipe de sorte à trouver les bons
équilibres ou compromis sur les sujets à traiter.
Un atelier est toujours une contrainte forte de temps : on aimerait en avoir beaucoup
plus pour aller dans l’exhaustivité des sujets à traiter (ex. comité d’investissement,
atelier d’expression du besoin, CAB de mise en production).
C’est un mode de travail en ligne avec une finalité d’avancement sur un objectif de
valeur, nécessitant des décisions qui sont des équilibres ou compromis : la contrainte de
temps force une réflexion centrée sur ce qui fait de la valeur, par distinction avec des
points secondaires, et oblige à prendre des décisions, par distinction avec un travail qui
se contente d’une analyse de la situation.
Cette contrainte de temps est à tiroirs : la réussir nécessite de découper la séance en
boites de temps elles-mêmes conduites par ce qui fait de la valeur20.
20 Chapitre ‘5.3 Les boites de temps’.
36 © Yphise
Un atelier met l’équipe en responsabilité collective. Le danger est de ne pas aboutir en
raison du comportement individualiste de certains participants : il s’agit de « jouer
collectif ». Il est pour cela important de considérer que les participants sont égaux, sans
hiérarchie ni privilège. La conduite de l’atelier doit faire très attention à ce que l’écoute,
les débats et les restitutions mettent tous les participants sur un plan d’égalité. Ceci
amène couramment à limiter les interventions de certains tandis qu’il faut encourager
d’autres à s’exprimer. L’utilisation intensive d’un tableau pour une visualisation partagée
est également une clé de la dynamique collective.
Lorsque le travail à réaliser est trop complexe pour aboutir en une séance, il faut une
suite d’ateliers, c’est-à-dire une construction itérative. L’enjeu est alors la gestion de la
convergence21.
21 Chapitre ‘5. L’itération’.
37 © Yphise
5. L’itération
5.1 Les pratiques
5.2 La combinaison chaud et froid
5.3 Les boites de temps
5.4 Le centrage des itérations
LibertéRègle du jeu EngagementItérationDébat= + + +
38 © Yphise
5. L’itération
5.1 Les pratiques
Itération
Construction itérative de la valeur
par combinaison de boites de temps
v1 v2 v3
SOLUTION DELIVREE
v4
OBJECTIF DE VALEUR
Recul à froid sur le résultat intermédiaire
Construction itérative de la solution
Travail par boites de temps
! Le risque de divergence d’une construction itérative d’une solution
LE sujet est la convergence d’un travail mené par un objectif de valeur ; c’est-à-dire avec
des inconnues sur la solution et la manière de l’obtenir qui empêchent une logique de
planification. On avance donc pas à pas, de manière itérative. Le risque est de tourner en
rond ou au contraire de partir dans tous les sens au fur et à mesure des discussions.
La maitrise de la convergence repose sur trois lots de pratiques :
− la combinaison chaud et froid,
− les boites de temps,
− le centrage des itérations.
39 © Yphise
5. L’itération
5.2 La combinaison chaud et froid
La création de valeur en situation d’inconnues nécessite une prise de recul à froid sur chaque
résultat intermédiaire.
C’est une charge de travail modeste mais indispensable à la maitrise de la convergence. Il s’agit
de revoir ce qui a été fait ou décidé pour mettre le doigt sur des faiblesses ou des opportunités à
considérer dans la suite.
Construction itérative de la valeur
par combinaison de boites de temps
v1 v2 v3
SOLUTION DELIVREE
v4
OBJECTIF DE VALEUR
Recul à froid sur le résultat intermédiaire
Voici une pratique basique, essentielle, et pourtant souvent négligée parce
qu’incomprise : la création de valeur en situation d’inconnues nécessite une prise de recul
à froid sur chaque résultat intermédiaire.
C’est une idée de fond d’un développement par enchainement de sprints ; un sprint est
un travail intense permettant de concrétiser un objectif de valeur en quelques semaines :
suit une prise de recul sur le résultat afin d’y voir clair sur la bonne définition du prochain
sprint. En situation d’inconnues, l’erreur à ne pas faire est d’augmenter la durée des
sprints car on diminue alors la fréquence de cette prise de recul, ce qui se révèle être
contre productif. Les équipes expérimentées en Scrum privilégient pour cette raison des
sprints courts.
De même, lorsqu’un travail est réalisé par une suite d’ateliers : le bon avancement
nécessite que chaque participant prenne du recul à froid sur le résultat après chaque
atelier pour apporter en entrée du suivant les éléments qui permettent de l’orienter
correctement. C’est en particulier dans cette réflexion à froid qu’apparaissent des points
ou des erreurs de raisonnement que les travers de la pensée de groupe ont générés ou
laissés passer pendant l’atelier.
L’erreur à éviter absolument est que les participants considèrent que le travail se résume
aux ateliers, c’est-à-dire qu’ils arrivent dans un atelier au point de sortie du précédent.
La prise de recul à froid est une charge de travail a priori modeste. Il ne s’agit pas de
développer ce qui a été fait pendant l’atelier, le sprint ou autres, mais de revoir ce qui a
été fait ou décidé pour mettre le doigt sur des faiblesses ou des opportunités à considérer
dans la suite.
40 © Yphise
5. L’itération
5.3 Les boites de temps
Une boite de temps est une contrainte de temps que l’on se donne, pour forcer à se tenir sur
l’essentiel ; c’est-à-dire à avancer au regard d’une valeur, en cherchant à reporter les points
secondaires.
Une boite de temps est un dispositif à tiroirs : on la décompose autant que nécessaire pour arriver
à une granularité maitrisable.
Attention : cette décomposition doit être une dynamique d’organisation du travail au fur et à
mesure de l’avancement et de l’identification des difficultés ou des opportunités ; ce n’est pas une
planification a priori.
tps
Boites de temps
vx
Avancer par boites de temps (time boxing) est LE principe de travail lorsqu’on ne sait pas
détailler un résultat et planifier le mode opératoire de son obtention ; mais qu’il faut au
contraire avancer sur un objectif de valeur amenant des débats ou une construction
itérative.
Une boite de temps est une contrainte de temps que l’on se donne, pour forcer à aller sur
une décision qui est un équilibre ou un compromis. On est donc obligé d’aller à
l’essentiel, c’est-à-dire à avancer au regard d’une valeur, sans se perdre dans du
secondaire : on cherche à reporter les points secondaires.
Le travail en boite de temps est aussi une condition pour ne pas épuiser les participants
dans une situation de travail intense, notamment lorsqu’il faut mener des débats
amenant des équilibres ou des compromis. Nous insistons : c’est une soupape de sécurité
pour ne pas s’enfoncer dans les travers de la pensée de groupe et le risque de troubles
psychosociaux.
Une boite de temps est un dispositif à tiroirs : on la décompose autant que nécessaire
pour arriver à une granularité maitrisable. Cette décomposition n’est pas une planification
a priori, mais une dynamique d’organisation du travail au fur et à mesure de
l’avancement et de l’identification des difficultés ou des opportunités. Nous insistons : il
ne faut pas tomber dans le travers d’une logique de planification.
Ainsi, un atelier est une boite de temps, dont la bonne conduite se fait en identifiant à
tout moment ce sur quoi il est essentiel d’avancer, et en se donnant un certain temps
pour en débattre. L’erreur à éviter est de dériver sur une planification a priori de l’atelier
41 © Yphise
qui découpe le travail en sujets, pris à la suite comme on enfile des perles d’un collier : il
y a au contraire une dynamique qui fait que la boite de temps à venir dépend de celle en
cours ; une boite de temps donne le relief permettant de choisir et centrer la suivante au
regard d’une valeur, compte tenu de la situation précise.
De même, Scrum est entièrement construit sur une logique de boites de temps. Un sprint
est une boite de temps qui va se décomposer en temps opportun et avec la granularité
maitrisable au fur et à mesure des points d’avancement (daily scrum).
Le travail en boite de temps est ainsi une technique simple, mais à utiliser avec doigté.
42 © Yphise
5. L’itération
5.4 Le centrage des itérations
La convergence d’un travail itératif conduit par un objectif de valeur, nécessite de centrer chaque
itération sur le bon sujet dominant.
On a intérêt à débuter par les sujets importants qui sont difficiles à monter à maturité, de sorte à
disposer de plusieurs itérations et prises de recul.
sujet 3
sujet 1
sujet 2
v1 v3v2 v4
ébauche avancé très avancé définitif
Un travail itératif conduit par un objectif de valeur amène la possibilité de considérer tout
sujet à tout moment et certains retours arrière entre itérations. Sinon, cela signifie qu’on
n’a pas besoin d’agilité : on sait séquencer et planifier la réflexion et l’action.
Nous insistons : le mélange des sujets traités et la possibilité de revenir en arrière sont
intrinsèques à un mode de travail agile ; mais il faut savoir les maitriser, c’est-à-dire
sécuriser un avancement dans un certain flou.
LA pratique pour cela est de savoir centrer chaque itération sur LE sujet dominant pour
avancer au mieux. On n’interdit pas que les autres sujets viennent sur le tapis ou que le
sujet dominant soit remis en question ultérieurement ; mais les débats et l’action sont
centrés sur le sujet dominant.
Ainsi, la construction d’un business case amène à construire les gains et le scénario de la
maitrise : on parle aussi d’opportunité et de faisabilité. La bonne manière d’avancer est
de centrer la ou les premières itérations sur la construction de l’opportunité, pour établir
ensuite les moyens d’une faisabilité maitrisée. Mais il est évident que les réflexions sur
l’opportunité ne peuvent faire totale abstraction des questions de faisabilité ; de même, il
est fréquent que les réflexions sur la maitrise de la faisabilité amènent à retoucher les
conclusions sur l’opportunité.
Nous insistons : tout travail en agilité avec des itérations doit être mené en ayant les
idées claires sur la dominante de chacune afin de sécuriser l’avancement.
Dans ce contexte, on a intérêt à débuter par les sujets importants qui peuvent être lents
à monter à maturité ; c’est-à-dire sur lesquels il faut challenger la réflexion et l’action
des participants. On entre par ce qui est structurant et difficile, de sorte à disposer de
plusieurs itérations et prises de recul.
Ainsi, la construction d’un plan d’investissement sur un SI nécessite de qualifier chaque
demande en urgence, profondeur et gravité. La bonne manière d’avancer est de
43 © Yphise
commencer par la gravité qui est le sujet le plus difficile en terme de consensus à
trouver ; à l’inverse, la profondeur est une question plus factuelle et simple à traiter ;
l’urgence se situe entre les deux. La première itération a donc pour dominante la gravité,
une seconde l’urgence, vient ensuite le traitement de la profondeur.
44 © Yphise
45 © Yphise
6. L’engagement
6.1 Les pratiques
6.2 Les facteurs d’engagement
6.3 Les protocoles de points d’engagement
Règle du jeu ItérationDébat= + + +Liberté Engagement
46 © Yphise
6. L’engagement
6.1 Les pratiques
Engagement
Equipe à plat, entre égaux
Protocole de points d’engagement
Equipe à plat
Point d’engagement
! La fragilité de l’engagement
L’engagement des participants est a priori bien enclenché lorsque sont compris et
maitrisés la liberté, le débat et l’itération. L’inverse est également vrai : l’engagement ne
peut être satisfaisant si ces trois ingrédients sont défaillants.
Il faut donc considérer ici l’engagement comme un complément de ce qui précède.
L’importance de ce dernier ingrédient varie selon que la pizza team a pour objectif de
produire une réflexion ou une réalisation. Il prend toute son importance lorsque chaque
participant porte la responsabilité de tâches à faire (ex. écriture de code par un sprint).
L’engagement des participants d’une pizza team doit considérer le besoin d’une
dynamique au fur et à mesure des événements. On est dans un environnement où la
logique de planification ne fonctionne pas, avec des participants qui ne sont pas
forcément dédiés à temps plein. Il faut donc que l’équipe s’organise elle-même ; à plat,
de manière collégiale, c’est-à-dire sans chef passant son temps à planifier, à négocier
avec des hiérarchies et à contrôler.
La maitrise repose sur deux lots de pratiques :
− comprendre les facteurs d’engagement,
− utiliser un protocole de points d’engagement.
47 © Yphise
6. L’engagement
6.2 Les facteurs d’engagement
Les facteurs d’engagement
Pour maximiser l’engagement d’une personne sur la réalisation d’un acte (il faut respecter tous
les facteurs) :
− la déclarer libre de son choix (même si les circonstances font que cela est une illusion) ;
− faire en sorte que l’acte soit important pour la personne dans ses conséquences et l’effort
demandé, tout en restant faisable ;
− faire en sorte que l’engagement soit le plus visible possible : public, explicite et irrévocable ;
− attribuer explicitement à la personne une qualité spécifique pour le réussir (qualité qui peut
être un leurre) ;
− éviter les justifications externes : promesses de récompenses ou punitions ;
− multiplier les occasions d’engagement sur des actes comparables.
La meilleure dynamique d’engagement pour un mode de travail agile s’obtient lorsque la définition
de chaque engagement respecte tous les facteurs d’engagement.
! La fragilité de l’engagement
Comment obtenir l’engagement d’une personne à réaliser un acte qu’on attend d’elle
(pouvant comporter des contraintes de date ou de budget) ?
Ce sujet a fait l’objet de multiples recherches : on sait aujourd’hui précisément ce qu’il
faut faire et éviter. C’est simple : le meilleur taux de réussite s’obtient au moment de la
définition de l’engagement, lorsque cette définition respecte les facteurs d’engagement.
Ces facteurs établissent les circonstances qui maximisent l’engagement22.
Attention : le respect de ces facteurs n’est pas une garantie de réussite à tous les coups ;
il n’est pas non plus un moyen de rendre faisable ce qui ne l’est pas. Il définit la posture
permettant d’obtenir la meilleure dynamique d’engagement lorsqu’un mode de travail
agile est nécessaire.
A l’inverse, la bonne tenue des engagements décroit avec la négligence d’un ou plusieurs
facteurs : tous les facteurs interviennent.
Ces facteurs nécessitent une équipe à plat, sans chef planifiant pour les différents
participants. Ils se concrétisent par des points d’engagement : il faut donc maitriser les
protocoles de points d’engagement, ce qui amène un lot spécifique de pratiques...
22 Une référence d’un abord facile et développant largement les exemples en entreprise : ‘La soumission
librement consentie’ (Beauvois et Joule) PUF 1998 et rééditions régulières depuis.
48 © Yphise
6. L’engagement
6.3 Les protocoles de points d’engagement
Principe
Point d’engagement (mêlée) bref et à haute fréquence réunissant l’équipe.
Avec libre choix par chaque participant de ses tâches parmi celles à faire : arbitrages d’affectation
ou de réaffectation si indispensable.
Réussite
− Bonne définition des tâches : une tâche correspond à un résultat tangible ; sa taille et sa
complexité sont cohérentes avec l’autonomie de maitrise des participants ; les critères de
qualité (définition de terminé) sont établis et compris.
− Affichage public par tâche : « état (à faire, en cours, terminé) - responsable - engagement
prévu - réalisé une fois terminée ».
− Vue synthétique de la vélocité de l’équipe : « charge réalisée - charge restant à faire ».
− Point de situation et libre choix de ses tâches par chaque participant.
Equipe à plat
Point d’engagement
Un protocole de points d’engagement vise à concrétiser les facteurs d’engagement de
manière adaptée à la pizza team.
Les pratiques usuelles de tenue du point quotidien de Scrum constituent une bonne
référence. Cette manière de faire fonctionne parce qu’elle concrétise bien les facteurs
d’engagement.
Mais il faut faire attention : l’important est bien de partir des facteurs d’engagement ; le
protocole qui vise à les concrétiser est à adapter à la circonstance.
Ainsi, trouver le bon niveau d’exigences de reprise d’un SI à l’occasion d’un projet se fait
par une suite d’ateliers. Il est fréquent que des investigations supplémentaires soient à
mener entre deux ateliers23. Il faut alors que chacun comporte un point d’engagement qui
permette d’engager correctement les participants concernés.
23 Investigations qui se concrétisent souvent par une suite d’ateliers dédiée à un sujet.
49 © Yphise
8. Annexe : exemples
Gestion de problème
Mise en production
Scrum
Business case
Etc.
Expression de besoin
Plan de reprise d’un SI
Compétitivité d’un SI
Solution recherchée Le bon niveau d’exigences de reprise.
Pizza team Elaboration en atelier(s) du bon niveau d’exigences de reprise, avec débat
contradictoire réunissant compétences de maitrise d’œuvre et d’ouvrage.
Solution recherchée Résolution d’un problème.
Pizza team Amélioration lean : touver une avancée en atelier réunissant les centres de
compétences concernés ; itérations si nécessaire ; mise en œuvre et évaluation de
cette avancée pour trouver une nouvelle avancée en atelier.
Elaboration en atelier(s) du bon niveau d’exigence de reprise, avec débat contradictoire réunissant
Solution recherchée Décision de mise en production de changements.
Pizza team CAB (Change Advisory Board) : atelier réunissant les parties prenantes pour
prendre des décisions d’acceptation ou de rejet de changements.
Solution recherchée Logiciel.
Pizza team Développement en quelques semaines par une équipe devant atteindre un objectif
de valeur (sprint goal précisé par un sprint backlog) ; définition du contenu de
sprint (planning meeting) ; engagement quotidien (daily scrum).
Solution recherchée Construction d’un bon business case.
Pizza team Construction itérative des gains et du scénario de la maitrise du business case (=
construction de l’opportunité et de la faisabilité) ; débat contradictoire par un
comité d’investissement à chaque itération.
Solution recherchée Expression de besoin permettant un bon projet.
Pizza team Construction itérative du besoin en ateliers réunissant les parties prenantes en
responsabilité collective ; conduite des ateliers par la discussion des scénarios
d’usage (stories).
Solution recherchée Construction d’un bon plan d’investissement.
Pizza team Compréhension et qualification (gravité, urgence, profondeur) des opportunités ou
besoins d’investir sur un SI en ateliers réunissant les parties prenantes en
responsabilité collective.
Cette liste montre deux points24.
− Le besoin se trouve dans toutes les disciplines de l’informatique.
24 Voir sur chaque sujet les études correspondantes du Portefeuille.
50 © Yphise
− Il est toujours localisé, au sens où il s’inscrit dans des processus pouvant fonctionner
ailleurs selon un mode de travail administré : une pizza team est une bulle agile dans
un environnement qui peut avoir une autre logique de fonctionnement, pour de
bonnes raisons25.
25 Etude « Le défi de l’informatique agile ».