Mon méta-modèle à moi : 3- Les pratiques agiles

C'est un peu la partie de l'agilité d'entreprise que tout le monde connaît aujourd'hui. On parle de "passer en agilité" et on entend parfois souvent par là un mode de gestion de projet, qu'on oppose souvent au cycle en V. Pour reprendre l'image simple d'Ade Shokoya dans Waterfall to Agile, on passe d'un grand cycle expression de besoins>cahier des charges>développements>tests>mise en production pour l'ensemble du produit à une succession de cycles courts qui reprennent schématiquement la même production. Plusieurs de mes collègues seraient d'ailleurs, dans le détail, en désaccord avec cette description parce que, dans un sprint, il n'y a pas un temps pour le développement et un temps pour les tests : dans du développement agile sérieux, tout arrive tout le temps: l'expression des besoins, la solution qu'on leur propose, les tests, l'intégration et même la mise en production continue. Mettant l'accent sur le fait que l'agilité consiste à avoir toujours un produit fini disponible, je serais d'ailleurs d'accord avec cette réserve. Mais enfin, on voit l'idée générale : on va discuter aussitôt que possible autour de produits qu'on peut manipuler et corriger à la fois les erreurs et les demandes au fur et à mesure qu'on avance.

A en juger par le contenu de ses séminaires et de son discours, notre maître Steve Denning semble bien lui-même d'avis que Scrum est le coeur du radical management (=l'agilité d'entreprise=l'innovation continue=le ravissement du client, etc.). Vu que je suis précisément en train d'exposer un modèle qui dit que ce n'est pas le cas, je ne vais pas m'étendre sur les limites de cette approche. Au contraire, on peut remarquer que, dans certains cas, le passage de projets critiques en mode Scrum est un puissant levier de transformation de toute l'organisation. En discutant des conditions de réussite de Scrum, j'ai déjà identifié des vecteurs qui font de l'industrie du logiciel un candidat idéal (le développement représente l'essentiel de la valeur, les profils culturels sont proches, les rôles, produits et marchés sont bien connus, etc. ). L'exemple de Salesforce nous montre la puisssance possible de cette approche de Scrumification. Typiquement, on commence par une "proof of concept" avec un ou deux projets. Des fois, c'est un produit important ; un sur lequel on est en retard et qui semble planté (comme dans l'excellent The Power of Scrum) ; des fois, on commence avec le comité directeur dans une Scrumification waterfall, si j'ose dire, une trickle-down agility. En général, on compte à la fois sur le fait de convaincre les équipes dirigeantes avec des résultats rapides et démontrés ; et sur la capillarité et l'imitation à l'intérieur de la structure.

Ca ne suffit pas forcément. Dans le cas de Salesforce, on voit bien que la culture sous-jacente a épousé Scrum avec enthousiasme, ce qui fait qu'on pourrait presque dire que ce n'était pas vraiment une transformation. Mais si ça n'est pas bien fait, ça peut par contre garantir l'échec. Or, nous sommes tous familiers avec des facteurs d'échec majeurs d'un passage en Scrum:

• L'équipe n'est pas bien définie, ou pas stable
• La vision n'est pas bien définie
• Les bénéfices attendus de l'agilité ne sont pas définis
• Le management ne prend pas Scrum au sérieux
• Il n'y a pas de coaching agile
• On fait du "demi-Scrum" ou du "Scrum à ma sauce", souvent en transformant cet instrument de libération et de progrès des équipes en un apparatus de contrôle quotidien et de flicage total (par exemple le PO ou le Scrum Master se met à affecter les tâches)
• On ne se munit pas d'un vrai PO, par exemple on demande à quelqu'un de la DSI de remplacer les métiers, sans déranger leurs habitudes -- et on rate le point principal, qui est que le client et l'équipe négocient en permanence une vision commune
• On n'a pas la compétence technique suffisante, par exemple pour faire de l'intégration continue et du TDD
• On a choisi un projet qui ne se prête pas bien à l'agilité, comme l'écriture de la Recherche du Temps Perdu
• Insérez votre raison d'échec de Scrum ici

