Un guide de Survie

lAdoption ou
Transformation Agile :
Travailler avec la Culture
dune Organisation

Michael Sahota

Prface par Jurgen Appelo et Henrik Kniberg

1
Cet ouvrage de Michael Sahota est mis disposition selon les termes de
la licence Creative Commons Attribution - Pas dUtilisation Commerciale -
Partage dans les Mmes Conditions 3.0 France.

Ce qui veut dire que vous tes libre dutiliser le contenu de ce livre (aussi
bien le texte que les illustrations). Tout ce que vous avez faire, cest :

1 Inclure une rfrence Agilitrix ou Michael Sahota. Vous pouvez

par exemple utiliser le logo Agilitrix (voir en haut de cette page) ou
tout simplement crire "Merci Michael Sahota".

2 Inclure le logo Creative Commons ou utiliser les lettres CC pour

dsigner creative commons.

3 S'il s'agit d'une page web, veuillez ajouter un lien vers le site de
lauteur : http://agilitrix.com/.

Si vous souhaitez inclure du contenu dans un produit commercial (pour

de la vente), veuillez demander la permission lauteur.

2
Prface par Jurgen Appelo
Tous les modles sont utiles mais certains chouent plus rapidement que
d'autres. Cest ma propre adaptation de la clbre citation de George Box
Tous les modles sont faux mais certains sont utiles.

Dans ce petit mais prcieux livre, Michael Sahota donne au lecteur de

nombreux modles utiles pour travailler avec des organisations Agiles et
des organisations qui tentent de devenir Agile. Le livre de Michael m'a
appris quil est souvent ncessaire de mener une transformation qui
savre tre beaucoup plus difficile raliser quune simple adoption.
Apprendre faire un bon caf est une adoption. Devenir un barista
(sommelier du caf) est une transformation. Une adoption ne modifie
que ce que vous faites. Une transformation modifie ce que vous tes.

Bien sr, cette distinction est juste un autre modle, mais elle savre tre
trs utile. Quand nous voulons changer le monde du dveloppement
logiciel, nous devons apprendre transformer la culture
organisationnelle. Il ne suffit pas de se contenter d'adopter certaines
pratiques. Je l'entends presque tous les jours. Dans mes cours, des
confrences, et lorsque je profite d'un caf itinrant avec les praticiens
agiles dans les villes que je visite travers le monde. Les gens ne luttent
pas tellement avec l'adoption de pratiques Agiles. Ils ont du mal avec le
passage l'tat d'esprit Agile, parce que beaucoup de cultures
organisationnelles y rsistent activement.

De la littrature sur la meilleure gestion du changement, j'ai appris que le

changement de culture organisationnelle ne peut tre conduit avec un
simple plan en 5 tapes. Il y a rellement beaucoup de travail. Cela
ncessite la comprhension de la culture actuelle, l'application de
diffrents modles, l'adaptation des ides nouvelles aux contextes
traditionnels, la rduction des cycles de retour (feedback), la prise en
compte la fois des gens et de leur environnement, lalternance entre
changement continu et changement radical, et des exprimentations
dans un contexte donnant droit lerreur. Et beaucoup de caf.

3
Heureusement, Michael a crit ce livre pour nous rendre la vie un peu
plus facile. Les diffrents modles qu'il dcrit ne peuvent pas toujours
tre justes. Mais partir de la pense complexe, nous pouvons
apprendre quil nest possible datteindre une bonne comprhension d'un
problme complexe quen utilisant de multiples perspectives incompltes.
De nombreux modles faibles, ensemble, peuvent renforcer
considrablement notre comprhension du sens.

Lhistoire de Michael dans ce livre est courte, mais est trs sense. J'ai
dj adopt certaines de ses ides dans mes cours. Je dirais mme que
ce livre a un peu transform ma pense.

- Jurgen Appelo

4
Avant-propos par Henrik Kniberg
Quand jai particip ma premire confrence Agile, jtais bloui par la
prsence des Gourous - les personnes qui dfinissaient lAgilit et qui
crivaient les livres. Mais, en coutant ce quelles disaient rellement, jai
ralis mon grand dsarroi quelles disaient des choses diffrentes et
mme parfois ntaient pas daccord entre elles. La grande leon que jen
ai tir t: Zut, il va falloir que je me fasse mon ide moi mme !.
couter les Gourous, lire les livres, mais se faire soi mme son ide.

Cependant, se faire son ide ne signifie pas ignorer des annes de

connaissances accumules. Cela signifie se construire une boite outils
personnalise, un rpertoire doutils et de modles de pense pour vous
aider comprendre le monde qui vous entoure. Sans cette boite outils
vous tes la merci de votre instinct, qui est un grand outil mais qui ne
vous emmne pas trs loin.

Michael nous a fait une grande faveur, il a pris les essences de nombreux
modles et livres sur le changement organisationnel, et les a condenses
en un aperu illustr, terre terre, qui est immdiatement applicable par
nimporte quel coach, manager ou autre agent du changement. Ce livre a
un rapport signal/bruit tonnamment lev. Il va directement au but, et au
lieu de se perdre dans les dtails de chaque modle, Michael fournit une
description de haut niveau (en quoi consiste le modle et quand
lappliquer) et une rfrence pour en lire plus.

Ce livre est rafrachissant parce que Michael ne se retient pas, il remet en

question beaucoup dhypothses largement acceptes parmi nous les
Coach Agiles, et nous dit essentiellement Voici pourquoi vous et moi
sommes cot de la plaque, et comment nous pouvons ltre moins !.
Quelque fois une claque amicale dans la figure est ce dont nous avons
besoin pour rester alerte !

Et, pour tout garder ancr dans la ralit, il fournit plein dexemples
concrets et dtudes de cas, mme une check-list pratique ! Un bon

5
quilibre entre la thorie (comprendre le Pourquoi), et la pratique
(comprendre le Comment)

Une chose que jai appris en tant que coach et agent du changement, est
que les choses ne se droulent jamais comme prvu (et mme quand
cest le cas, cela mme nest pas prvu...). Quelques fois une longue
intervention de coaching sur site se termine par un grand retour
lAncienne Mthode en un an. A linverse, quelques fois un court
sminaire dinspiration devient la graine qui la fin changera toute
lorganisation. Quelques fois, djeuner avec la bonne personne au bon
moment a un plus grand impact que des annes daide et de coaching.

Le livre de Michael fournit un moyen de comprendre le hasard.

Parce que ce nest pas du hasard, cest juste que cest compliqu.

Merci Michael de dcomplexifier un peu le monde pour nous !

-Henrik Kniberg

6
Remerciements
Si jai vu plus loin, cest parce que je me suis juch sur les paules de
gants. - Isaac Newton

Je tiens remercier Henrik Kniberg qui a tant contribu la communaut

Agile avec ses documents open source et m'a inspir pour crire un
eBook gratuit afin de rendre la pareille. J'apprcie galement le fait quil
ait pris le temps d'crire l'une des prfaces.

Je tiens remercier les participants aux ateliers ayant utilis les premiers
jets de ce document. XPToronto, SoCal Lean Kanban, Agile Tour Toronto
et Agile Nouvelle-Angleterre. Vos commentaires, les dfis et les rflexions
ont contribu de faon incommensurable lcriture de ce livre.

Merci toutes les personnes qui ont lu mes billets tout au long de lanne
2011 sur ce sujet et fourni de prcieux commentaires.

Un grand merci Michael Spayd pour mavoir fait dcouvrir le modle de

culture de Schneider et pour avoir men une enqute sur les Agilistes.

De toute vidence, ce travail naurait pas exist sans la diffrentiation

entre ladoption et la transformation de Mike Cottemeyer.

Merci l'quipe de relecture pour ses retours : Chris Williams, Irne

Kuhn, Armond Mehrabian, Krishan Mathis, Bernie Jansen, Ed Willis, Eric
Willeke, Karl Scotland, Sabine Canditt, Todd Charron, Bob Sarni. Olaf
Lewitz en particulier, mrite une distinction en fournissant une quantit
extraordinaire de prcieux commentaires, questions et dfis.

Je tiens remercier ceux qui ont directement contribu ce travail ainsi

qu la relecture : Olivier Gourment pour sa contribution un cas dtude,
Jeff Anderson, Olaf Lewitz, Jon Stahl, Karl Scotland et Alexei Zheglov
pour leur partage de dfis et visions alternatives en annexe.

7
Je tiens galement remercier Alistair McKinnell, Jason Little, Declan
Whelan pour leurs retours sur larticle Methods & Tools qui fait lobjet
dun chapitre de ce livre, et John McFadyen et Dave Snowden pour
leurs retours sur la partie Cynefin.

Je suis trs reconnaissant vis vis de Jurgen Appelo qui a pris le temps
d'crire une prface malgr son planning charg.

Et bien sr, un grand merci ma fille Scarlett, qui a fourni les dessins
originaux du puzzle et de la transformation en papillon.

Ouah ! Mme un petit livre comme celui-ci bnficie de beaucoup d'aide.

- Michael Sahota

8
Remerciements (Seconde Partie)
Je suis profondment reconnaissant vis vis de toute l'quipe de
traduction pour avoir donn de leur temps afin de rendre ce livre
accessible la communaut francophone. Je me rjouis de cette
traduction tant donn que ma mission est d'aider autant de personnes
que possible trouver une voie heureuse et fructueuse avec lAgilit. J'ai
demand chacun des membres de l'quipe d'inclure une courte
biographie. Veuillez prendre un moment pour apprendre connatre les
gens qui vous ont apport ce livre.

- Michael Sahota

9
Par ordre alphabtique :

Alfred Almendra

Alfred est scrum master et coach agile. Il aide les

quipes ravir leurs clients, et accompagne les
entreprises dans leur transformation culturelle. Les
ingrdients quil utilise sont : une dmarche empirique
damlioration continue, les jeux agiles, et la
visualisation. http://atelierlogiciel.wordpress.com

Fabien Bataille

Aprs 15 ans passs dans lindustrie logicielle en

aronautique puis dans les tlcoms, o il subit les
diffrentes modes de management du logiciel, Fabien
dcouvre enfin lAgilit en 2010. Il a alors limmense
chance daccompagner une quipe de 10 personnes
dans sa transformation vers lagilit. Fabien a t certifi
scrum master par Jeff Sutherland en 2012. www.agile-lean-et-
compagnie.com

Frdric Faure

Ayant expriment la plupart des mtiers de lingnierie

logicielle en socit de service, Frdric dcouvre
lagilit en 2006. Depuis cette date, il essaie de mettre
en oeuvre et de transmettre les valeurs et principes
agiles aux quipes au sein desquelles il travaille. Vous
pouvez le suivre sur twitter @ffaure32

10
Florent Lothon

Florent est coach et formateur Agile quand il nest pas lui

mme dans les tranches. Sur son site (LAgiliste), il
partage ses connaissances. Son but : Contribuer
apporter davantage de plaisir au travail et de meilleurs
rsultats. Pour lui, a ne fait aucun doute, les deux sont
troitement lis. http://www.agiliste.fr

Nathalie Phung

Cest au sein dun dpartement de recherche et de

dveloppement dans le domaine des Telecom que
Nathalie a commenc son immersion dans le monde
agile en 2005. Aprs plusieurs annes de pratique en
tant dingnieur de dveloppement agile et Scrum
Master, elle conseille et accompagne aujourdhui les
entreprises et les quipes projet dans la dcouverte et la
mise en place de l'Agilit en tant que Coach et formateur agile. Pour
Nathalie, chaque projet agile est une passionnante aventure humaine !

Pascal Rieux

Pascal dcouvre lagilit via Scrum en 2008, aprs

presque vingt ans dans le monde du dveloppement
logiciel, pour lindustrie et les tlcoms. Scrum Master
depuis cette date, et membre de lassociation Agile-
Toulouse depuis 2010, il aide actuellement des quipes
de R&D dans lappropriation des pratiques et des
concepts de lagilit.

11
Table des matires
Prface par Jurgen Appelo........................................................................3
Avant-propos par Henrik Kniberg..............................................................5
Remerciements.........................................................................................7
Introduction.............................................................................................15
Partie 1: LAgilit en situation de crise.....................................................17
Lchec de lAgilit est largement rpandu..........................................17
LAgilit est voue lchec.................................................................19
La Culture est le dfi n1 de ladoption Agile.......................................21
Partie 2: Culture Agile.............................................................................23
LAgilit nest pas un processus - elle dfinit une Culture....................23
Comprendre la Culture au travers du modle de Schneider................24
La Culture Agile concerne la Collaboration et le Dveloppement
personnel.............................................................................................27
Le manifeste et les principes Agile dfinissent la Culture Agile........28
Approche Analytique (Pour les curieux)...........................................29
Le Modle de Culture Nous Permet de Poser des Questions Utiles 30
La Culture Kanban est en phase avec le Contrle...............................31
Attendez une minute - Kanban est Agile, nest-ce pas ?..................33
Kanban est un Bon Outil..................................................................33
Kanban tel un Cheval de Troie ou une Drogue Passerelle...............34
Kanban + Agile = Agile.....................................................................34
Le Craftsmanship relve de la Comptence........................................35
Pourquoi devons-nous faire attention ?............................................36
Travailler avec Votre Culture................................................................37

12
 Comprendre la Culture.....................................................................39
Travailler avec dautres Cultures......................................................40
Adaptateurs de Culture....................................................................40
Comment Changer une Culture est une autre Histoire.....................44
Rsum...............................................................................................45
Partie 3: Guide de survie lAdoption et la Transformation.....................46
Dfinissons Adoption et Transformation..............................................46
Un modle pour comprendre lAdoption et la Transformation..............46
Adoption des pratiques Agile dans une Culture Inadapte..................48
Eviter le Manifeste Agile et Scrum....................................................49
Modles dadoption de lAgilit.........................................................51
Devenir Agile dans un monde imparfait............................................51
tude de cas : Une Grande Entreprise de la Finance......................52
Adoption et Transformation dans une Culture Compatible...................53
Orienter avec le Manifeste Agile et Scrum.......................................54
Le Changement Sans Peur..............................................................55
Inspecter et Adapter avec lEquipe de Transition dEntreprise..........56
ADAPT.............................................................................................57
Conteneurs, Diffrences et changes..............................................59
Modle Cynefin................................................................................60
Quand utiliser le modle Cynefin.....................................................62
tude de Cas d'Adoption Agile dans une Culture Compatible..........62
La Transformation Agile.......................................................................64
La Transformation Agile est-elle Possible ?......................................65
La Transformation Agile par Accident Endommage les Entreprises. 67
Modle de Kotter pour le Changement Organisationnel...................70

13
 Conduite de la Transformation.........................................................72