Au moment de développer une stratégie de métamorphose agile, il faut donc se demander

• Est-ce que mes projets agiles sont en condition de réussite?
• Est-ce que, dans mon organisation, la mise en place de projets agiles est possible? (en particulier avec des équipes dédiées)?
• Est-ce que la réussite de ces projets a l'air d'être le moyen le plus efficace pour entraîner toute l'organisation? En particulier, la généralisation de cette transition est-elle facile à percevoir?

Les pratiques agiles, ce ne sont pas seulement les méthodes agiles

Des pratiques agiles sont aussi simplement cela: des pratiques agiles. Il n'y a pas forcément de Scrum, mais il y a des pratiques et des conditions qui sont favorables à l'appropriation du projet commun par tous. La multiplication des privilèges, des injustices et des statuts est par exemple une pratique anti-agile, destructrice d'engagement. Des places de parking attribuées, par exemple, sont humiliantes pour ceux qui n'en ont pas et légitimantes (pas motivantes) pour ceux qui en ont. J'ai connu des clients chez lesquels la hiérarchie était l'alpha et l'oméga de toutes choses. Dans le dernier job d'avocat de ma femme, elle s'est d'abord fait enguirlander pour avoir parlé dans une réunion avant des plus hauts gradés. On peut peut-être comprendre, c'est les manières. Mais elle n'avait pas bien compris la leçon, en fait : ensuite, elle s'est fait enguirlander à propos de l'ordre dans lesquels les destinataires étaient sur la ligne "à" d'un email, ou elle avait apparemment écrit le nom d'un sous-fifre avant celui d'un patron. Je ne sais pas comment on fait pour prendre au sérieux des boites comme çà. Mais je suis sûr qu'elle ne cherche pas à mobiliser la créativité des gens qui bossent pour eux ou leur capacité à tisser des liens durables avec les clients, les partenaires ou les actionnaires. 

Dans Liberté et Cie, Barney et Getz détaillent ainsi à l'envie ce qu'ils appellent "l'abolition des privilèges" dans les "campagnes de libération" d'entreprises. On est d'ailleurs au coeur de pratiques que beaucoup imitent mais peu adoptent pour de vrai -- ainsi tout le monde appelle ses collaborateurs des "associates" partout, de nos jours. Mais chez Gore & Cie, on prend au sérieux le fait que ça reflète effectivement un organigramme très plat. De même, nombreuses sont les sociétés à avoir envoyé leurs cadres en observation dans des usines Toyota et à imiter ce qu'ils croient être les "fondamentaux" (par ex. le KanBan), mais sans les mêmes résultats en termes de paix sociale et de qualité.

Ces pratiques se traduisent aussi, si j'ose dire, en pratique : dans les bureaux, les usages, les cafétérias, etc. Les entreprises "agiles" prêtent souvent un attention particulière à "l'esprit des lieux" de l'endroit où ils travaillent. Chez IDEO, par exemple, agence de design, on a refusé de déménager dans des locaux plus grands mais plus froids et moins centraux. Oh, et d'ailleurs, en parlant de pratique : chez IDEO, les employés ont leur mot à dire (en fait, ils décident même) sur le déménagement.

Mon méta-modèle à moi : 2- La vision partagée

Dans mon expérience, une transformation réussie réussit sur six front à la fois, et ce sont les six dimensions que je vais résumer ici (et détailler dans les posts suivants). A chaque dimension correspondent des outils pour transformer l'organisation. De même qu'il n'y a pas une seule façon d'être agile, il n'y a pas une seule façon de transformer. Dans ma pratique, je propose un travail préalable de compréhension de l'organisation selon ces six dimensions. De cette compréhension se dégagent des axes d'amélioration, des conditions de réussites, etc. Bref, des outils pour initier une stratégie de transformation.

Les six dimensions, que je vais discuter une par une dans les posts à venir, sont:

1. La vision partagée
2. Les pratiques agiles
3. Des infrastructures compatibles
4. Une gouvernance durable
5. Une compréhension de la culture
6. Des managers et leaders capables d'accompagner le mouvement

Après avoir expliqué ces six dimensions, je proposerai d'analyser des exemples de transformation agile réussies pour vérifier si elles traitent bien des six points, explicitement ou implicitement ; et des transformations ratées, pour vérifier si elles ont bien négligé une ou plusieurs des six dimensions.

Une vision partagée

C'est ballot, mais si on veut que chacun dans l'entreprise ait l'autonomie de prendre des décisions dans l'intérêt de l'entreprise, il faut que tout le monde sache ce qu'elle fait, ou au moins puisse en discuter. Dans beaucoup d'organisations, si on ne délègue pas, ce n'est pas (seulement) parce qu'on ne fait pas confiance à ses subordonnés : c'est parce qu'on ne sait pas leur donner le pourquoi de ce qu'on leur demande de faire. Vous aussi, vous avez sans doute connu des ces grosses organisations qui ont des présentations interminables sur leur supposée stratégie, mais qui sont incapables de donner un cadre clair à l'initiative de leurs collaborateurs. La conséquence logique est toujours la même : si on ne connaît pas la stratégie de l'entreprise, sa raison d'être, à chaque doute, on est  bien obligé de demander au patron "qu'est-ce que je fais". Et souvent, lui-même se retourne vers son patron, car les objectifs (et l'autonomie) qu'on lui a donné ne suffisent pas pour trancher)

Si vous ne savez pas à quoi sert votre travail, l'initiative est au minimum dangereuse, et souvent malvenue. L'engagement et la créativité sont, de ce fait, extrêmement improbables. Et la compétitivité dans l'économie numérique, encore plus. Les auteurs de Liberté et Cie schématisent ainsi les entreprises libérées comme des entreprises du pourquoi? plutôt que du comment?

Il faut donc une vraie vision, celle qui permet de définir l'intérêt de l'entreprise et de prendre des décisions en conséquence ; et il faut qu'elle soit partagée. Mais on aurait tort de déduire de cette exigence qu'il faut un de ces "processus stratégiques", suivie de communications argumentées comme préalable à toute transformation. En fait, la construction d'une vision partagée vaut autant pour le process que pour le résultat. Teerlink chez Harley Davidson a ainsi commencé son mandat en proposant aux syndicats, non pas de négocier le prochain accord de branche, mais de construire ensemble une vision pour l'entreprise. Ce faisant, il traitait à la source le "problème" des syndicats du type de ce qu'on a vu chez Goodyear récemment. La même logique existe dans les exemples célèbres de l'usine GM puis Toyota de Fremont en Californie, ou dans la co-gestion à l'allemande. 

De manière encore plus générale, on peut dire que la condition de réussite d'une entreprise agile est une communauté de vue à l'intérieur de l'entreprise, une certaine complicité, une connivence. Dans Booster l'Intelligence Collective, d'Herbemont a ainsi de beaux passages sur la connivence, par exemple dans le personnel de sécurité des centrales nucléaires. Or, contrairement à ce que croient certains grands naïfs, technocrates ou ingénieurs, ce qui fait qu'on se comprends, qu'on met les mêmes réalités sous les mêmes mots, et en fin de compte qu'on n'a pas besoin de passer son temps à se synchroniser pour travailler ensemble, ce n'est pas un dictionnaire, des définitions préalables, un glossaire, ni même une formation. 

Non, ce qui fait qu'on se comprend, c'est qu'on se parle. Ca va plus vite quand on est culturellement proche, d'ailleurs : Michel et Augustin ou IDEO sont ainsi, à la base, des bandes de copain. C'est plus facile de se dire qu'on va se mettre ensemble, et qu'on n'a pas trop besoin de fixer des règles, quand on a ce genre de complicité, un parcours commun, qu'on a été dans les mêmes écoles, etc. D'où d'ailleurs, je le disais dans le dernier post, le succès des méthodes agiles dans le développement informatique, où les cultures ont tendances à être plutôt homogènes. Mais même là, à un moment, il faut bien se dire ce qu'on fait.