Autres Approches du Changement Organisationnel............................75
Et aprs ?................................................................................................76
Checklist pour les agents du changement...........................................76
References..............................................................................................78
A propos de lAuteur................................................................................85
Autres vues et Opinions..........................................................................86
La Culture comme un Contexte pour ladoption et la transformation
Agile.................................................................................................86
Votre Kanban nest pas mon Kanban...............................................88
Kanban est plus quune simple Culture du Contrle.........................88
Kanban concerne aussi la Transformation !.....................................90
Scrum versus Kanban......................................................................91

14
Introduction
La communaut agile souffre dune confusion importante entre les
principes dadoption et de transformation. Malheureusement, les agents
du changement parlent de ladoption de lagilit et non de la
transformation de la culture dentreprise pour encourager ltat desprit
Agile. La triste consquence de ce strabisme est que les agents du
changement entreprennent une transformation ponctuelle sans vritable
adhsion ou sans en matriser les consquences organisationnelles. Et le
rsultat est un chec.

Il y a peu de modles dans notre communaut pour aider les agents du

changement comprendre quand utiliser ladoption et quand utiliser la
transformation. Bien sr, il existe une base substantielle de
connaissances sur les techniques spcifiques ladoption ou la
transformation, mais peu de donnes pour aider les agents du
changement choisir quelle orientation prendre et pourquoi la prendre.

Ce guide de survie fournit un cadre simple pouvant tre utilis pour

comprendre et entreprendre le travail de mutation Agile. Ce cadre peut
aussi bien tre utile si vous travaillez avec la mthode Kanban ou bien
dans la mouvance Software Craftsmanship. Je lai trouv moi-mme
extrmement utile, tout comme les participants aux sessions auxquels je
lai enseign. Ce cadre ma aid sortir de lincomptence inconsciente
en tant quagent du changement et devenir conscient des choix que je
fais. Cette prise de conscience ma permis de dbuter lascension vers la
comptence.

La premire tape pour prendre la mesure dun problme est de

reconnatre que vous en avez un. Le problme auquel nous sommes
actuellement confronts est le niveau lev dchecs dans les entreprises
adoptant lAgilit ou vivant une transformation Agile. Certaines des
causes racines de ce problme sont abordes dans la premire partie de
ce livre pour justifier le besoin d'un guide de survie.

15
Si vous ne grez pas la culture, cest elle qui vous gre. La plupart des
checs dans ladoption de lagilit sont le rsultat dune absence de
comprhension de la culture organisationnelle de lentreprise. La
deuxime partie de ce livre explique comment utiliser la culture
organisationnelle pour comprendre les mouvements Agile, Kanban et
Software Craftsmanship. Il explique galement comment utiliser le
modle de culture de Schneider pour valuer la culture de votre
organisation et fournit des faons de travailler efficacement avec cette
dernire.

La troisime partie de ce livre propose un cadre pour comprendre et

choisir les approches dadoption et de transformations appropries pour
une varit de contextes. Il prsente un aperu des mthodes cls
dadoption et de transformation. Le cadre propos fournit la connaissance
de base pour apprhender la mutation Agile dans les entreprises.

16
Partie 1: LAgilit en situation de crise
Lchec de lAgilit est largement rpandu
Les efforts d'adoption et de transformation Agile connaissent des taux
d'chec levs dans de nombreuses industries et organisations. 84% des
personnes interroges dans l'Enqute sur le Dveloppement Agile ont
dclar avoir connu un projet Agile en situation dchec [VersionOne].
Seulement 16% des rpondants n'avaient pas connu d'chec.

J'ai effectu mes propres recherches informelles sur ce sujet. J'ai

demand aux gens d'valuer sur une chelle de 0 5 le degr de succs
qu'ils ont eu avec lAgilit, o 0 indique labsence de succs et 5 que tous
les projets ont t couronns de succs. La moyenne sur environ 130
rpondants rpartis en 4 sessions diffrentes tait de 2,7. Pas brillant.
Voir les rsultats du sondage informel d'chec ci-dessous sous forme de
graphiques et de tableaux. Veuillez noter que les personnes se sont auto-
values en fonction de leur propre dfinition de russite et chec.

On peut observer une forte cohrence des moyennes obtenues, avec des
variations mineures. Je ne pense pas que lon puisse tirer des
conclusions claires en ce qui concerne les carts ou tendances.

17
18
LAgilit est voue lchec
Prenons quelques raisons courantes d'chec et voyons pourquoi - en tant
que concept relativement nouveau - lAgilit semble voue aux
problmes.

Prenons la position de lAgilit sur la courbe dadoption dune technologie

du Crossing the Chasm (Passer lAbme) de Geoffrey A. Moore. Le
diagramme ci-dessous montre lAgilit traversant le gouffre. Dans les
premires tapes, les visionnaires fournissent un soutien solide et ont
une tolrance leve au changement.

Une des conditions cl de succs auprs de la majorit prcoce est le

"produit complet" constitu de l'ide centrale entoure de tout le
ncessaire pour assurer le succs, comme illustr ci-dessous. Certains
lments du produit dans son ensemble sont prsents, tandis que
d'autres sont absents ou mme non dfinis. L'absence continue du
produit dans son ensemble indique que lAgilit n'est pas suffisamment
mature pour le grand public. Mais il y a un problme encore plus grand :
penser lAgilit en tant que produit est une mtaphore toxique car elle
ne reflte pas lAgilit en tant qutat desprit ou systme culturel.

19
Martin Fowler dfinit la Diffusion Smantique comme le processus selon
lequel un mot (Agile par exemple) qui est invent par une personne ou un
groupe, est ensuite propag travers l'ensemble de la communaut
d'une manire qui affaiblit cette dfinition [Fowler]. Cet affaiblissement
risque de causer la perte totale de la dfinition - et avec elle, toute lutilit
de ce terme. Jai rencontr de faon certaine des gens qui prtendent
tre agile et comprendre les pratiques, mais qui ne comprennent pas
l'tat d'esprit Agile. On trouve de plus en plus couramment des

20
praticiens Agile qui comprennent les pratiques, mais ne comprennent
pas les valeurs et les principes. L'argument ici est que lAgilit est voue
l'chec tant son message et sa signification deviennent illisibles.

Lorsquun mot concernant lAgilit nat, il subit le mme processus que

beaucoup d'adoptions technologiques, processus selon lequel il vit un pic
dintrt et une dsillusion, comme illustr dans le schma ci-dessous
[Wikimedia - "Hype Cycle"]. LAgilit a pass le pic des attentes
exagres et se dirige vers le creux de la dsillusion [Stack Overflow -
Le dveloppement Agile est-il mort ? [en]]. On peut considrer ce livre
comme une tape vers l'acclration de ce processus en criant l'chec
et en fournissant les premires tapes menant vers la pente de
l'illumination.

La Culture est le dfi n1 de ladoption Agile

Les rsultats de l'enqute sur ltat du dveloppement Agile sont
tonnants en termes de gravit et d'ampleur des dfis lis ladoption de
lAgilit auxquels les organisations font face [VersionOne]. La barrire n1

21
 l'adoption largie de lAgilit dans les entreprises est le changement
culturel (voir le schma ci-dessous), un problme signal par 52% des
rpondants. Et encore, ce chiffre pourrait tre sous-estim, car les
impacts culturels sont difficiles identifier.

Alors, quelle est limportance de la culture dune entreprise ? Edgar

Schein, professeur au MIT Sloan School of Management, dclare: Si
vous ne grez pas la culture, cest elle qui vous gre, et vous navez
mme pas la possibilit de mesurer lampleur de ce qui est en train de se
passer.

22
Partie 2: Culture Agile
LAgilit nest pas un processus - elle dfinit une
Culture
Mais qu'est-ce que cela a voir avec lAgilit ?

Eh bien, quest ce que lAgilit ? La dfinition consensuelle est fournie par

le Manifeste Agile ayant une dcennie dge [Manifeste Agile]. LAgilit
est une ide soutenue par un ensemble de valeurs et de croyances. En
d'autres termes, lAgilit dfinit une culture cible pour une ralisation
russie du logiciel. Ce livre va explorer davantage le modle de culture
Agile dans les pages suivantes.

LAgilit est communment dcrite comme un processus ou une famille

de processus. Cela est vrai, mais cest une abstraction dangereuse et
errone. J'ai malheureusement communiqu ce message trompeur par
ignorance maintes fois. Si Agile tait juste une famille de procds, nous
ne devrions pas voir la culture comme un problme rpandu.

Trop souvent, lAgilit est achete et vendue comme un produit. Les

entreprises qui ont des problmatiques de timeto-market trop lent ou de
qualit, veulent une solution. Les bnfices apports par lAgilit sont mis
en avant et un projet est lanc avec lAgilit comme tant la solution.
Dave Thomas a invent le concept de la Fe Agilit o les coachs
Agiles peuvent intervenir et saupoudrer de la poudre magique sur les
projets en difficult permettant de corriger des annes datrophie et de
ngligence [Thomas]. C'est un mythe : lAgilit n'est pas une panace.

LAgilit apporte un changement fondamental de pense. Tobias Mayer a

crit que Scrum porte davantage sur le changement de notre faon de
penser quun processus [Mayer]. Bob Hartman a une belle prsentation
sur ce sujet - Faire Agile n'est pas la mme chose qu'tre Agile
[Hartmann]. Le point essentiel est que nous sommes dans le Faire Agile
lorsque nous suivons les pratiques et nous sommes dans le tre Agile

23
quand nous agissons avec un esprit agile. Les praticiens expriments
savent que les pratiques ne sont quun moyen de ralisation.

Mike Cottmeyer a crit une srie d'articles sur la faon dont de grandes
entreprises adoptent lAgilit et ne se transforment pas en Agile
[Cottemeyer]. Il a grandement contribu aider la communaut lever
l'ambigut entre les termes adoption et transformation qui sont
toujours utiliss de faon interchangeable. Mike fait cette distinction:

Ladoption, cest changer par le faire agile

La transformation cest changer par le tre agile

Indpendamment, Isral Gat parlait de la relation entre lAgilit et la

culture dans Comment nous faisons les choses ici pour russir [Gat]. Son
observation tait que l'adoption de lAgilit dclencherait un conflit du
dcalage culturel entre les groupes au sein d'une entreprise. Il nous
conseille dtre conscients de ces problmatiques pour pouvoir les
attnuer. Pete Behrens a document des tudes de cas en utilisant la
culture comme un moyen de soutenir lAgilit [Behrens].

Pour russir, nous devons commencer penser lAgilit comme une

culture et non pas comme un produit ou une famille de processus.

Dans la section suivante, je prsenterai un modle de culture qui peut

tre utilis pour comprendre la culture de votre organisation. Les sections
suivantes expliquent les cultures propres lAgilit, au Kanban et
lArtisanat Logiciel (Software Craftsmanship). Dans la dernire section, je
vous propose un guide pour valuer dans quelle mesure une approche
spcifique correspond la culture de votre organisation.

Comprendre la Culture au travers du modle de

Schneider
Nous devons dfinir ce que nous entendons par culture avant daller plus
loin dans lexploration de lagilit. Dans cette section, je vais introduire le

24
modle de culture de Schneider, bas sur le livre de William Schneider
[Schneider - The Reengineering Alternative: A plan for making your
current culture work]. Bien quil y ait beaucoup de manires diffrentes de
penser la culture dentreprise, ce modle a t slectionn parce quil
permet daboutir des plans daction.

Quest-ce quun modle de culture ? Un modle de culture met en

lumire les valeurs et les normes en vigueur au sein dun groupe ou
dune entreprise. Il identifie ce qui est important, ainsi que la faon dont
les gens abordent le travail et sabordent entre eux. Par exemple, une
culture peut valoriser la stabilit et lordre. Dans ce cas, des processus
clairement dfinis sont valoriss et il y a une forte attente de conformit
au processus plutt qu linnovation et la crativit.

Le modle de Culture de Schneider dfinit quatre types de cultures

diffrentes:

1 La culture de la Collaboration : travailler ensemble.

2 La culture du Contrle : avoir et garder le contrle.

3 La culture de la Comptence : tre le meilleur.

4 La culture du Dveloppement personnel : apprendre et se

dvelopper en visant un objectif ayant du sens.

Le diagramme ci-dessous rsume le modle de culture de Schneider.

Chacune des quatre cultures est dcrite - une dans chaque quadrant.
Chacune a un nom, une lgende descriptive, une image, et quelques
mots qui caractrisent ce quadrant. Prenez le temps de bien tudier le
diagramme pour comprendre le modle et trouver o se situe votre
entreprise.

25
Un autre aspect du modle de Schneider concerne les axes qui indiquent
le focus dune organisation.

1 Axe horizontal : Orient Individu (personnel) versus Orient

Entreprise (impersonnel).

2 Axe vertical : Orient Ralit (Actualit) versus Orient Possibilit.

Cela fournit un moyen de voir les relations entre les cultures. Par
exemple, la culture du Contrle est davantage compatible avec les
cultures de la Collaboration et de la Comptence quavec la culture du
Dveloppement Personnel. Dans le modle de Schneider, la culture du
Dveloppement Personnel est loppos de la culture du Contrle;

26
apprendre et se dvelopper est loppos de la scurit et de la structure.
De faon similaire, la Collaboration est loppos de la Comptence.

Tous les modles sont faux, mais certains sont utiles - George Box,
statisticien. Tous les modles sont une approximation de la ralit et il est
important de se rappeler que nous ignorons sciemment les carts
mineurs de faon pouvoir raliser une analyse et avoir un discours
ayant du sens. De mme, nous pouvons avoir envie de considrer
dautres modles comme celui des Spirales Dynamiques pour
comprendre lvolution des cultures [Beck, Cowan].

Dans le modle de Schneider, aucune culture nest considre meilleure

quune autre. Voir le livre pour les dtails sur les forces et les faiblesses
de chacune. En fonction du type de travail, un type de culture peut tre le
meilleur choix.

Schneider suggre que la plupart des entreprises ont une seule culture
dominante avec des lments provenant des cultures des trois autres
quadrants. Les lments des autres cultures sont encourags tant quils
servent la culture dominante. Des dpartements ou groupes diffrents
(ex: dveloppement versus production) ont typiquement diffrentes sous-
cultures. Ces diffrences peuvent entraner un conflit.

La Culture Agile concerne la Collaboration et le