Mêmes les bandes de potes et les familles doivent se réunir régulièrement pour échanger et maintenir leur synchronisation. La plupart des PME agiles (par exemple, Blablacar, Deezer) ont ainsi institutionnalisé des moments d'échange réguliers qui sont souvent distincts des moments de pur convivialité, mais où chacun présente aux autres ce qu'il fait.

Jim Collins, l'auteur de Good to Great insiste ainsi sur le fait que les patrons des boites aux performances extraordinaires ont toujours choisi l'équipe avant de choisir le projet. Une vision n'est pas un préalable à une métamorphose agile -- mais une interrogation sur cette vision et surtout un process pour la construire le sont. Ce process de construction de la vision, et aussi le process de révision régulière de ladite vision, font également partie de la troisième dimension, celle d'une gouvernance durable. Pour l'instant ceci dit, il s'agit de se poser la question : partageons-nous et communiquons-nous bien une même vision de notre organisation?

Une stratégie adaptée à l'économie numérique

Beaucoup de patrons vous diront : ah ben oui, j'ai une vision partagée. D'ailleurs regarde : j'ai un mission statement, et puis une shared vision, et je te mets même des valeurs pour pas plus cher. Sauf que : d'abord, il s'agit souvent d'objectifs comptables placés sur une feuille de route. Ensuite, elles ne comportent souvent pas l'analyse appropriée de l'environnement et des ressources de l'entreprise, moins encore de la solution crédible qu'y apporte l'organisation.

Quand la raison d'être de l'entreprise n'est plus adaptée à l'environnement, il faut en changer. On peut partager ensemble une vision claire du type "nous fabriquons des locomotives à vapeur". Ca risque de n'être pas porteur d'une dynamique collective forte. Cet exemple paraît peut-être stupide, mais n'est-ce pas aujourd'hui la situation des opérateurs de télécom, des fabricants de voiture, ou des banques traditionnelles français? Si votre marché n'existe plus, ce n'est pas d'une réorganisation ni même d'excellence opérationnelle dont vous avez besoin. C'est d'une réflexion sur votre stratégie de survie comme organisation.

Dans ce registre, il faut bien reconnaître que l'environnement économique est justement en profonde mutation, rendant ainsi caduques bien des stratégies établies et anciennes. Pour le dire simplement, nous vivons dans un monde où la propriété intellectuelle est caduque, où les tâches mécaniques sont de plus en plus mécanisées (même celles qui valent cher, comme la plupart des avocats), où le travail n'est plus à louer. Le grand gisement de valeur qui existe encore, c'est l'humain : tisser des liens significatifs, être créatif, libérer du temps, donner du sens à l'existence.

Comment une entreprise peut-elle faire ça? Moi, je fabrique des vélos, je fais la cuisine, je produis des bilans annuels. Comment diable est-ce que je pourrai être créatif, donner du sens, ou ravir mes clients? Quand on se pose la question de la raison d'être de son organisation, il faut, de nos jours, se poser ces questions, et ne pas faire l'hypothèse qu'on est dans un marché à l'abri de la révolution numérique et globalisante.

Pour ma part, je propose qu'une grande partie des éléments de réponse peuvent être trouvés dans l'exemple Google. Dans What Would Google Do, Jeff Jarvis détaille longuement les fondamentaux du succès de Google. J'y reviens dans plusieurs posts, mais en raccourci, il s'agit de s'adapter à une économie en réseau ; de se spécialiser ; d'offrir une plateforme plutôt qu'un produit à ses clients, c'est-à-dire la possibilité de produire eux-mêmes, voire de créer de la valeur ajoutée ; d'accepter la co-construction et le dialogue permanent avec le client et les autres parties prenantes et d'en tirer parti ; de s'approcher autant qu'il est possible de la gratuité, pour maximiser en priorité son réseau et sa communauté, plutôt son flux de revenus...