Dveloppement personnel
Michael Spayd a rendu un grand service la communaut en ralisant
une enqute sur la culture des Agilistes Culture Survey of Agile [Spayd].
Voir le diagramme ci-dessous pour les rsultats. Ses rsultats du terrain
montrent que les praticiens agiles ont un profil culturel particulier
reconnaissable par les lments cls que sont la Collaboration et le
Dveloppement Personnel. Les rsultats suggrent que lAgilit concerne
avant tout les individus. Il est intressant de noter que l'enqute incluait
aussi bien des pratiquants de Scrum, XP, ou Kanban.

27
Le manifeste et les principes Agile dfinissent la Culture
Agile
Le Manifeste Agile et les douze principes - mme aprs dix ans - sont
toujours la rfrence de ce qui est considr comme Agile. Considrez
le diagramme ci-dessous, o les valeurs et les principes sont relis au
modle de Schneider.

28
On peut voir quil y a une forte densit de valeurs et de pratiques qui sont
en rapport avec la Collaboration et le Dveloppement personnel. Il est
noter quil ny avait pas dlment en rapport la culture du Contrle et
seulement un en relation avec la culture de la Comptence. La similarit
avec le rsultat obtenu par Michael Spayd dans son enqute sur lAgilit
est frappante.

Approche Analytique (Pour les curieux)

Certains dentre vous peuvent tre curieux de savoir comment jen suis
arriv ce rsultat et ceux qui suivent.

Pour chaque valeur ou principe, jai analys comment il tait align avec
chacune des cultures. Sil y avait une forte affinit, je lassociais avec
cette culture. Par exemple, pour la Collaboration avec lUtilisateur ctait

29
trs simple, puisquelle met en valeur le succs travers la collaboration
entre plusieurs personnes. Certains lments semblaient tre
orthogonaux au modle de culture de Schneider. Par exemple, un
logiciel qui fonctionne, ne semblait pas rellement suggrer une culture
par rapport une autre. En fait, il peut faiblement suggrer une culture de
la Comptence, mais vraiment peine. Par consquent, il nest pas
indiqu dans le diagramme ci-dessus. Dautres items taient les meilleurs
choix possibles en me basant sur ma comprhension courante.

Alexei Zhegloz ma suggr que cette approche revient lancer des

flchettes sur une cible. Chaque valeur ou principe est une flchette
unique. La cible est le modle de Schneider. Quelques flchettes vont
atterrir sur la cible dans une des zones du quadrant des cultures, tandis
que dautres vont compltement la rater. Aprs avoir envoy environ dix
flchettes, nous pouvons voir comment elles se rpartissent, mais nous
ne devons pas trop tenir compte des tirs de flchettes qui ne sont pas
valides. La mthode danalyse est utilise pour illustrer le biais culturel
dun systme de pense.

Ces rsultats ont t valids au travers d'ateliers en groupe pendant

lesquels les participants ont effectu cette mme activit aprs avoir reu
une explication du modle de culture [Sahota Culture Workshop]

Le Modle de Culture Nous Permet de Poser des

Questions Utiles
LAgilit concerne les personnes. Ce nest pas une conclusion
choquante : il semble que tout le monde sait cela.

Ce qui est intressant est que quand nous commenons rflchir

propos de lAgilit en tant que culture spcifique nous pouvons alors nous
poser les questions suivantes :

Quelle est la culture de mon entreprise en ce moment ?

Cette culture est elle en phase avec celle de lAgilit ?

30
 A quels problmes dois-je mattendre si les deux cultures ne sont
pas en phase ?

Plus de dtails ce propos dans la section plus bas : Travailler avec votre
Culture.

La Culture Kanban est en phase avec le Contrle

Jai choisi un billet perspicace de David Anderson comme base mon
analyse [Anderson Principles of the Kanban Method]. David est sans
conteste le principal leader de lcole Kanban/Software grce son livre,
une mailing list trs active et le Lean Software and Systems
Consortium. Jai choisi ce billet car cest un rsum concis des principes
mis en avant dans son livre, Kanban [Anderson Kanban].

Comme avec le manifeste Agile, jai pris les principes Kanban et je les ai
mis en relation avec le modle de culture de Schneider. Comme on peut
le voir dans le schma suivant, Kanban est largement en relation avec la
culture du Contrle et avec la Comptence en seconde influence.

31
Les cultures du Contrle vivent et respirent les rgles et les processus.
Kanban en a des tonnes. La culture du Contrle signifie aussi crer une
structure claire et ordonne afin de grer lentreprise - exactement ce que
Kanban fait bien. Les cultures du Contrle se focalisent sur
lentreprise/systme (pas sur les personnes) et ltat courant (pas ltat
futur). C'est une bonne description du point de dpart utilis avec
Kanban.

Ce qui est rellement intressant du point de vue de lanalyse culturelle

est le principe suivant : amliorez-vous de faon collaborative en utilisant
les modles et la mthode scientifique. Daprs le modle de Schneider,
ces deux concepts ne se mlangent pas car ils viennent de cultures
opposes. Alors, comment cela peut-il marcher ? Daprs Schneider,
dautres lments culturels peuvent tre prsents tant quils supportent la

32
culture principale. Donc, se focaliser un peu sur la personne est trs bien
tant que cela est un support au contrle du travail.

La notion de changement volutif ou contrl peut aussi tre compatible

avec une culture du Contrle si elle est utilise pour maintenir la structure
dorganisation existante et la hirarchie.

Karl Scotland propose un autre ensemble de principes qui dfinissent

Kanban [Scotland Thoughts on Kanban Thinking]. On peut noter que
ces principes se situent eux-aussi dans le quadrant Contrle et
Comptence du modle.

Attendez une minute - Kanban est Agile, nest-ce pas ?

Mike Burrows a crit un post trs influent o il soutient que Kanban
satisfait chacun des Principes Agiles [Burrows]. Maintenant que jtudie
cela dune perspective culturelle, je vois que ce nest que faiblement le
cas.

Agile et Kanban se partagent de faon sre une mme communaut, et

beaucoup de pratiques peuvent tre adaptes de faon croises.
Cependant, fondamentalement, elles promeuvent des perspectives
diffrentes. Agile sintresse dabord aux personnes et Kanban
sintresse dabord au systme. Oui, les personnes sont importantes
aussi en Kanban, mais cela est secondaire par rapport au systme.

Alors est-ce que Kanban est Agile ? Je le croyais. Mais je ne le crois plus.
Je peux voir maintenant comment la croyance que Kanban est Agile est
dangereuse puisque les bases culturelles sont diffrentes.

Kanban est un Bon Outil

Parfois, quand je partage cette analyse que Kanban est li une culture
de contrle, je reois une forte raction ngative, car la culture de
contrle est totalement contraire au travail intellectuel. Pour viter tout
malentendu, je tiens prciser quelques points :

33
 1 J'aime Kanban et je pense que cest un bon outil. Nous avons
besoin de davantage lutiliser dans le monde. Voir mon blog o
jargumente sur le fait que certaines situations fonctionnent mieux
avec Kanban que Scrum [Sahota - "Scrum ou Kanban ? Oui ! "].

2 Je ne dis pas que les personnes qui utilisent Kanban sont des
maniaques du contrle ou quils prfrent commander et contrler.
Ce que je veux dire, c'est que si votre entreprise a une culture de
contrle, Kanban est un meilleur outil que Scrum.

Voir l'annexe pour les vues alternatives de Kanban fournies par les
relecteurs.

Kanban tel un Cheval de Troie ou une Drogue Passerelle

La thorie de la drogue passerelle assure que les drogues douces
(Kanban) peuvent conduire des drogues plus dures (Scrum, XP). Cest
une superbe mtaphore car cette thorie a t la fois prouve et
dmentie. Pour citer David Anderson nous commenons seulement
comprendre les diffrences entre Scrum et Kanban.

Avec Kanban, il y a des cas documents dquipes collaborant,

apprenant, et relevant/rsolvant des problmes spontanment. Cest
aussi mon exprience et cela pourrait confirmer lhypothse que Kanban
est un cheval de Troie (contenant lAgilit lintrieur).

Cest bien quand les personnes travaillent amliorer leurs

environnements un rythme rgulier. Beaucoup dorganisations ne sont
pas prtes une restructuration radicale (bien quelles puissent en avoir
dsesprment besoin). Pour de telles entreprises, Kanban est un bon
dbut. Descendre du Sofa et courir un marathon (Scrum) peut causer une
crise cardiaque; pour beaucoup il peut tre prfrable de commencer par
courir autour du pt de maisons (Kanban). Nous allons ltudier plus en
dtail au travers de lexploration de ladoption et de la transformation.

Kanban + Agile = Agile

34
Il est possible de pratiquer Kanban avec un tat desprit Agile comme
point de dpart pour faire voluer le processus. Dans cette situation, le
focus est sur les valeurs et principes Agile alors que les rgles et
processus sont utiliss comme support pour le travail dquipe. Une telle
approche peut tre approprie quand Scrum ou XP ne sont pas
appropris pour lenvironnement. Voir CrystalBan comme moyen
dintgrer les personnes dans Kanban [Scotland Crystallising
Kanban].

Olaf Lewitz assure que Kanban peut et devrait tre utilis tout comme
lAgilit lest - pour remettre en question le statu quo. Son objectif
principal est de fournir une boucle de rtroaction qui peut tre utilise
pour conduire le changement dans les organisations. Il affirme que les
personnes sont le systme et que nimporte quel programme de
changement doit les impliquer en tant que composant central.

Le Craftsmanship relve de la Comptence

La monte dun Scrum anmi a caus la consternation dans la
communaut Agile. Uncle Bob Martin a cristallis ce problme en
ajoutant une cinquime valeur au manifeste Agile du Savoir-faire plus
que de la Merde [Martin Quintessence]. Cela a donn naissance la
si ncessaire communaut de l'Artisanat logiciel ["Manifesto for Software
Craftsmanship"]

J'ai dj expliqu que la communaut Agile tait centre sur la

Collaboration et le Dveloppement Personnel au dtriment de la
Comptence. En tant que communaut de professionnels du logiciel,
nous devons faire attention la comptence et l'excellence technique
pour garantir notre durabilit sur le long terme. Pour plus d'informations
sur le sujet, lisez l'article rcent d'Uncle Bob [Martin The Land that
Scrum Forgot].

Le diagramme ci-dessous met en regard les composantes du manifeste

pour l'Artisanat Logiciel (Software Craftsmanship) vis--vis des cultures
identifies dans le modle de Schneider.

35
Sans surprise, on trouve un focus important sur la culture de la
Comptence. Cette culture permet le succs en tant le meilleur. Et
l'artisanat correspond l'ide d'tre les meilleurs dveloppeurs de logiciel
possibles.

La valeur partenariats productifs se trouve isole. L'ide gnrale est de

travailler main dans la main avec les clients pour produire du logiciel de
valeur rsolvant des problmes rels. Ne pas tre de simples singes
codant.

Pourquoi devons-nous faire attention ?

L'Artisanat Logiciel (Software Craftsmanship) doit exister pour tre sr
que les pratiques techniques mises en avant par XP sont utilises en
soutien dun dveloppement durable et ne se perdent pas dans une

36
culture Agile de pacotille. Les pratiques telles que : le remaniement (de
code) sans arrt, faire le plus simple possible et qui fonctionne,
Dveloppement Dirig par les Tests (TDD), Dveloppement Dirig par les
Test dAcceptation (ATDD), lintgration continue, le dploiement continu,
la responsabilit collective du code, le code propre, etc.

La cration et lexistence dun mouvement spar en support dune

culture de la Comptence existant en dehors de lAgilit, soutient lide
que la culture Agile est focalise sur la Collaboration et le Dveloppement
personnel et non sur la Comptence.

En guise de note finale avant de laisser la culture de l'Artisanat Logiciel,

je voudrais dire que ce manifeste ne reflte pas de faon correcte un
aspect cl du mouvement : Un profond engagement apprendre et
grandir (culture du Dveloppement Personnel). Ceci tant une valeur qui
vient soutenir la recherche de lexcellence de la construction logicielle.

Travailler avec Votre Culture

Considrez le diagramme suivant illustrant comment les principes Agile,
Kanban, et dArtisanat Logiciel se marient avec les diffrentes cultures.
Les formes illustrent la culture dominante pour chacun des mouvements
Agile, Kanban et dArtisanat Logiciel, en se basant sur lanalyse des
sections prcdentes.

37
Le diagramme peut tre utilis comme guide pour dterminer quelle
approche peut se construire sur la culture dominante de votre entreprise.

Culture du Contrle => conduit Kanban

Culture de la Comptence => conduit lArtisanat Logiciel

(Craftsmanship)

Culture de la Collaboration ou du Dveloppement personnel =>

Conduit certains aspects de lAgilit qui sont en phase avec la
culture de lorganisation, par exemple : Vision et Rtrospectives
pour la Culture du Dveloppement personnel.

Ce guide ne doit pas tre utilis sans tenir compte des autres aspects
culturels et contextuels de lentreprise.

Bien sr, beaucoup de lecteurs peuvent tre intresss savoir comment

faire voluer la culture dentreprise dune culture du Contrle vers la

38
Collaboration, le Dveloppement personnel et la Comptence. Ceci est
discut en dtail dans la section sur la transformation.

Comprendre la Culture
La premire chose faire avant de travailler sur votre culture est dj de
la comprendre. Schneider dcrit une enqute que vous pouvez donner
votre personnel [Schneider Survey] et suggre dutiliser les rsultats
du sondage comme point de dpart pour des ateliers sur la culture avec
un chantillon diversifi de collaborateurs. De ma propre exprience, jai
trouv que latelier seul est plus pertinent (comme indiqu par les
participants) et les rsultats plus comprhensibles et dune appropriation
plus simple.

Le gourou du management Peter Drucker dit la Culture est

curieusement tenace... En fait, le changement de comportement
fonctionne seulement sil est bas sur la culture en place. En
consquence il nest pas possible de simplement basculer dune culture
du Contrle vers une culture Agile.

Une orientation centrale du livre de Schneider est quil est essentiel de

sappuyer sur la culture existante plutt que de sy opposer. Il existe
plusieurs suggestions afin dutiliser linformation de la culture pour guider
la prise de dcisions :

1 valuer les problmes cls dans le contexte de la culture.

Quelques fois il faut faire des changements pour aligner la culture
avec la culture prdominante.

2 Quelque fois la culture est trop extrme (ex: trop de

Dveloppement Personnel sans aucun contrle - ou vice versa !),
et des lments des autres cultures en place sont ncessaires
pour la contrebalancer.

3 Considrer la possibilit de crer des

interfaces/adaptateurs/faades afin de tenir compte des
diffrences entre les dpartements ou les groupes.

39
Travailler avec dautres Cultures
Considrons le diagramme ci-dessous montrant des faons efficaces de
travailler sur la culture dentreprise.

Loption n1 illustre le fait quil est plus facile de travailler avec la culture
dominante existante (ici la culture du Contrle). Loption n2 est dexplorer
prudemment les cultures adjacentes de manire respecter et soutenir la
culture actuelle du groupe. Le choix du chemin peut tre indiqu par la
nature de la culture secondaire de lorganisation. Ici, lide est de
s'appuyer sur la culture existante, et non de la combattre.

Adaptateurs de Culture
Le modle cellulaire est un moyen trs puissant pour introduire une
culture trangre telle que lagilit dans une organisation. Considrez la
transformation russie dune quipe ou dun groupe lAgilit.

Imaginez que lquipe est trs enthousiaste vis vis de la nouvelle faon
de travailler. Puisque ce chapitre a pour sujet la transformation, les
membres de lquipe voluent dans un contexte o existent plusieurs
autres cultures. Lquipe nest pas vraiment enthousiaste vis vis de
toutes les barrires organisationnelles, ni vis--vis des limites en terme
de productivit et de succs. Donc, ce qui arrive typiquement est quils
commencent repousser toutes les exigences des autres groupes et
toutes les demandes qui najoutent pas de valeur lquipe ou aux
clients.

40
Le rsultat ressemble une srie B : Attaque des anticorps de
lorganisation ! Dans le corps humain, nous avons des anticorps (les
cellules T, tueuses) dont la mission est dliminer les lments
trangers pour nous maintenir en bonne sant. De la mme faon, les
organisations vont ragir lintroduction dune culture trangre telle que
lagilit. Ce sont les lments qui travaillent dur pour prserver le statu
quo.

41
Le film na pas forcment une mauvaise fin. Un modle habituel est de
construire des adaptateurs ou traducteurs autour de la culture trangre
de faon ce quelle sinsre lintrieur de la culture englobante. Cela
est dcrit dans le diagramme ci-dessous au moyen de formes entourant
et protgeant lquipe. Dans cette situation, ladaptateur autorise lquipe
se mlanger avec lensemble de la culture de lorganisation et dviter
dactiver les anticorps.

En pratique, ladaptateur pourrait prendre la forme dun planning

Microsoft Project qui na aucune valeur pour le client ou pour lquipe

42
mais qui est requis par lorganisation. Un autre exemple pourrait tre
lutilisation de revue par ses pairs afin d'accrotre la reconnaissance du
mrite de chacun mais qui serait toujours soumise par le manager car le
systme naccepte dentres que de sa part.

Cela semble tre beaucoup defforts ! Est-ce que cela en vaut la peine ?
La valeur est gale aux bnfices drivs de lAgilit moins les cots de
maintenance de ladaptateur. En supposant quil y ait une bonne valeur
dans la nouvelle faon de fonctionner pour lquipe, alors
malheureusement une partie de cette productivit sera perdue dans la
maintenance des adaptateurs. Mais cest une situation bien meilleure que
celle dtre attaque par les anticorps de lorganisation. Les adaptateurs
font partie du cot de lactivit conomique. Comme les taxes.

Le Lean fait la difference entre diffrents types de gaspillage dans les

organisations. Le Muda (gaspillage) de type I concerne les tches
napportant pas de valeur qui sont requises en ce moment. Le Muda de
type II concerne les tches napportant pas de valeur et qui peuvent tre
supprimes immdiatement. Maintenir les adaptateurs est du type I
puisque lenvironnement en a besoin.

Etude de Cas : Dans une organisation, je prsentais Scrum et le

PMO (Project Management Office) nous avait demand de fournir
un plan de projet. Jai fait observer juste titre que ce plan
napporterait aucune valeur et je me suis retrouv engouffr dans
une bataille de tranches avec le PMO. Bien sr, cela avait vit
un peu de travail, mais, long terme, cela a cr des ennemis
la transition Agile lintrieur mme de lentreprise.

Heureusement, lquipe a eu beaucoup de succs, le manager lui-

mme avait agi comme adaptateur. Il travaillait dur pour protger
lquipe et pour rpondre toutes les demandes externes de
lorganisation. Aprs deux ans de lutte, il le faisait toujours mais
trouvait cela usant.

43
 tude de Cas par Olivier Gourment : Jai introduit la
programmation en binme (pair-programming) dans une
organisation o les revues de code taient obligatoires, mais cette
organisation ne voulait pas aller jusqu la programmation en
binme. Je leur ai simplement prsent cette dernire pratique
comme une meilleure revue de code. Une faon de lenvisager
est que le relecteur et le dveloppeur collaborent ensemble sur
le code revoir. Vu de lextrieur, cela donnait limpression que
nous faisions seulement des revues de code. La programmation
en binme est vraiment quelque chose que vous devez essayer
avant den comprendre les bnfices. Dans ce cas particulier, cela
a permis dconomiser normment de temps parce que le
framework web tait nouveau pour toute lquipe, et que des
standards devaient merger.

Le modle ci-dessus pointe une faon de russir la transformation Agile -

il est possible de transformer une quipe ou un groupe tant quon apporte
du soin et de lattention pour satisfaire les demandes du reste de
lorganisation. Il semblerait que la stratgie de ladaptateur ne soit pas
soutenable long terme. Pourtant, cela pourrait tre une bonne stratgie
denvisager cela comme une premire tape avant dinitier un
changement dorganisation plus large.

Joseph Pelrine aborde une discussion approfondie du problme des

discordances entre les quipes Agiles et leur environnements in [Pelrine].
Cest aussi une bonne explication de la pense de la socit vue comme
un systme complexe.

Comment Changer une Culture est une autre Histoire

Changer la culture est trs difficile. Ce sujet sera abord plus en dtail
dans le chapitre suivant sur la transformation Agile.

44
Rsum
Flicitations! Vous avez maintenant le modle de la Culture Schneider -
un outil facile utiliser pour valuer la culture de votre entreprise. Une
fois que vous connaissez la culture de votre entreprise, vous allez tre
conscient de son influence sur de nombreux aspects du travail quotidien.
Plus important encore, vous pouvez utiliser le modle correspondant la
culture pour dcider quelle approche - Agile, Kanban, ou lArtisanat
Logiciel (Craftsmanship) - convient le mieux votre organisation si vous
voulez travailler avec la culture existante. Bien sr, si votre objectif est de
dfier le statu quo pour construire de grandes quipes et organisations,
continuez lire la suite.

45
Partie 3: Guide de survie lAdoption et la
Transformation
Dfinissons Adoption et Transformation
LAdoption est un terme qui sapplique un produit ou un processus. Par
exemple, Nous adoptons GoogleDocs la place de Microsoft Office ou
bien nous adoptons un nouveau processus dachat.

Il est souvent utilis de faon incorrecte tel que nous adoptons lAgilit.
Comme nous avons tabli que lAgilit est un tat desprit et une culture,
elle ne peut pas tre adopte toute seule. Dun autre cot, on peut dire
sans crainte nous adoptons le cadre de processus Scrum ou bien nous
adoptons les pratiques Agile.

La Transformation implique le changement dune faon dtre vers une

autre faon dtre. Cest souvent quelque chose dENORME. Comme une
chenille se changeant en papillon. Ou bien en crant un environnement
o les gens prennent du plaisir travailler.

Nous nous transformons en Agile est une bonne faon de dcrire ce qui
est mis en oeuvre dans les environnements o le changement reprsente
une remise en cause profonde des comportements et des valeurs.

Le mot transition signifie mouvement, passage, ou changement de

position, dtat, de niveau, de sujet, de concept, etc. vers un autre.
Transition pourrait tre utilis pour dcrire aussi bien adoption que
transformation. Puisquil est ambigu, cest mieux de toute faon dviter
ce terme.

Un modle pour comprendre lAdoption et la

Transformation
Considrons le cadre suivant pour nous permettre danalyser et de
planifier de faon efficace les efforts de changement :

46
 1 Adoption des pratiques Agiles dans une Culture Inadapte (
gauche).

2 Adoption et Transformation dans une Culture dAccompagnement

(au milieu).

3 Transformation Agile ( droite).

Le diagramme montre une gamme dapproches et dans quels contextes

elles sont le plus utiles. Cette vue na pas pour but dtre exhaustive,
mais de plutt illustrer comment une approche peut tre plus axe
adoption que transformation. Elle fournit un modle de pense propos
des diffrentes approches et buts de lactivit de changement, de telle
sorte quun agent du changement peut slectionner la bonne approche
dans un contexte donn.

47
Adoption des pratiques Agile dans une Culture
Inadapte

Le but de cette section est dexpliquer les approches dadoption des

pratiques Agile, Kanban ou celles de lArtisanat Logiciel (Craftsmanship)
dans une culture dentreprise qui nest pas aligne avec la culture de
lapproche considre. Par exemple, cela pourrait tre les pratiques Agile
(Culture de la Collaboration/Dveloppement Personnel) dans une culture
de Contrle ou bien des pratiques de lArtisanat Logiciel (culture de la
Comptence) au sein de dune culture de la Collaboration. Le puzzle de
lillustration a pour but de montrer une extension par morceaux de la
structure de lorganisation. Avant de nous y embarquer, nous devons
considrer diffrentes perspectives autour bien-fond de ce type
dapproche.

48
Lorientation fournie par Schneider est didentifier des pratiques qui
supportent la culture dominante de lentreprise ou du groupe plutt que
dessayer de la changer. Il appelle cela faire fonctionner votre culture.

Prenons lexemple de lAgilit, nous pourrions envisager cette approche

comme un menu de pratiques plutt quun systme de valeurs. Nous
pourrions choisir des itrations ou des laps de temps pour fournir plus de
structure et de contrle la livraison du projet. Ou bien introduire la
vlocit pour ajouter du contrle empirique afin damliorer la prdictibilit
de la livraison.

De nombreux promoteurs de lAgilit trouvent que rduire cette approche

un ensemble de pratiques conduit rater compltement la cible. On
pourrait argumenter que lAgilit est un moyen daider les organisations
atteindre le succs, et non un ensemble de pratiques slectionner
comme des morceaux de viande. Dun point de vue culturel, lAgilit a
plus pour vocation de schapper dune culture du Contrle que de
trouver des moyens pour laider !

Un autre point de vue considrer est celui de la supplication

[Sirajuddin]. Je pense la supplication comme un moyen de sengager
avec une personne ou dans un systme avec un profond respect et avec
comprhension. Par exemple, plutt que de penser Waouh, ce
dpartement est compltement pourri, on pourrait plutt penser : Le
systme fonctionne aussi bien quil le peut cet instant prcis. Les gens
sont capables daccomplir des choses malgr de nombreux obstacles. A
partir dune position de supplication, nous pouvons voir quune
organisation nest peut-tre pas capable daccepter ou mme de vouloir
un tat desprit Agile mais que nous pouvons laider dans son tat courant
dapprentissage et de croissance (i.e. : culture).

Eviter le Manifeste Agile et Scrum

Ce qui est presque aussi important que ce qu'il faut faire, c'est ce quil ne
faut pas faire. Un exemple cl est d'viter tout ce qui pourrait suggrer ou
encourager un changement de mentalit et de culture. Pourquoi ?

49
Daprs mon exprience, il est source de confusion, de dsorientation, et
dangereux de discuter d'un changement de mentalit lors de ladoption
des pratiques. Par exemple, se focaliser sur la collaboration troite ne
fonctionne pas bien quand un groupe de dveloppement logiciel est
rparti dans le monde.

Comme indiqu prcdemment, le Manifeste Agile est un nonc des

valeurs dont lobjectif est de former une culture spcifique. Donc, c'est
une bonne ide dviter de les mentionner ou mme de les conserver
comme un objectif lors de l'adoption Agile. Au mieux, ils ne sont pas
pertinents et, au pire, ils vont provoquer des changements accidentels
dans le comportement du personnel qui sera source de frictions dans
l'environnement. Il est cependant intressant de parler avec l'quipe de
direction de la culture ainsi que des valeurs et des principes agiles afin
qu'ils puissent prendre une dcision claire sur une adoption par rapport
une transformation.

Scrum en tant que Technologie de Transformation Disruptive

Scrum est une mthode de transformation trs puissante. Scrum est

construit pour casser les structures de pouvoir et de contrle en crant de
nouveaux rles (Product Owner, Scrum Master, lEquipe). Il pose aussi
les quipes auto-organises comme pierre angulaire fondamentale des
organisations. En tant que telle, la mthode Scrum devrait tre vite,
autant que possible, lorsque ladoption des pratiques Agile seffectue
dans une culture inadapte. La raison en est que par sa nature cette
mthode forcera la transformation de la culture en place, plus quelle nen
permettra ladoption des pratiques. Il ny a pas de problmes utiliser les
pratiques Scrum, mais il est prfrable dutiliser les termes Agile originels
(ex: Itration et non Sprint) comme discut ici [Sahota - StealthScrum].

Lean diffrencie kaizen (amlioration continue) et kaikaku (transformation

radicale). Kanban promeut kaizen alors que Scrum est une forme de
Kaikaku [Sahota - Kanban est une drogue passerelle]. Dans
lventualit o il y aurait de forts facteurs favorables des changements
radicaux dans lenvironnement, alors Scrum est un excellent choix pour la

50
transformation. Nanmoins, l'adoption avec une culture inadapte ne
correspond pas ce genre de situation.

Modles dadoption de lAgilit

Une autre grande ressource pour l'adoption de pratiques Agiles est
Modles d'adoption Agile : Feuille de route pour le succs de
lorganisation [Elssamadisy]. Il prconise une adoption des pratiques
base sur les points douloureux issus de situations mtier (ex : Des
fonctionnalits qui ne sont pas utilises) et de processus (ex : le manque
de visibilit) qui ne sentent pas bon. Chaque type dodeur ou de
problme est associ un ensemble de pratiques Agiles qui adressent ce
problme. Voici un exemple:

Problme : la phase de consolidation est ncessaire la fin du

cycle de la version.

Pratiques applicables : les tests automatiss par les

dveloppeurs, l'intgration continue, les tests fonctionnels, l'tat
Termin, et la livraison frquente.

L'approche dcrite ici concerne uniquement les pratiques Agiles -

parfaites pour l'adoption de l'Agilit dans une culture inadapte.

Devenir Agile dans un monde imparfait

Le livre Devenir agile dans un monde imparfait fournit une foule de
conseils pratiques sur l'adoption de l'Agilit [Smith & Sidky]. Les auteurs
partent de lhypothse que de nombreuses entreprises ne sont pas prtes
pour lAgilit dans diffrentes dimensions : Outils, Culture, Gestion de
Projet, les Processus logiciels et l'Environnement. Ils prconisent de
devenir le plus Agile possible compte tenu des limites environnementales
actuelles et des besoins les plus importants. Bien qu'ils reconnaissent
que lAgilit reprsente un changement dtat desprit, ils soutiennent
quune adoption incrmentale oriente pratiques est compatible avec
une adoption des pratiques Agiles dans une culture inadapte.