Mon méta-modèle à moi : 1- Les mille et une formes de l'agilité d'entreprise

Par agilité d'entreprise j'entends au sens large l'adaptation de l'entreprise à l'ère numérique : il ne s'agit pas seulement d'être rapide, réactif et innovant ; il s'agit, plus profondément, de tisser des liens de confiance dans la communauté qu'est l'entreprise. Avec les clients, bien sûr, mais aussi entre collaborateurs et avec les autres parties prenantes, comme les fournisseurs et les actionnaires.

Pourquoi parler d'adaptation à l'économie numérique? Pour faire simple, parce que nous vivons une époque où le savoir, le travail, ou les matières premières ont de moins en moins de valeur en soi. Parce que, ce qui crée encore de la valeur dans notre économie numérique mondialisée, ce sont les liens significatifs, et les choses qui nous libèrent du temps et changent notre rapport au monde.

Et comment on fait ça? En gros, par la mobilisation de toutes les intelligences et de tous les enthousiasmes. En faisant en sorte que les gens qui travaillent soient engagées de toute leur personne dans leur travail, ce qui n'arrive si le projet n'est pas le leur.

Ca, c'est l'idée d'ensemble -- le syllogisme, en termes hégéliens. J'espère bien qu'on pourra discuter de ses termes en détail bientôt. Mais le thème d'aujourd'hui est : il n'y a pas une seule façon d'être agile. Il ne s'agit pas d'appliquer systématiquement un même modèle ou une même structure. C'est d'ailleurs ce qui est trompeur (quoique magique) avec Scrum et les méthodes agiles : ça vous laisse croire qu'il n'y a qu'à faire les mouvements, et ça va changer la vie. Ca marche, des fois. Mais en général, il y a au minimum beaucoup de pré-conditions à ce que ça marche : déjà, pour faire du Scrum, il faut une équipe, une idée de produit, et un client ou un représentant du marché bien identifié. En plus, il faut en général que l'esprit de la transformation soit compris, et c'est moins simple que ça n'en a l'air : laisser les équipes s'auto-organiser, être toujours prêt à aller au marché, foncer vers les problèmes et les difficulté, le tout avec un rythme vraiment soutenable et un effort constant de synchronisation et de négociation avec toutes les parties prenantes. Et puis il y a toutes sortes de condition à l'échelle de l'entreprise. Ainsi, si Scrum marche si bien pour les boites de développement informatique, c'est grâce à un certain nombre de spécificités, en particulier:

• la chaîne de valeur porte en très grande partie sur le travail de développement pris au sens large (yc specs et produits)
• les développeurs ont généralement une culture commune
• les équipes existent déjà, dont souvent déjà au même endroit
• la répartition des rôles et le découpage du travail se font assez facilement, assez naturellement
• la qualification élémentaire du produit, de ce que fait l'équipe, est en général peu problématique
• de même, l'identification du marché et du client

Or donc, l'agilité a mille et uns visages : on peut partir du ravissement du client et de Scrum, comme aime à le faire Steve Denning (The Leader's Guide to Radical Management) ; on peut la voir comme un partage de valeurs, de passions et de sens, comme Tony Hsieh (Delivering Happiness : A Path to Profit, Passion and Purpose) ; elle est aussi une dynamique tribale, comme chez Dave Logan (Tribal Leadership); comme dit l'autre, Agile is the new Lean, et les consultants qui ont peu d'imagination aiment d'ailleurs à réduire l'un à l'autre ; fondamentalement, ça reste une question de liberté des travailleurs, comme dans Freedom Inc ; et ça ne peut arriver que si les leaders sont à la hauteur des enjeux, et, au minimum, ne se mettent pas en travers du chemin. Idéalement, on voudrait même qu'ils insufflent l'agilité, i.e. l'appropriation du projet par les collaborateurs et la mobilisation de tous les talents -- c'est ce qu'étudie Bill Joiner, par exemple (Leadership Agility).