51
tude de cas : Une Grande Entreprise de la Finance
Considrons la situation suivante : un projet Agile hors de contrle dans
une grande socit de services financiers. Les personnes travaillant sur
le projet sont rparties dans plusieurs lieux en Amrique du Nord, ont
plusieurs sites off-shore, une organisation matricielle et une culture
Contrle/Comptence. LAgilit tait vue comme un moyen de travailler
efficacement et il ny a eu aucune aide de la part de lorganisation pour
voluer vers un tat desprit Agile ou redonner de lautonomie aux
personnes.

Le rsultat de lenqute sur la culture est indiqu ci-dessous. Il faut

prcise que pendant une discussion de groupe sur la culture, il est
devenu clair que la culture de Contrle tait dominante et celle de la
Comptence secondaire.

Par le pass (sans ma comprhension de la culture), jaurais

certainement cherch des moyens daider le client devenir plus Agile ou
bien pousser un changement dorganisation. Les rsultats auraient
certainement t dsastreux. Un scnario similaire est apparu chez un
oprateur tlcom chez qui je faisais du coaching. Jai contribu un
chec dans ladoption de lAgilit en promouvant un tat desprit Agile. Il y
a eu aussi dautres exemples.

52
Pour russir, jai appliqu une adoption contextuelle et pilote par la
douleur de plusieurs pratiques, certaines taient Agile, dautres non. Un
des problmes tait que personne ne connaissait le primtre de ce qui
pouvait tre fourni la date de livraison. Les pratiques Agiles qui ont t
appliques taient : communication face face lors dun atelier de 3 jours
co-localis pour le rglage du projet. Une autre tait un diagramme du
reste faire pour ce qui tait livrer dans 6 semaines. Notons quavec
une dure de 6 semaines, les itrations ont t abandonnes car elles
ntaient pas suivies de toute faon et ne semblaient pas fournir les
bnfices habituels. Un exemple de pratique non-Agile a t dutiliser
lenqute Gallup dengagement des employs pour mesurer la
performance de lunit business [Buckingham & Coffman]

Aprs une session intensive de planification stratgique utilisant la

technique A3 [Sahota A3 Technique] il devint clair que les obstacles
venant de lorganisation tels que la stratgie de localisation des sites et le
reporting matriciel auraient rendu trs difficile le moindre changement de
la culture de Contrle et de la Comptence. De mme, il aurait t trs
difficile de crer de petites quipes co-localises pour soutenir ce
processus. Lenvironnement tait si contraint qu'aller au del de l'adoption
de pratiques Agile n'aurait pas t possible ce moment l.

Adoption et Transformation dans une Culture

Compatible
Dans cette section, nous allons voir ce que signifie adopter lAgilit ou la
transformation Agile dans une culture compatible o les cultures
dominantes sont la Collaboration et le Dveloppement Personnel ou
peut-tre la Comptence pour l'adoption oriente XP. Bien que les ides
et les approches soient adaptes pour Kanban ou lArtisanat Logiciel
(Craftsmanship), lAgilit sera utilise pour illustrer les ides cls de cette
section.

Comme indiqu prcdemment, le modle de Schneider fournit une

loupe grossire travers laquelle vous pouvez voir la culture

53
organisationnelle. La vision nave serait de confirmer l'alignement culturel
d'une organisation et de procder simplement l'adoption de pratiques
Agiles dans l'hypothse o l'tat d'esprit Agile est entirement soutenu
par la culture. Malheureusement, la situation est un peu plus complexe
que cela. Ainsi, le modle de Schneider nous aide comprendre que
nous sommes dans ce scnario, mais ne fournit aucune indication
supplmentaire.

Dans son livre "Organizational Culture and Leadership" ("La Culture

Organisationnelle et le Leadership"), Schein fait valoir que nous devons
viter les modles superficiels de culture et nous appuyer sur de plus
profonds, plus complexes modles anthropologiques. [Schein, p.14]. Il
prsente de nombreuses et diffrentes dimensions de culture telles que :
les coutumes, les traditions, les normes du groupe, les valeurs pouses,
la philosophie officielle, les rgles du jeu, les mtaphores profondes, etc.

En outre, la culture d'un groupe est l'agrgation des points de vue de

chaque individu. Ainsi, cest gnralement le cas, certaines personnes ne
se conforment pas la culture du groupe. LAgilit tend rendre ces
types d'carts trs visibles et promeut certains types de comportements
tels que la collaboration et la visibilit.

Pris dans leur ensemble, il est clair que mme si l'on travaille avec
lAgilit dans une culture compatible, il se pourrait qu'un certain niveau de
transformation individuelle et collective soit ncessaire. Le but de cette
section est d'explorer ces approches et de mettre en vidence leurs
avantages et les dfis quelles reprsentent.

Orienter avec le Manifeste Agile et Scrum

Quand on travaille avec une culture qui est dj aligne avec les valeurs
Agile, il est alors opportun dutiliser les valeurs et les principes du
manifeste Agile comme pierre angulaire de linitiative de changement.
Quand les personnes sont orientes vers le but du changement que
lAgilit promeut (le POURQUOI), alors elles sont moins sujettes tre
distraites par les dtails du processus (le QUOI et le COMMENT).

54
Scrum marche bien dans cette situation parce quil est par dfinition une
technologie de changement disruptif. Comme discut prcdemment il
reprsente un changement radical de la structure de lorganisation. En
particulier, sa focalisation sur les quipes autonomes auto-organises est
particulirement puissante pour voluer vers un tat desprit Agile.

Le Changement Sans Peur

Le livre Fearless Change: Patterns for Introducing New Ideas (Le
changement sans peur : les modles pour introduire de nouvelles ides)
fournit plein de super techniques et conseils pour adopter de nouvelles
ides au sein dune organisation [Manns & Rising]. Limage ci-dessous de
Mihai Iancu montre des modles divers et varis qui peuvent tre
appliqus pour aider ladoption dune nouvelle technologie ou ide. Jai
utilis ces modles et ils sont trs utiles - spcialement quand on se sent
paralys et que lon cherche des ides pour sen sortir. Je les ai inclus
dans le bas de lchelle de ladoption car ils sont prvus pour introduire
de nouvelles ides, et non pour transformer une culture dentreprise.

55
Pour une image plus grande, voir [Iancu].

Deb Hartmann a cr un jeu, le voyage sans peur, pour aider les

personnes apprendre et appliquer ces modles [Hartmann]

Quand utiliser les modles du changement sans peur

Le changement sans peur est une bonne boite outils pour soutenir une
initiative de changement. En tant que tel, il est utile pour soutenir une
adoption Agile ou en complment dune autre approche.

Inspecter et Adapter avec lEquipe de Transition

dEntreprise
The Enterprise and Scrum (LEntreprise et Scrum) souligne comment
faire la transition (et non pas faire la transformation) dune organisation

56
vers Scrum [Schwaber]. Notons que lapproche nindique pas sil sagit
dune adoption ou dune transformation.

Les principales tapes sont les suivantes:

1 Crer une Equipe de Transistion dEntreprise - une quipe Scrum

responsable de la transition de lorganisation vers Scrum.

2 Crer un backlog dactions de transitions dans lentreprise.

3 Lquipe de transition suit la mthode Scrum; inspecte et adapte

pour aboutir au succs.

Bien qu'il soit reconnu que Scrum exige une nouvelle Culture d'Entreprise
et un effort norme pour sa mise en oeuvre - le livre manque de dtails
sur la faon de rendre cela possible. On peut mme faire une remarque
cynique en disant que tout ce que nous avons faire, c'est "d'inspecter et
adapter notre faon de faire pour aboutir au succs. A ma connaissance,
cest le modle le plus appliqu dans la communaut. Voir aussi A CIOs
Playbook for Adopting the Scrum Method of Achieving Software Agility
(livre dexercice pour adopter la mthode Scrum et aboutir lAgilit
logicielle lusage des DSI) [Schwaber, Leffingwell and Smits].

Il est utile de noter que lusage du mot transition, comme not

prcdemment, est ambigu par rapport ladoption ou la transformation.
Le sens vague du mot transition est une grande source de confusion
autour de ce thme dans la communaut des coachs Agile.

Quand utiliser Inspecter et Adapter

Inspecter et Adapter avec une quipe de transition dentreprise est une

approche raisonnable pour ladoption Agile dans ces situations vraiment
videntes. Dans le cas o leffort de changement est plus lourd, alors une
approche plus puissante, de transformation doit tre envisage.

ADAPT
ADAPT est le modle dadoption pour Scrum de Mike Cohn :

57
 1 Alerte sur le fait que le processus courant ne donne pas de
rsultat acceptable.

2 Dsir dadopter Scrum comme moyen pour rsoudre les

problmes courants.

3 Aptitude russir avec Scrum.

4 Promotion de Scrum par le partage dexpriences pour pouvoir

sen rappeler et afin que les autres voient nos succs.

5 Transfert de ce quimplique lutilisation de Scrum au travers de

lentreprise.

Voir le livre de Mike Cohn ou la prsentation pour plus de dtails [Cohn

Succeeding with Agile - Chapter 2] [Cohn Adapting to Agile Keynote].

Il est intressant de noter que le modle va dans la direction de la

transformation mais pas compltement. Voir par exemple la comparaison
avec un modle dtaill de transformation tel que celui de Kotter o le
dsir est remplac par un sentiment durgence. Ce dernier tant un
critre beaucoup plus exigeant. Par exemple, je peux tre conscient et
avoir le dsir de perdre du poids, mais cela pourrait tre un tel effort que
je nai pas un sentiment durgence ce propos. Une ide en ligne avec la
transformation est la reconnaissance que la transformation concerne les
individus : Tous les individus vont devoir passer par les tapes dAlerte,
de Dsir et dAptitude. Dun autre cot le mcanisme la base de la
ralisation de ce changement est en ligne avec le Inspecter et Adapter
de lEquipe de Transition dEntreprise vu plus haut.

ADAPT peut tre vu comme un complment au modle Inspecter et

Adapter qui donne des indications sur la manire datteindre un
alignement de lorganisation lors du passage vers lAgilit. Cest pour
cette raison quil est plac plus sur la droite (vers la transformation) dans
le diagramme de la vue densemble.

58
Quand utiliser ADAPT

ADAPT est utile pour les scnarios dAdoption Agile quand leffort de
changement ncessaire pour voluer vers un tat desprit Agile est
relativement faible. Pour des efforts de changement significatifs, une
approche plus explicitement oriente vers la transformation serait
bnfique.

Conteneurs, Diffrences et changes

CDE (Conteneurs, Diffrences,
changes) est un modle pour rflchir
comment effectuer un changement
dans un systme complexe. Ce nest
pas un modle dadoption en tant que
tel mais plutt une approche pour raliser le changement dans les
organisations. CDE est un composant central d'une approche globale
utilisant un raisonnement complexe pour le changement organisationnel
[Olson and Eoyang].

CDE fournit un moyen de comprendre le contexte dune quipe ou dun

groupe et de mettre en lumire les moyens de provoquer le changement.
Par exemple, une quipe est un conteneur trs puissant dorganisation du
personnel. De mme que lenvironnement physique (ex : bureau
dquipe). Les changes sont des points dinteractions entre les
conteneurs tels que lemail ou les transactions financires. Des
diffrences telles que le pouvoir ou lexpertise sont souvent cls pour
comprendre lalignement et la diversit. Esther Derby a fourni un bon post
et une prsentation/video au sujet des modles dvolution dorganisation
[Derby]. CDE est aussi discut ailleurs en tant quamplificateur efficace
dun effort de changement Agile [Cohn -Succeeding with Agile, p. 221-
227].

Quand utiliser CDE

59
CDE aide comprendre comment influencer un systme. Considrez
l'utilisation de CDE comme un outil daide ou de pense systmique pour
une approche mergente du changement.

Modle Cynefin
Cynefin est un modle rvlateur de sens qui distingue les diffrentes
causes existant entre diffrents types de systmes et propose de
nouvelles approches de prise de dcision dans un environnement social
complexe. Certains prtendent que le modle Cynefin peut tre utilis
pour aider ladoption Agile. Dautres lutilisent en tant que modle
danalyse pour crer une comprhension commune du type
denvironnement pour permettre de choisir lapproche la plus approprie.

Le modle Cynefin dcrit

cinq domaines diffrents:
Simple, Compliqu,
Complexe, Chaotique, et le
Dsordre (le mouton noir
au milieu du troupeau). Les
quatre premiers sont lists
dans lordre dune causalit
dcroissante tandis que le
Dsordre est un espace
humain o nous ne savons
simplement pas dans quel
type de systme nous
sommes. Dans un domaine
simple, la cause et leffet
sont directement connects, alors que dans le domaine Chaotique il ny a
pas de modle et la relation entre la cause et leffet nest pas claire. Nous
allons tudier plus avant les domaines Compliqu et Complexe car ils
sont plus pertinents lorsquon travaille avec des organisations.

60
Par exemple, dans des environnements complexes, les causes sont
comprhensibles a posteriori (i.e. : avec du recul) ce qui fait quune
approche adaptative au changement est approprie.

Les implications pour une adoption/transformation Agile sont claires - il

est suggr que beaucoup denvironnements dorganisation sont
complexes et que lapproche de transformation a besoin de reflter cette
ralit au risque dchouer. Dans un environnement complexe, nous ne
savons pas quelles actions vont conduire au rsultat dsir. A linverse,
nous avons besoin de tester lenvironnement, sentir le rsultat de nos
actions et alors choisir une rponse approprie. Ce modle conceptuel
sous-entend que lenvironnement peut fournir bien moins de clart en
comparaison dune feuille de route de transition dentreprise.

Certains aspects contextuels de lorganisation sont simplement

compliqus et ouverts lanalyse. La pense systmique est un exemple
de pratique qui requiert un environnement compliqu pour fonctionner
[Senge]. Un outil danalyse particulirement utile est le diagramme de
cause effet [Kniberg]. Par exemple, au cours dun processus A3, jai
utilis des diagrammes de cause effet pour en extraire une analyse
cense et je les ai utiliss comme base pour gnrer des contre-mesures
[Sahota A3 Technique].

John McFadyen, un promoteur du modle Cynefin, suggre que les

contextes organisationnels sont normalement dpendants des humains et
que nous complexifions tout ce que nous touchons. Cependant,
beaucoup vont agir comme sils taient simplement compliqus car ils
ont tendance agir dans cet environnement.

Le modle Cynefin nous fournit un langage pour comprendre et raisonner

propos du type denvironnement dans lequel nous travaillons. Voici une
courte video propos modle Cynefin [CognitiveEdge] ainsi quune
prsentation expliquant pourquoi cest important. i.e. : le cas des
systmes complexes adaptatifs [Schenk]. Si vous tes intresss par
lutilisation ou lexprimentation du modle Cynefin, vous pouvez regarder
le jeu cr dans ce but qui utilise les Lego [Tomasini & Lewitz].

61
Quand utiliser le modle Cynefin
Le modle Cynefin aide raisonner sur la relation entre la cause et leffet
dans un systme et identifier une approche cognitive approprie pour le
travail de changement. Cynefin nest pas une approche dadoption ou de
transformation, mais plutt un outil pour aider les agents de changement
comprendre leur objectif et leur approche. Ainsi il est complmentaire
aux autres approches.

tude de Cas d'Adoption Agile dans une Culture

Compatible
Le but de cette tude de cas est d'illustrer que l'alignement culturel avec
des cultures de Collaboration et de Dveloppement Personnel n'est pas
suffisante pour dterminer la compatibilit et la russite. L'organisation
est un groupe international de ples indpendants. Comme on peut le
voir sur les rsultats de lenqute ci-dessous propos de la culture, la
compagnie semble tre un candidat raisonnable lAgilit. Ces rsultats
ont t confirms par un atelier de groupe, mais pas la conclusion
souleve par cette tude.

On m'a demand doptimiser" une quipe Scrum existante et dadopter

des pratiques Agiles avec les deux autres petites quipes.

62
Dans le cadre d'une phase d'valuation/planification mene avant la
formation et le lancement du projet, il est devenu vident qu'une partie
essentielle de la culture faisait lobjet dun individualisme dbrid. Une
forte culture de hros tait en place et la direction avait cd aux souhaits
individuels de travail autonome. Il est devenu vident que Scrum ntait
peut-tre pas un bon choix car il exige un niveau de discipline bien plus
lev que celui que pouvait supporter cet environnement son stade de
maturit. En raison de ces proccupations et d'autres, l'quipe de
direction et moi-mme avons dcid d'utiliser une partie du temps dans
une formation de deux jours pour introduire Kanban, en plus de Scrum.
De plus, nous avons choisi de laisser aux quipes le choix dadopter
Scrum, Kanban ou un mlange des deux.

A la fin de la formation, les trois quipes ont slectionn Kanban plutt

que Scrum. Il est intressant dobserver que les quipes ont galement
adopt les User Stories, l'estimation et la vlocit pour grer la
communication avec les autres parties prenantes et planifier et suivre les
releases. Un atelier sur le travail en binme a galement t demand
pour soutenir l'objectif de transfert des connaissances. Une seule quipe
a eu un product owner. Aucune quipe ntait prte investir dans un
ScrumMaster ou un coach en processus.

63
La Transformation Agile

Le verbe transformer signifie [Dictionnaire Larousse] :

1 Rendre quelque chose diffrent, le faire changer de forme,

modifier ses caractres gnraux.

2 Modifier de faon spectaculaire ltat physique, moral,

psychologique de quelquun.

3 Faire dun tre, un tre diffrent.

Limage dune chenille se transformant en papillon est utilise pour

illustrer les changements profonds qui interviennent suite une
transformation.

Dans le contexte du modle de culture de Schneider, une transformation

serait un dplacement dune culture fondamentale vers une autre.

64
Dans la terminologie Agile, la transformation est une mtamorphose vers
un tat desprit agile - ce qui entrane un changement de culture.

La Transformation Agile est-elle Possible ?

Mon hypothse est que lAgilit seule n'est pas suffisante pour induire
une transformation organisationnelle. Une hypothse connexe est que les
approches dadoption Agile discutes dans les sections prcdentes sont
insuffisantes pour une transformation organisationnelle.

Kotter documente 10 grandes entreprises qui ont transform leur culture

d'entreprise [Kotter, Heskett]. Ainsi, il semblerait que le changement de
culture est difficile, mais possible.

Y a-t-il des cas documents de transformation Agile ? J'ai entendu des

gens parler dAgilit ou de Kanban induisant un changement de culture.
Au moment o jcris ces lignes, je nai pas connaissance d'tude de cas
appuyant lune de ces hypothses.

Certaines personnes pourraient mentionner le succs d'une entreprise

telle que SalesForce.com comme exemple de russite de changement
culturel. Dun autre ct, larticle les six erreurs communes que
Salesforce n'a pas commis, prcise que La direction a vu la
transformation, non pas comme une nouvelle approche, mais plutt
comme un retour aux valeurs fondamentales de l'entreprise [Denning].
Donc ce ne serait pas un bon exemple puisque les valeurs de l'quipe de
direction n'ont pas chang. Il semblerait que dans ce cas, lAgilit a t
utilise pour traiter la drive de la culture cause par la croissance et
l'introduction dun niveau de management intermdiaire. Je me rappelle
dune histoire similaire sur le retour la culture d'origine chez Yahoo qui a
galement fait une transition d'entreprise vers Scrum.

Au Rassemblement Scrum 2012 Atlanta, Andrea Tomasini de Agile 42

et Hendrik Esser dEricsson ont restitu une tude de cas dans laquelle
Scrum a t utilis pour aider un ple de 2000 personnes trouver sa
voie aprs avoir fait sauter la hirarchie et lorganigramme. Scrum a jou
un rle dans la sensibilisation et la prsentation de ce qui tait possible,

65
ainsi que l'excution de la transformation Agile. Le management a t
pouss par l'volution du march et les plaintes, l'insatisfaction et la
frustration des employs, considrer le changement. Ainsi, un lment
cl de la transformation a t le moment auquel l'quipe de direction a
mis de ct ses proccupations oprationnelles pour passer six mois
travailler sur la refonte de l'avenir de la socit. Il semble quune
gouvernance de type traverser l'ocan et brler le bateau est cl pour
russir une transformation. Dans ce cas, Scrum a agi comme un
catalyseur de changement, mais ce n'tait pas le processus de
changement lui-mme.

Chirurgie Radicale

NUMMI tait une joint-venture dans laquelle Toyota a travaill avec GM

pour changer la culture dans une usine de fabrication de GM [Shook -
NUMMI]. Observez les extraits suivants des rsultats et modifications
apports :

Nous avons fait passer la qualit de l'usine de GM de la pire la

meilleure - pas seulement de mauvais bien, du pire au meilleur - en une
seule anne.

J'ai toujours soulign, comme je l'ai fait plus haut, que la main-d'uvre
NUMMI tait la mme quavant en termes deffectifs. C'est vrai. Ce que je
nai parfois pas le temps d'ajouter, c'est quil est galement vrai que les
travailleurs taient les mmes, mais les managers... tous les managers
taient nouveaux. Ils peuvent avoir t de GM, Toyota ou embauchs,
mais ils taient nouveaux pour NUMMI.

Dans ce cas, le changement de culture a t ralis en remplaant

l'quipe de management. Dans la plupart des contextes, ce n'est pas
seulement impossible mais aussi indsirable. Ceci est cohrent avec des
rapports indiquant que la rsistance du management intermdiaire au
changement est un obstacle majeur la transformation.

Transformation - Une Personne la Fois

66
Qu'est-ce que cela signifie pour une organisation de se transformer ?

Prenons la dfinition suivante d'une organisation : les rseaux

d'apprentissage des personnes crant de la valeur [Appelo - Stoos
Network]. Une organisation ne peut se transformer que dans la mesure
o les membres de cette organisation subissent la transformation.
Chaque personne au sein de l'organisation a besoin de progresser dans
la transformation son propre rythme. Quand une organisation ncessite
un changement un rythme plus rapide que celui que certaines
personnes peuvent supporter, cela se traduira par des changements de
personnel avec des dparts et des arrives.

Je pense lAgilit ou tout autre systme de culture dorganisation

comme un virus qui se propage et infecte les gens. A travers le
coaching Agile dquipes, je peux voir quand les gens percutent et ont
fait le saut vers un tat d'esprit Agile. La rsistance au virus Agile (et au
changement) diffre selon les organisations et les individus.

La Transformation Agile par Accident Endommage les

Entreprises
Avant daller plus loin, il est absolument essentiel de bien indiquer que la
vaste majorit des organisations ne veulent pas de transformation. Je nai
pas encore travaill avec une entreprise qui ait compris ce qutait une
transformation et qui ait souhait la vivre. Lanne dernire quand jai
clarifi avec des pratiquants Agile ce qutait la transformation et ce
quelle reprsentait, seules de trs petites entreprises avec un leadership
visionnaire taient intresses par la transformation. En gnral les
leaders et managers veulent rsoudre les problmes avec le minimum de
risques et defforts possibles. Or la transformation reprsente un effort
monumental et un risque significatif.

Considrons une manager typique qui aimerait adopter Scrum pour

amliorer le processus de dveloppement logiciel de son quipe. Elle
pense probablement Scrum en tant que processus ou un cadre de
processus et non en tant que systme de valeur et dtat desprit. Il est

67
peu probable quelle soit consciente que Scrum est une forme de
restructuration radicale qui ncessite un support significatif du
management et de lquipe pour viter lchec.

Encore plus alarmant, de nombreux pratiquants et coachs Agile/Scrum ne

sont pas au courant du foss qui existe entre ce qui est mal compris dans
Scrum (cest un processus) et ce quil implique rellement (une
restructuration radicale). Une analyse claire de la culture et du cadre
prsent dans ce livre contribuerait largement combler ce foss.

Beaucoup dAgents du Changement Oprent un Niveau

dExpertise Accidentel

Sur la base de mon enqute sur lchec Agile, il est douloureusement

clair quen tant que communaut, nous navons pas assez dclairage sur
ce que signifie une adoption ou transformation Agile/Scrum. Beaucoup de
pratiquants ont, sans aucun doute, une comprhension raisonnable des
mcanismes et (dans une moindre mesure) de ltat desprit Agile ou
Scrum. Ce qui fait cruellement dfaut est une comprhension de la
distinction entre ladoption et la transformation. Considrez le diagramme
ci-dessous.

68
Considrons la question du niveau dexpertise Agile des agents du
changement aidant les organisations confrontes lAgilit. On pourrait
faire valoir le fait que beaucoup dagents du changement Agile sont juste
au niveau Shu du Shu-Ha-Ri. Pourtant, il y a une tape avant le Shu
- o quelquun ne connat pas ou nest pas intress par une comptence
particulire - appele accidentel dans la terminologie de Chapman et
incomptence inconsciente dans le Modle de Comptence Consciente.

Jaffirme que la vaste majorit des agents du changement Agile sont au

niveau accidentel. Les raisons cls sont :

1 Incomprhension de lAgilit en tant que systme de culture et de

valeurs.

2 Incomprhension du pouvoir disruptif de lAgilit en gnral et de

Scrum en particulier.

3 Incomprhension de la diffrence entre ladoption et la

transformation.

69
 4 Souvent aucun cadre dadoption ou de transformation explicite.

5 Alignement faible ou nul avec les buts et objectifs du

management.

La courbe dcrit le niveau courant de comptence autour de

ladoption/transformation Agile. Veuillez noter que la ligne est thorique
car je nai que des informations qualitatives pour tayer cette allgation.
La majorit de la communaut est au niveau de lincomptence
inconsciente avec seulement un petit nombre au del. Bien quil y ait
quelques leaders dopinion partageant des informations prcieuses, il ny
a pas de message cohrent sur lequel tout le monde tombe daccord.
Nous devons dplacer la courbe vers la droite. Mon espoir est que ce
livre aidera y parvenir.

Le temps o, en tant que communaut, nous pouvions prtendre que

lAgilit tait la meilleure invention depuis le pain en tranches et qu'il
suffisait de l'instiller dans n'importe quelle entreprise est rvolu. Les
checs documents ne corroborent pas cela. Donc considrons
maintenant quelques modles qui aident vritablement la
transformation Agile.

Modle de Kotter pour le Changement Organisationnel

Transformer vritablement une organisation ncessite une nergie
constante soutenue durant une longue priode. Kotter numre les 8
tapes conscutives passer pour tablir un vrai changement positif
durable. Elles ont t observes dans diffrentes entreprises ces 20
dernires annes :

1 Crer un sentiment
durgence.

2 Former une quipe de

pilotage puissante.

3 Crer une Vision.

70
 4 Communiquer la Vision.

5 Donner du Pouvoir aux Autres pour Agir sur la Vision.

6 Planifier et Crer des Succs Court Terme.

7 Consolider les Amliorations et toujours Produire Plus de

Changement.

8 Institutionnaliser les Nouvelles Approches.

Le modle est puissant, mais sa mise en oeuvre est un dfi. Par

exemple, le critre mis en avant en tant que sentiment durgence est que
75% du management pense vritablement que le statu quo est
inacceptable. Daprs mon exprience, le management peut vouloir
lAgilit et croire en elle mais chouer sur ce critre. Quand les praticiens
Agile auxquels je parle comprennent ce critre minimum, ils sont tristes
car ils savent que les entreprises dans lesquelles ils travaillent sont loin
de remplir ce critre. Ce phnomne aide expliquer les hauts niveaux
dchecs vcus aujourdhui.

Considrons un objectif personnel tel que lexercice physique. Je peux

vouloir moccuper de mon corps. Je peux savoir que cest une bonne
dcision pour ma sant. Je peux savoir que jaurai plus dnergie si je
mentrane. Je peux ne pas vouloir des consquences ngatives davoir
un excs de poids et des risques de sant. Mais cela ne me fait pas me
lever de mon canap et sortir pour faire un footing. Pour russir
amliorer ma sant, jai besoin de reconnatre que le statu quo ne
fonctionne plus pour moi et de mengager fournir un effort durable pour
ma sant.

Un autre aspect cl du modle est quil nest pas possible de faire de rel
progrs moins que chaque tape soit ralise dans lordre. Donc, sans
une sensation durgence, un effort de changement est condamn
lchec. Pour en savoir plus, allez voir le livre de Kotter Leading Change
[Kotter]. Par ailleurs, Olivier Lafontan a des Jeux de Cartes pour mettre

71
en oeuvre Kotter (trs sympa) si vous tes intresss par lutilisation de
ce modle [Lafontan].

Les implications de ce modle sur la transformation Agile sont frappantes.

Il indique quil doit exister un effort de changement explicite et bien
appuy pour russir. Beaucoup de suggestions de transition mentionnent
le besoin dun appui fort du management, mais lappel de lurgence est
une exigence bien plus claire et convaincante.

Lors de mon cours CSM en 2004, Ken Schwaber parlait dentreprises