Une usine Toyota, c'est agile, et pourtant, c'est plein de règles hyper-précises, yc où on doit porter son regard et quelle main on doit utiliser. Oui, mais les ouvriers sont propriétaires de ces process : ils ont bien la liberté de les changer. Il se susurre même que certaines modifications sont mises en oeuvre sans que leur valeur soit démontrée, mais pour assurer l'engagement des collaborateurs. Inversement, des environnements radicalement libres sont aussi agiles, comme FAVI ou comme IDEO. Ce n'est pas l'existence de règles qui fait l'agilité ou son manque : c'est la réalité de l'engagement, et de la satisfaction profonde des gens qui travaillent ensemble. Une entreprise agile, c'est une entreprise où on reconnaît que la valeur dans l'économie d'aujourd'hui est spécifiquement humaine, jamais mécanique.

Je n'ai jamais rencontré d'organisation qui ne soit pas agile : ce qui fait qu'on produit quelque chose, c'est qu'il y a forcément un certain niveau d'engagement des gens qui le font. L'idée que les travailleurs suivent des procédures et font ce qu'on leur dit est démentie par plus d'un demi-siècle de sciences sociales et par l'expérience de chacun. C'est même ce qui explique que, selon les enquêtes, on vous dise que les gens aiment leur travail (sinon, ils ne pourraient pas le faire), et qu'ils sont désengagés (ce qui coûte très cher). Notre expérience à tout un chacun est bien que chaque individu innove, s'adapte au quotidien pour faire son boulot, et ne fait pas que suivre des instructions.

Ceci posé, dans le prochain post, je partagerai une grille de compréhension de l'organisation que je propose à mes clients pour comprendre leur niveau d'agilité actuel, expliciter leurs objectifs, identifier leurs forces et les incohérences de leur organisation.

La motivation intrinsèque, piqûre de rappel

Dans cette Keynote, Dan Pink nous livre la substantifique moelle de son livre : Drive: The Surprising Truth about What Motivates Us

Son message central: la carotte et le bâton ne sont pas efficaces pour motiver les gens dont le travail n'est pas purement mécanique. Ce n'est pas une conviction ou un rêve, c'est un des faits les plus solidement établis par les sciences sociales... et les plus ignorés par les entreprises partout dans le monde.