tant dans des situations vraiment dsespres (ex : survie dentreprise)
comme de bonnes candidates pour ladoption de Scrum puisquelles
navaient rien perdre. Il est clair que dans de telles circonstances, la
premire tape - un sentiment durgence - serait compltement satisfaite.
Malheureusement, Scrum est souvent "adopt" de nos jours par des
organisations qui manquent de ce sens de l'urgence.

Daprs mon exprience, beaucoup dagents du changement Agile ont

rendu sans le vouloir un mauvais service notre industrie en
entreprenant une transformation sans complte acceptation ou
comprhension des consquences organisationnelles. Je pense que la
trs large majorit des agents du changement Agile essaie de faire le
bien dans le monde. Personnellement, je sais qu beaucoup doccasions
jai voulu que le client volue compltement vers lAgilit pour que son
personnel ait plus de pouvoir et puisse produire de grands rsultats. Mais
ctait mon dsir et mon rve, pas celui des clients. Le dcalage entre les
bonnes intentions et la transformation accidentelle aide comprendre
une cause fondamentale de beaucoup dchecs que nous voyons avec la
transformation Agile.

Conduite de la Transformation
Edgar Schein parle des moyens cls que les leaders utilisent pour
intgrer la culture dans lorganisation [Schein]. Dans son modle, les
principaux mcanismes dintgration sont :

72
 Ce que les leaders regardent, mesurent et contrlent
rgulirement.

La faon dont les leaders ragissent aux incidents critiques et les

crises organisationnelles.

La faon dont les leaders allouent les ressources.

La mise en place dlibre de rles de modlisation,

denseignement et de coaching.

La faon dont les leaders allouent les rcompenses et les statuts.

La faon dont les leaders recrutent, slectionnent, promeuvent et

excluent.

Il est possible pour un leader, nimporte quel niveau de management

dans la hirarchie, dintroduire la transformation lintrieur de sa sphre
de contrle. Il est essentiel que les leaders de transformation indiquent
clairement que tout le monde dans le systme devra changer de
comportement ou bien partir pour laisser la transformation russir.

LAgilit concerne les personnes, et ainsi elles auront tendance tre les
plus importants obstacles. A un moment donn, nous devrons avoir de
srieuses discussions si nous voulons vraiment aller vers lAgilit -
Johnny Scarborough

tude de cas : Dans une grande entreprise de la finance, le

premier jour de mon intervention jai eu une discussion franche
avec le Vice-prsident qui mavait embauch. Jai indiqu que
lquipe avec laquelle il mavait demand de travailler tait un
systme complexe et quil faisait partie de ce systme. La
consquence tait que jaurai besoin de lui donner un retour direct
sur la faon dont ses actions aidaient ou naidaient pas lquipe. Il
tait daccord et je testais son ouverture desprit le lendemain. Il
russit le test et nous avons dvelopp une bonne relation de

73
 travail. Il savra quil tait prt faire ce quil fallait pour soutenir
lAgilit mais au final, lorganisation ntait pas prte.

Les Leaders se Lancent (en Agile) en Premier !

Jon Stahl signale une approche appele Agile De Haut en Bas :
Dirigeants & Leadership vivant lAgilit [Stahl]. Je considre cela comme
la faon d'incuber le leadership transformationnel. Les leaders se lancent
en premier en procdant de la faon suivante :

Vivre les valeurs.

Mener par l'exemple.

Chercher vraiment comprendre leur culture.

tre aussi transparents que les quipes qu'ils dirigent.

Avant de se lancer dans une transformation Agile, Jon montre une vido
sur un environnement de haute crativit pour illustrer l'tat d'esprit Agile
[ABC Nightline]. Puis il demande aux dirigeants :

Est-ce que vous voulez vraiment cela ?

tes-vous prt changer votre comportement pour soutenir cela ?

tes-vous prt vous lancer en premier ?

Retraite de Temenos sur le Leadership

Temenos est le nom donn par Siraj Sirajuddin pour une retraite intensive
qui aide les gens comprendre leurs plus profondes visions personnelles
et la faon dont ils veulent influencer les sphres organisationnelle,
sociale et familiale autour de leur vie. Le cur de l'atelier tourne autour
de la reconnaissance et lapprciation de nous-mmes et des autres en
tant qu'tres humains. Une ide centrale est qu'une quipe de leadership
a besoin de maintenir comme un objectif primordial sa propre sant et
son fonctionnement. Comme selon la dmarche de Jon Stahl, les leaders

74
doivent "incarner le changement qu'ils veulent voir." La principale
diffrence est que Temenos ouvre la voie vers un changement de
mentalit dans un laps de temps trs court.

Autres Approches du Changement Organisationnel

Ce livre na pas la prtention de couvrir lexhaustivit des approches
connues du changement organisationnel utilises au sein de la
communaut Agile. Cela dit, cette section peut constituer un guide de
lecture synthtique pour ceux qui souhaitent aller plus loin :

Bob Marshall a cr un modle qui dcrit une voie d'volution vers

des organisations de plus grande efficacit appele rightshifting
qui se caractrise par la mentalit dominante [Marshall].

Jurgen Appelo dispose dun super diaporama et dun livret sur la

faon de changer le monde [Appelo]. Il y dcrit un mta-modle
compos de quatre modles : 1) Interagir avec le systme, 2)
Soccuper des personnes, 3) Stimuler le rseau dadoption, et 4)
Modifier l'environnement. Cela inclut : Plan-Do-Check-Act et le
modle de lAbme de Moore. Il est intressant de noter qu'il
diffre des autres modles de changement tels que le
Changement Sans Peur et Switch (Interrupteur) [Heath].

75
Et aprs ?
En tant que communaut, notre comprhension du mouvement Agile et
de ses implications est un processus continu en volution permanente.
Cet ouvrage est un premier pas vers une meilleure comprhension des
principales caractristiques culturelles des mouvements Agile, Kanban et
Artisanat Logiciel (Software Craftsmanship). Jai rdig ce guide pour que
vous puissiez travailler avec votre propre culture mais aussi comme
cadre pour comprendre les approches cls de transformation et
dadoption.

Checklist pour les agents du changement

Les checklists sont couramment utilises pour viter les erreurs dues la
routine. Vous trouverez ci-dessous une checklist pour ladoption et la
transformation agile. Cette liste est destine aux agents du changement,
quils soient internes ou externes. En tant quagent interne du
changement, votre client est le groupe que vous accompagnez dans son
adoption ou sa transformation agile.

1 Je connais le problme que mon client me demande de rsoudre,

2 Je connais sa culture dominante, sa culture secondaire ainsi que

les forces motrices au sein de son environnement,

3 Mon client et moi-mme sommes daccord sur les objectifs et

lapproche - simplement adopter les pratiques ou bien aussi
transformer la culture,

4 Je mappuie sur une approche explicite pour ladoption ou la

transformation,

5 Mon client a une bonne comprhension des implications de

lapproche propose,

76
6 Mon client et moi-mme sommes daccord sur le primtre des
personnes inclues et impactes,

7 Mon client sinvestit pleinement pour dployer les changements

requis et dispose du support organisationnel adquat pour russir
ces changements,

8 Le degr dinfluence et de contrle de mon client est suffisant pour

rendre le succs possible,

9 Mon client comprend quen travaillant avec un systme complexe,

le chemin emprunter est mergent et ne peut pas tre dfini
lavance.

77
References
ABC Nightline. IDEO Shopping Cart, 1999, YouTube, Web,
<http://www.youtube.com/watch?
feature=player_embedded&v=M66ZU2PCIcM>.

Anderson, David. The Principles of the Kanban Method. Web. 10

Dec. 2010. <
http://agilemanagement.net/index.php/Blog/
the_principles_of_the_kanban_method>.

Appelo, Jurgen. How to Change the World (slides). Web. 2011.

<http://www.noop.nl/2011/09/how-to-change-the-world.html>

Appelo, Jurgen. How to Change the World. Lulu. eBook. 2012.

Appelo, Jurgen.Stoos Network (part 3): Core Idea. Web. 10 Jan.

2012. <http://www.noop.nl/2012/01/stoos-network-part-3-core-idea.html>.

Beck, Don Edward., and Christopher C. Cowan. Spiral Dynamics:

Mastering Values, Leadership and Change. Oxford: Blackwell,
2006. Print.

Behrens, Pete. The Culture of Agility, Web. 2011, <

http://trailridgeconsulting.com/culture-of-agility.html?
view=slide>

Block, Peter. Flawless Consulting: A Guide to Getting Your

Expertise Used. San Francisco: Jossey-Bass/Pfeiffer, 2000. Print

Buckingham, Marcus and Coffman, Curt. First, Break All the Rules,
What the World's Greatest Managers Do. Simon & Schuster,, 1999.
Print.<
http://www.studergroup.com/newsletter/
Vol1_Issue1/gallups12questions.htm>.

78
Burrows, Mike.Kanban and the Twelve Principles of Agile
Software.Positive Incline. Web. 21 Jun. 2010.
<http://positiveincline.com/?p=727>.

CognitiveEdge. "The Cynefin Framework." YouTube. YouTube, 11

July 2010. Web. 09 Mar. 2012. <http://www.youtube.com/watch?
v=N7oz366X0-8>.

Cohn, Mike. Succeeding with Agile: Software Development Using

Scrum. Upper Saddle River, NJ: Addison-Wesley, 2010. Print.

Cohn, Mike. ADAPTing to Agile for Continued Success (Keynote).

Web.2010.<http://www.mountaingoatsoftware.com/presentations/137-
adapting-to-agile-for-continued-success-keynote>.

Cottemeyer, Mike.Untangling Adoption and Transformation. Web.

January. 2011. <http://www.leadingagile.com/2011/01/untangling-adoption-
and-transformation>.

Denning, Steve. Six Common Mistakes that Salesforce.com

Didnt Make. Web. 18 April. 2011.
<http://www.forbes.com/sites/stevedenning/2011/04/18/six-common-mistakes-
that-salesforce-com-didnt-make/>.

Derby, Esther. Shifting Organizational Patterns. Web. March.

2011. <http://www.estherderby.com/2011/03/shifting-organizational-
patterns.html>.

Elssamadisy, Amr. Agile Adoption Patterns: A Roadmap to

Organizational Success. Upper Saddle River, NJ: Addison-Wesley,
2009. Print.

Fowler, Martin. "SemanticDiffusion." Web. 14 Dec. 2006.

<http://martinfowler.com/bliki/SemanticDiffusion.html>.

79
Gat, Israel. How We Do Things Around Here in Order to
Succeed. Web. Aug. 2010. <http://www.agilitrix.com/2010/08/how-we-
do-things-around-here-in-order-to-succeed/>.

Hartmann, Bob. "Doing Agile Isnt The Same As Being Agile."

SlideShare. Web. 12 Feb. 2010.
<http://www.slideshare.net/lazygolfer/doing-agile-isnt-the-same-as-being-
agile>.

Hartmann, Deborah. Fearless Journey. <http://fearlessjourney.info/>.

Heath, Chip and Heath, Dan. Switch: How to Change Things

When Change Is Hard. 2010. Print.

Iancu, Mihai, Web. <http://agilitrix.com/wp-

content/uploads/2010/03/Fearless-Change-Mindmap-by-Mihai-Iancu.jpg>.

Kotter, John and Heskett, James. CorporateCulture and

Performance.1992.Print.

Kotter, John P. Leading Change. Boston, MA: Harvard Business

School, 1996. Print.

Kniberg, Henrik. Cause-Effect Diagrams. Web. 09 Mar. 2012.

<http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000>.

Lafontan, Olivier."Card Decks for Agile Transitions." Web. 08 June.

2010. <http://leanpizza.net/?page_id=63>.

"Manifesto for Agile Software Development." Web. 2001

<http://www.agilemanifesto.org/>.

Manifesto for Software Craftsmanship. Web. 2009.

<http://manifesto.softwarecraftsmanship.org/>.

Manns, Mary Lynn, and Linda Rising. Fearless Change: Patterns

for Introducing New Ideas. Boston: Addison-Wesley, 2005. Print.

80
Marshall, Bob. The Marshall Model of Organisational
Evolution.Web. 2010 <http://fallingblossoms.com/opinion/content?
id=1006>

Martin, Robert. Quintessence: the Fifth Element for the Agile

Manifesto. Web. 14 Aug. 2008.
<http://blog.objectmentor.com/articles/2008/08/14/quintessence-the-fifth-
element-for-the-agile-manifesto>.

Martin, Robert. "The Land that Scrum Forgot. Scrum Alliance.

Web. 14 Dec. 2010. <http://www.scrumalliance.org/articles/300-the-land-
that-scrum-forgot>.

Mayer, Tobias. The Peoples Scrum. Web. 06 Dec.

2009<http://agileanarchy.wordpress.com/2009/12/06/the-peoples-scrum/>.

Mayer, Tobias. Scrum: A New Way of Thinking.Web. 22 Mar.

2008. <http://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/>.

Merriam-Webster Dictionary, Web.2012. <http://www.merriam-

webster.com/dictionary/>.

Moore, Geoffrey A. Crossing the Chasm: Marketing and Selling

Disruptive Products to Mainstream Customers. New York, NY:
HarperBusiness Essentials, 2002. Print.

Olson, Edwin and Eoyang, Glenda. Facilitating Organizational

Change: Lessons from Complexity Science.Jossey-Bass/Pfeiffer,
2001. Print.

Pelrine, Joseph "InfoQ." : Dealing With the Organizational

Challenges of Agile Adoption. Web. 09 Mar. 2012.
<http://www.infoq.com/presentations/Agile-Adoption-Joseph-Pelrine>.

81
Sahota, Michael. A3 Technique.Serious Problems? Use A3
Technique to Nail em!<http://agilitrix.com/2010/07/use-a3-technique-to-
solve-serious-problems/>

Sahota, Michael. Kanban is a Gateway Drug. Web 2010.

<http://agilitrix.com/2010/06/kanban-is-a-gateway-drug>

Sahota, Michael. Scrum or Kanban? Yes! Web. May. 2012.

<http://agilitrix.com/2010/5/scrum-or-kanban-yes/>.

Sahota, Michael. Vacation Stealth Scrum. Web. May. 2005.

<http://www.slideshare.net/mobile/michael.sahota/vacation-stealth-scrum >.

Sahota, Michael, Workshop Results on Culture. Web. November

2011, <http://agilitrix.com/2011/11/workshop-results-on-culture/>,

Scarborough, Johnny, 2011, Private communication

Schein, Edgar. Organizational Culture and Leadership. Print.

1996.

Schenk, Mark. The Case for Complexity. Web. 16 July. 2009.