Ce qui motive les gens pour un travail intellectuel, ce sont l'automomie, la maîtrise, et le sens, nous explique Pink. C'est ce qu'on appelle les motivations intrinsèques (ça me plaît, ça fait sens, j'aime ça...) par opposition aux motivations extrinsèques (sinon je vais me faire virer, je ne pourrais plus nourrir mes enfants, et au contraire un jour j'aurai une Aston Martin).

On est là au coeur de ce que doit être l'agilité d'entreprise bien comprise : pour être réactif dans un marché changeant, pour créer de la fidélité chez des consommateurs zappent, pour innover en continu dans un monde où aucun avantage ne dure, la seule vraie source de valeur est l'engagement des collaborateurs et des parties prenantes. C'est l'idée de base de la transformation qu'on appelle agile (mais qu'on pourrait appeler d'une autre nom, ajulien par exemple, ou campagne de libération, ou métamorphose, etc.).

Pour ma part, en ce qui concerne le bonheur au je garde comme boussole les principes qui font le bonheur en Scrum: 

- Control : je suis aux commandes (l'équipe auto-organisée en Scrum)

- Progress : je me vois progresser (la valeur créé à chaque itération, la mesure de la vélocité, les rétrospectives pour l'amélioration continue)

- Belonging : l'engagement solidaire avec le reste de l'équipe, les échanges fréquents avec le PO qui construisent une appartenance et une vision comune

- Purpose : la conviction que ce qu'on fait sert à quelque chose (vision du produit et, au-delà, peut-être de son impact social).

Travailler dans une compagnie à haute performance

On savait déjà que les "Best places to work" étaient des compagnies plutôt plus performantes que la moyenne. Mais dans l'autre sens, comment ça marche? Ce billet de blog reprend les conclusions d'une étude qui suggère qui analyse les compagnies à haute performance et suggère que:

1. Les collaborateurs se sentent effectivement mis en valeur
2. Ils ont beaucoup d'autonomie
3. Ils travaillent en équipe
4. Leur développement personnel est important pour l'entreprise

Mais

1. Ils travaillent beaucoup
2. Ils ne se sentent pas surpayés

Agile est-il français?

Une des questions récurrentes que nous nous posons dans notre pratique est : dans quelle mesure l'agilité (sous ses différentes incarnations) est-elle compatible avec une culture française? Une méthode qui supprime l'argument d'autorité dans une culture basée sur le statut? Une culture de l'engagement solidaire dans un pays dont la politique est la spécialité? Une obligation de dire les choses dans une langue faite pour les insinuations? La négociation et la recherche de l'intérêt commun dans un pays qui aime les batailles de village gaulois? De l'empathie en France ? De l'égalité dans une société de cour ?

Voici une première réflexion sur le sujet, dont j'espère bien que ce n'est que la première d'une longue série :

Agile software development and French culture

Transparence et agilité

Je vois bien, comme tout le monde, qu'agilité et transparence ont partie liée. Et jusqu'à récemment, je pensais que ça avait surtout avec à voir avec les valeurs sous-jacentes, et aussi un peu avec les modes de coordination. On est transparent parce qu'on veut un lieu de travail où règne la confiance, et aussi parce que c'est un moyen de coordination entre différentes équipes (voyez par exemple ut7, entreprise sans managers, mais où la transparence financière permet à tous de comprendre la situation de la boite et de se faire une idée informée sur ce qui est dans son intérêt).

Mais en relisant The Power of Scrum et en repensant à Employees First, Clients Second (où la transparence s'avère un puissant levier de transformation), et puis aussi en essayant d'expliquer l'agilité à de plus en plus de gens, je me suis dit qu'il y avait un rapport plus profond. Qu'y a-t-il au coeur de Scrum et des autres méthodes agiles? Il y a un produit qui est toujours prêt. Il n'y a plus jamais de long tunnel où on passe des mois à construire un produit qui n'existe pas. Ca veut dire, entre autres, que tout ce qu'on fait est impeccable, que la qualité est continue.

C'est comme dans une cuisine moderne et de haute volée : quand vous regardez Robuchon cuisiner, vous voyez que le moindre taillage de carotte est superbe, digne d'intérêt, et reflète la vision du produit final. Du coup, Robuchon a pu ouvrir sa cuisine, littéralement, à l'Atelier : vous voyez les chefs cuisiner (ou, pour être honnête, en tous cas la partie finale de leur travail). Dans beaucoup d'activités artisanales, on a justement cette exigence que tout soit toujours impeccable -- on range et on nettoie au fur et à mesure, de même qu'on teste et qu'on refactore, en agilité, au fil de l'eau.

La transparence n'est pas seulement cohérente avec ce mode de développement: elle l'encourage et le récompense. Dans Employees First, Customers Second, ce facétieux de Vineet Nayar prend l'exemple des fenêtres sans rideau aux Pays-Bas qui, explique-t-il, font que la maison de chacun est toujours impeccable.

En agilité, la transparence, c'est ce qui fait qu'on sort complètement de l'effet tunnel, non seulement celui où on développe un produit pendant des mois, mais aussi celui où un individu maintient l'obscurité sur comment il avance sur sa tâche du jour. Ouvrir la cuisine, c'est donner la garantie que tout est impeccable et exemplaire, montrable, d'un bout à l'autre, en continu.