<http://www.anecdote.com.au/archives/2009/07/the_case_for_co.html>.

Schneider, William E. The Reengineering Alternative: A Plan for

Making Your Current Culture Work. Burr Ridge, IL: Irwin
Professional Pub., 1994. Print.

Schneider, William. Schneider Culture Survey.SurveyMonkey.

Web. <http://www.surveymonkey.com/s/VVNT5FB>.

Schwaber, Ken. The Enterprise and Scrum. Redmond, WA:

Microsoft, 2007. Print.

Schwaber, Leffingwell and Smits: A CIOs Playbook for Adopting

the Scrum Method of Achieving Software Agility. Web. Published
2005.

82
<http://www.leffingwell.org/Document_Store/CIO_Playbook_For_Adopting_Sc
rum_080805.pdf>.

Scotland, Karl. Thoughts on Kanban Thinking. Web. Dec. 2011.

<http://availagility.co.uk/2011/12/03/thoughts-on-kanban-thinking/ >.

Scotland, Karl. Crystallising Kanban with Properties, Strategies

and Techniques. Web. Aug. 2011.
<http://availagility.co.uk/2011/08/03/crystallising-kanban-with-properties-
strategies-and-techniques/>.

Senge, Peter M. The Fifth Discipline: The Art and Practice of the
Learning Organization. New York: Doubleday/Currency, 2006.
Print.

Shook, John."How NUMMI Changed Its Culture." Lean.org. Web.

30 Sept. 2009. <http://www.lean.org/shook/displayobject.cfm?o=1166>.

Shook, John.Managing to Learn: Using the A3 Management Process to solve

problems, gain agreement, mentor and lead. Web. July. 2010. Lean
Enterprise Institute and Ocapt (in Canada).

Sirajuddin, Siraj. Private communication. 2010.

Smith, Greg, and Ahmed Sidky. Becoming Agile: --in an Imperfect

World. Greenwich, CT: Manning, 2009. Print.

Spayd, Michael. Agile & Culture: The Results. Web. 06 July. 2010.
<http://collectiveedgecoaching.com/2010/07/agile__culture>.

Stack Overflow, Is Agile Development Dead? Web. 19 Nov. 2008,

<http://stackoverflow.com/questions/301993/is-agile-development-dead>.

Stahl, Jon. Agile From the Top Down: Executives & Leadership
Living Agile.SlideShare. Web. 09 Aug. 2011.
<http://www.slideshare.net/LeanDog/agile-from-the-top-down>.

83
Thomas, Dave, Dave Thomas Unplugged Web. Aug. 2010.
<http://agilitrix.com/2010/08/agile-2010-keynote-by-dave-thomas >.

Tomasini, Andrea and Lewitz, Olaf. Cynefin Lego Game. Web.

25 Dec. 2011. <http://www.agile42.com/blog/2011/12/25/cynefin-leg-
game/>.

VersionOne,State of Agile Development Survey Results. Web. 09

Mar. 2012.
<http://www.versionone.com/state_of_agile_development_survey/11/>.

Wikimedia Foundation. "Hype Cycle." Wikipedia. 08 March. 2012.

Web. <http://en.wikipedia.org/wiki/Hype_cycle>.

84
A propos de lAuteur
"En tant que consultant principal de Agilitrix,
ma mission est de changer la vie des gens et
des entreprises avec lesquelles je travaille.
Mme si je suis un leader d'opinion, utilisant
des approches novatrices, et un large ventail
d'outils, ma force principale est l'nergie et la
passion que j'apporte en tant qu'artiste du
changement pour aider mes clients atteindre
leurs objectifs. Bien sr, le but est dtre
meilleur, mais nous pouvons le faire et mettre un sourire sur le visage de
tout le monde."

En tant que Coach Agile / Lean, Consultant et Formateur Toronto, je

travaille avec les entreprises pour acclrer la livraison de valeur.

Avec les quipes de dveloppement, cela peut comprendre l'introduction

de frameworks modernes de livraison de logiciels tels que Scrum ou
Kanban. J'aide les chefs de produit collaborer avec les intervenants et
les clients pour obtenir d'excellents rsultats grce des jeux innovants
(Innovation Games).

Les groupes oprationnels peuvent bnficier davantage de l'application

des pratiques Lean tels que la cartographie de la chane de valeur (Value
Stream Mapping), Kaizen et Kanban pour amliorer l'efficacit.

Ma passion du moment est dutiliser le jeu pour librer la crativit et

obtenir des rsultats rvolutionnaires. En plus d'une varit de jeux et de
simulations, je suis aussi form au jeu stratgique (StrategicPlay ) en
utilisant le Lego SERIOUS PLAY pour rsoudre les problmes
pineux. J'anime et facilite des ateliers Open Space pour de grands
groupes autour des problmes difficiles.

85
Autres vues et Opinions
Cette section donne la parole aux gens qui ont des opinions alternatives
celles prsentes dans ce livre.

Elle sert nous rappeler que, comme Henrik la fait remarquer dans la
prface, personne n'a toutes les rponses et que nous avons besoin de
penser par nous-mmes.

La Culture comme un Contexte pour ladoption et la

transformation Agile
par Olaf Lewitz

Le Contexte est plus quune culture

Je suis entirement d'accord pour dire que pour survivre une

transformation agile nous devons accorder plus d'attention la culture.
Pourtant, mettre l'accent sur la culture comme tant le dfi le plus
important auquel une transformation Agile fait face, est risqu. La Culture
n'est qu'un aspect du contexte, le systme dans lequel nous travaillons,
les autres tant ltat desprit dominant (ad-hoc, analytique, synergique,
chaotique), la situation de l'entreprise, la situation technique (dette
technique, excellence technique,...), la situation organisationnelle (silos,
dislocation, ...). Lequel d'entre eux (la liste n'est pas complte) est le dfi
le plus important de votre transformation agile, cela dpend de votre
contexte et de vos objectifs.

Ce qui conduit mon hypothse personnelle que le dfi n 1 est davoir

fix de mauvais objectifs. De nombreuses organisations tentent une
transition/adoption agile pour de mauvaises raisons (cots, corriger ce qui
est mal fait), sous-estiment les effets sur les gens quand vous les
mancipez, et/ou n'arrivent pas comprendre pourquoi et comment
lAgilit fonctionne en premier lieu.

LAgile nest pas une bonne/meilleure pratique

86
LAgilit est un moyen de trouver une solution mergente dans un
domaine complexe. Il s'agit d'une approche volutive de l'innovation et de
la croissance, respectant les gens qui crent de la valeur. Bien utilise,
elle inspire et facilite une transformation des mentalits et la culture dune
organisation apprenante. Llment dclencheur est l'adoption de
certaines (bonnes) pratiques comme un stand-up quotidien et un support
visuel. Ces adoptions changent la faon dont les gens collaborent et les
incitent repenser leur espace de travail. De nouvelles pratiques
mergent si ce processus d'amlioration se poursuit. Ils ne seront jamais
identiques dans deux organisations diffrentes. Agile ne peut tre
standardis.

Les Indicateurs pour choisir une mthode

Il y a beaucoup d'aspects d'un systme qui pourraient influencer votre

choix dune saveur agile (Scrum, Kanban, XP,...) pour point de dpart.
Le modle dentreprise pour le service ou le produit dvelopp est le
principal facteur que je prends en considration, mais il en existe une
multitude.

Vous devriez tre intress par la culture, sentir les influences

contrastes en elle (je vois pratiquement toujours un mlange des quatre
types de Schneider) et avoir une ide des dissonances possibles.
Comme lAgile dfie le statu quo, vous devez savoir ce que vous dfiez.
Challenger une culture ncessite de la respecter, pas de s'y adapter.

Quelques exemples pour illustrer mon propos : une culture de

comptence (google vient l'esprit) pourrait juste avoir besoin de quelque
chose comme Scrum pour inciter les gens collaborer. Une culture de
contrle peut ncessiter un challenge complet pour rellement changer.
Et dans une culture o la collaboration est dj un atout, Kanban pourrait
tre un outil utile pour visualiser et amliorer le flux (et identifier les
goulots d'tranglement causs par le manque de comptence...).

87
Les organisations ont de multiples facettes, nous devons prter attention
davantage daspects que simplement la culture dominante ou
apparente.

Votre Kanban nest pas mon Kanban

Karl Scotland crit :

Ceci ma fait rflchir comment je placerais les divers lments du

Kanban Thinking (http://availagility.co.uk/2011/12/03/
thoughts-on-kanban-thinking/).

La Pense Systmique - couvre probablement le cadre complet :)

Flux - Contrle (tre sous contrle [stable] plutt que avoir le contrle)
Valeur - Dveloppement personnel, mais probablement proche de la
comptence
Capacit - Comptence, mais probablement proche du dveloppement
personnel

tudier - Collaboration (comprendre collectivement ltat courant)

Partager - Collaboration (la visualisation est une forme de partage de la
connaissance)
Limiter - Contrle (les limites sont un moyen de stabiliser un systme)
Ressentir - Comptence ( quel point sommes nous bons actuellement)
Apprendre - Dveloppement personnel (comment pouvons-nous devenir
meilleurs)

Ce qui de faon intressante nous en donne deux dans chaque

quadrant :)

Kanban est plus quune simple Culture du Contrle

Alexei Zheglov crit :

Jai un certain nombre de dsaccords avec le chapitre La Culture

Kanban est aligne avec celle du Contrle. Je dessinerais le diagramme

88
de la culture Kanban trs diffremment. Je voudrais offrir ces diffrences
en tant que retours critiques.

Je pense que visualiser le flux de travail appartient au quadrant

Collaboration. Les tableaux visuels sont des outils de collaboration
essentiels. Cest loppos de ce qui se passe avec les chefs de projet qui
visualisent les choses dans MS Project. Kanban visualise le flux des
travaux le long des chanes de valeur, ce qui est diffrent des
visualisations habituelles des organisations de type contrle, tel que les
diagrammes dorganisation et les tableaux dindicateurs de performance.
(Michael Sahota: Je suis moiti daccord. Dans le diagramme, il est sur
la bordure, proche du quadrant Collaboration).

Limiter le Travail En Cours cest ce que la science nous dit de faire, donc
je lassocie avec le quadrant Comptence. Pierre, si tu peux faire X dici
la fin de la journe, ce serait formidable arrive beaucoup dans la culture
du Contrle. Cest un flux pouss qui ne respecte pas la limite des
Travaux En Cours. Le flux tir et la limitation des Travaux En Cours
correspond linverse. Par science jentends la thorie des files dattente
(Loi de Little) et la psychologie (car il y a des effets psychologiques
limiter le Travail En Cours). (Michael Sahota: Formidable observation ! Il y
a une opposition entre les aspects processus et efficacit. Je vais mettre
jour le diagramme pour reflter lquilibre entre eux.)

Dans rendre explicites les rgles du processus, processus et rgles

sont des attributs de Contrle, mais explicites suggre la visualisation et
lappartenance lquipe. Je les placerais sur la frontire.

Grer le flux : David Anderson y fait galement rfrence dans le mme

article de blog
(http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanba
n_method/) en tant que mesure du flux. Ce principe est aussi appel
mesurer et grer le flux. Mesurer est un mot important ici, parce quil
signifie mesurer quelque chose dune manire similaire la faon dont
les mesures sont faites dans une exprience scientifique. Et alors nous
grons le flux en nous basant sur ce que nous avons mesur. Je

89
placerais ce principe sur la frontire ou peut-tre entirement dans le
quadrant Comptence. (Michael Sahota: Une autre bonne observation.
Je vais mettre jour le diagramme pour lindiquer).

Globalement, ma version du diagramme sur la culture Kanban est une

forme en L, stirant depuis la Collaboration jusquau Contrle et ensuite
dans le quadrant Comptence - plutt quun cercle centr sur le Contrle.
Toutefois, cela ne change pas la conclusion globale - Kanban en tant
quoutil complmentaire aux mthodes traditionnelles Agile et
lArtisanat Logiciel (Craftsmanship).

Kanban concerne aussi la Transformation !

Jeff Anderson crit :

Mon avis est que Kanban a plus de chance que lAgilit de plaire aux
cultures de contrle. Mais cest un commentaire sur le marketing, et pas
sur ce dont la mthode a besoin pour fonctionner, ou bien sur l o elle
marche le mieux.

Mon souci principal est que dcouper les mthodes agiles majeures par
quadrant culturel peut ncessiter trop de gnralisation. Les
organisations avec lesquelles je travaille semblent dfier ce dcoupage
primaire en quadrants, et je trouve que Kanban, Agile, etc. ont trop de
composants se chevauchant pour proprement correspondre un
quadrant. Je suis daccord quon peut le garder en tte quand on applique
lAgilit sans regarder le contexte, et jai aussi limpression que beaucoup
dorganisations alentour ne sont mme pas au courant de ce quelles ont
besoin dapprendre. Cest courageux de ta part de le dire, bravo.

Ma dernire contre proposition est que je crois que la transformation Agile

est vritablement possible. Mais la meilleure chance dy arriver est au
travers dune adoption agile incrmentale.

Mon avis est que la culture est un sous produit de la pratique et de la

faon dont les gens travaillent. La faon dont ils travaillent ensemble, leur

90
clients, et leurs chefs. Donc si vous pouvez changer le travail, alors tt ou
tard la culture suivra, et la transformation peut arriver, cest juste LENT.

Jai tendance croire que la transformation rapide et radicale est

rserve aux entreprises qui sont proches de la faillite, ce qui mintresse
peu.

Scrum versus Kanban

Jon Stahl crit :

Nous utilisons Kanban pour les quipes qui essayent de pratiquer Scrum
mais, qui cause de leur mauvaise structuration ne russissent pas en
tant ququipe auto-organise.

La pratique de Kanban nous permet de:

Mettre en vidence les rgles qui ne servent rien et qui doivent

tre remises en cause.

Utiliser des limites et des donnes pour valider le fait que des
personnes peuvent tre dans le mauvais rle pour contribuer un
flux continu.

Sassurer que lquipe est collectivement responsable du

processus complet et pas uniquement de sa partie.

Kanban nous permet de commencer appliquer la pense systmique

en tant ququipe unie de faon identifier et supprimer le gaspillage.
Voir le systme dans son ensemble aide rduire le besoin de barrires
protectrices et de rendre les conversations plus faciles avec les autres
quipes. Donc, pour moi, Kanban ne concerne pas tant que cela le mode
Commander & Contrler, mais plutt la comprhension du flux EN
TANT QUEQUIPE. Ds quils ont compris la valeurs des lments et
comment le systme marche, ils peuvent voluer de faon adaptative
vers un meilleur processus.

91