Allez, c’est le dernier de la saison, après Rennes et Vannes. Toujours aussi bien organisé, là aussi, on sent l’équipe qui roule. Ci-dessous un rapide retour sur les sessions que j’ai suivies.
Keynote du matin
Tout d’abord, la conférence centrale du matin qui mettait à l’honneur Alexandre Gérard, de Chronoflex. Il est PDG de cette société qui est une des rares à avoir suivi le modèle de Favi, inspiré par Jean-François Zobrist. J’avais vu ce dernier à une présentation dans le cadre du CJD, et j’avais été proprement estomaqué par l’approche radicale de sa méthode et les résultats incroyables qu’elle apportait. Ce fut également le cas d’Alexandre Gérard, qui en temps que dirigeant a décidé de se lancer.
Il parle de saut en parachute pour bien faire mesurer le changement que cela représente. Le PDG ne prend pas les décisions, mais il fournit un cadre pour que les employés puissent s’épanouir et prendre les décisions par rapport à ce qu’ils peuvent faire. Etant donné qu’ils sont le plus proches de leur métier, ce sont souvent eux qui auront la meilleure idée pour résoudre les problèmes. Surtout, on remonte souvent aux chefs que ce qui ne fonctionne bien, ou alors en embellissant, ce qui fait que les problèmes sont poussés sous le tapis.
Concrètement, les changements peuvent paraître simple, mais représentent déjà un grand changement par rapport à beaucoup de boîtes : abandon des symboles de pouvoir comme le grand bureau ou la place de parking dédiée la plus proche, etc. Les plus grands changements sont bien sûr dans l’organisation du management. Les embauches, ouvertures de postes, stratégies et primes sont décidées par le groupe, de manière sociocratique. Les décisions les plus dures ne sont pas laissées de côté, avec le groupe qui prend ses responsabilités pour demander si besoin le départ d’un collègue qui ne veut pas s’intégrer au groupe.
Après avoir vu JF Zobrist, l’orateur l’a recommandé à d’autres personnes, qui à leur tour lui ont conseillé de lire Isaac Gates, et en particulier le livre “Freedom Inc.” (ou “Liberté et Cie, en français). Il a ensuite rencontré Isaac Gates et l’a convaincu de le rejoindre dans un club qui travaillerait sur la “recette” de Favi et comment l’appliquer à d’autres industries de manière plus générale.
Je ne vais pas trahir la recette ici, mais juste reprendre quelques points qui m’ont le plus marqué. Le premier est, comme je le disais plus haut, que le responsable ne doit plus être un “chef” pur, mais avant tout un facilitateur, un support pour que l’équipe et chaque personne soit dans un environnement favorisant sa montée en compétence et son appropriation de son travail. L’idée n’est pas de “motiver” les gens (comme si c’était possible par une action exogène), mais de leur fournir un environnement de travail au sens large qui fassent qu’elles soient naturellement intéressées à leur travail, qu’elles le prennent à bras-le-corps. Pour le manager, c’est simplement faire confiance au fait que la personne est bien plus indiquée que lui pour prendre les bonnes décisions sur son travail. Elle en maitrise mieux les impacts.
Le second est que le manager doit arrêter de donner des ordres, mais passer la plus grande partie de son temps à écouter les personnes qui sont en charge de la réalisation. Il doit être à l’affut du moindre signe de problème, et immédiatement voir comment il peut faire en sorte de donner à la personne les moyens qui lui manquent pour travailler comme elle le souhaite. La seule centralité du manager, à la fin, ne doit plus être le positionnement “haut de la pyramide hiérarchique”, mais plutôt une centralisation de la vision partagée de l’entreprise.
Une petite réflexion personnelle sur quelque chose qui peut apparaitre comme un paradoxe : l’approche de JF Zobrist, appliquée par A Gérard, est basé sur la confiance dans les personnes et leur amour du travail bien fait si on ne les bride pas. Bref, l’inverse des pratiques de management dures où on considère qu’il faut “mettre la pression” sur les gens. Il serait toutefois faux de penser qu’on est dans le monde des bisounours, et que c’est une philosophie baba-cool. L’orateur le dit lui-même, en décrivant son passage à cette méthode comme un saut en parachute. Il faut un sacré coup de pied au derrière pour faire un tel pas. Dans le cas de Chronopost, c’est une brusque chute d’activité, mettant la société en danger de disparition, qui a été le déclencheur. Et si très peu d’autres entreprises ont tenté l’approche, c’est qu’il faut un changement de barre radical, une volonté forte de forcer l’organisation au changement (et pas les personnes). Bref, du courage… On en revient souvent à cette notion agile.
Tout ce que vous avez toujours voulu savoir sur les entreprises auto-organisées
La toute première chose que cette session m’a apprise est que j’utilisais depuis des années l’expression Open Space sans savoir ce que ça recouvrait. Pour moi, c’était juste des bureaux sans cloison. En pratique, ce décloisonnement avait pour principe de faire en sorte que chaque personne puisse participer sur le travail dans lequel elle se sentait le plus à l’aise.
Le but de l’auto-organisation est en effet de donner uniquement la vision, et de ne pas dire aux personnes comment réaliser leur travail. On est proche de l’esprit de la keynote, où on reconnait que la meilleure personne pour organiser son travail est justement celle qui le réalise.
Un des retours de l’intervenant est d’expliquer que, malgré le fait qu’ils prennent dans son équipe toutes les décisions ensemble, cela ne s’étend pas à la définition de la vision, car ça prendrait trop de temps. Il recommande donc de partir de la vision d’une personne, et de faire immédiatement intervenir une collaboration forte pour transformer cette vision.
L’intervenant prône le courage de parler de tout dans une équipe, de façon à faire apparaitre au plus tôt les points qui pourraient devenir des grosses difficultés plus tard. Il faut pour cela une bonne dose de courage dont il fait lui-même preuve en expliquant leurs soucis de mise en redressement judiciaire au début de leur aventure. Ca ne rend que plus enthousiasmant leur actuel succès.
Il cite comme exemple de ce qu’il ne faut pas faire le réflexe d’embaucher quelqu’un pour faire ce que personne dans le groupe n’a envie de faire : le fait de réfléchir sur pourquoi c’est une contrainte, de discuter d’autres méthodes, aurait fait naitre une collaboration autrement plus intéressante dans le groupe.
Le point le plus positif, de mon point de vue, est que c’est un REX très pratique, avec de nombreuses explications au jour le jour. Par contre, il faut une maturité d’équipe très forte pour en arriver à ces pratiques sociocratiques. A commencer par des cercles, déjà, lors des points d’équipe.
Les enjeux du Kanban pour changer notre approche du travail
Laurent Morrisseau, le spécialiste du Kanban, présente cette conférence qui n’est pas tout à fait pour débutants, mais repose des bonnes bases pour la compréhension de Kanban. Les équipes Scrum croient en effet souvent faire du kanban à partir du moment où elles suivent un management visuel en collant des post-its. Kanban est beaucoup plus que cela dans le sens où il représente un workflow, avec pour but d’identifier la gestion du temps, de limiter les entrants, et au final de favoriser le flux tiré.
Dans Kanban, la satisfaction client est améliorée surtout par la gestion meilleure du temps : Time To Market, mais aussi Juste A Temps (l’art de retarder au maximum les décisions pour éliminer le maximum d’inconnue).
Quelque chose de marquant est que le temps d’attente lors du traitement d’une demande, rapporté au temps de bout en bout, est souvent de l’ordre de 90%. Cela s’explique par le morcellement du travail et surtout par le fait que des buffers sont réalisés entre chaque étape. Le but est d’avoir tout le temps du travail (pour ne pas “perdre de temps”), mais au final, ça ralentit le temps de cycle. Du coup, si on souhaite réduire ses délais, c’est vraiment sur cela qu’il faut travailler : ça ne sert à rien d’essayer d’améliorer l’exécution, car même avec beaucoup d’efforts, le gain sera obligatoirement très limité.
Une des pratiques les plus importantes est la limitation du nombre de tâches dans une colonne, de façon à ne pas livrer plus que ce que le client peut recetter / utiliser, ne pas tester plus que ce qu’on peut livrer, ne pas développer plus que ce qu’on peut tester, et ne pas faire plus de specs que ce qu’on peut coder. Dans le dernier cas, du stock peut paraitre anodin, mais une spec coûte quand même son analyse, ainsi que le fait qu’une fois stockée, elle perd de sa pertinence.
Un bon logiciel pour le Kanban est, selon Laurent, LeanKit, même si l’approche manuelle reste une référence en terme de souplesse.
Keynote de l’après-midi
Original de faire deux keynotes dans la journée, mais je trouve personnellement que c’était une très bonne idée. C’est parfois dur de choisir parmi quatre parcours, alors quand il y a une personne experte qui vient, ça vaut le coup de lui faire prendre la parole devant tout le monde. F.Dufau Joël est le genre de personne charismatique qu’on a plaisir à écouter même lorsque le sujet n’est pas celui qu’on aurait choisi sur une conférence en particulier.
A voir : http://blog.germe.com
L’orateur explique la méthode “World Café”, pour apprendre à poser les bonnes questions, ce qui prend souvent beaucoup plus de temps que la décision elle-même.
Une autre astuce est de faire de l’analyse “pre mortem” : en quelques mots, il s’agit d’écouter les sceptiques pour modéliser l’anayse de risques, sachant qu’ils remontent parfois également des solutions de mitigation de ces risques. Je vais essayer de me servir de ça pour l’urbanisation, car on rencontre encore beaucoup de sceptiques, malgré que le mouvement soit maintenant enclenché et à peu près certainement parti pour aboutir. Avec quelles technos, on ne sait pas encore, mais c’est le sens de tous les SI de se complexifier en intégration, et donc de nécessité un degré supplémentaire d’indirection.
L’orateur cite en dernier le “casino game”, qui est apparemment une très bonne méthode pour faire découvrir les enjeux et avantages de l’agile.
De l’idée à la réalité : ce que Kanban a changé dans notre centre de services
Un autre REX, très appliqué puisque la personne qui a suivi les conseils de Dorothée Le Seach était là pour témoigner de l’intérêt, mais aussi des difficultés de mise en place, d’un Kanban pour une équipe de centre de services informatiques.
Je ne refais pas toute l’intervention, ce n’est pas le but, mais juste quelques idées piochées par ci par là dans ce retour d’expérience bien riche. Déjà, faire porter la rétrospective par une personne neutre.
Marrant comme les équipes ont déformé le concept de VIP Card (carte ou post-it unique équivalent de la voie prioritaire dans un tableau de management visuel, à savoir possibilité de faire passer une et une seule tâche en priorité sur toutes les autres). Les équipes de Noémie parlent de “Vieille Picarde”. Au début, je me demandais si on était de la même région, et que ses équipes la traitaient de vieille 
A suivre le hashtag #KanbanCDS pour plus de retour de la part de l’équipe, qui s’est totalement approprié le Kanban qu’elle a mis en place et qui, selon les dires de tous dans la vidéo, ne pourrait plus s’en passer. Félicitations à eux !
Intéressant de voir que toute l’approche Kanban a été portée dans un premier temps en se cachant du client. Quand on travaille au bug, il y a du coup une certaine liberté à organiser la méthode, puisque cela se fera sur du temps non facturé. Mais quand on est sur du temps facturé, ce n’est pas le cas, et si on réfléchit à un changement de méthode, on peut avoir un client qui refuse qu’on passe du temps dessus, même si c’est pour améliorer le service rendu. Chez les éditeurs, c’est un peu pareil pour la prise en compte des besoins clients : même si la technologie sous-jacente devrait s’effacer au profit du service rendu et du respect de l’exigence, on se retrouve souvent à suivre des contraintes purement techniques. Dans certains cas, c’est justifié par le besoin d’homogénéité du parc logiciel. Dans d’autres, c’est juste une habitude qui est prise et qui éloigne au final de la satisfaction client.
Un conte pour changer sa perception de soi, des autres et du monde
Christophe (dont je n’ai pas noté le nom de famille) nous a gratifié d’un beau conte sur la réalisation de soi. Très inspirant. Il l’a trouvé sur internet, mais le raconte d’une façon très personnelle. Excellente idée des organisateurs d’avoir introduit cette approche dans les conférences. Je ne suis pourtant pas un artiste dans l’âme (il n’y a qu’à voir comment je m’habille), mais je suis convaincu que le théâtre pourrait apporter énormément en entreprise, pour favoriser la communication dans les équipes.
Notre session
Ou, devrais-je dire plutôt dire, malheureusement, ma session, vu que mon collègue Johan Le Lan, le pauvre était complètement aphone. Du coup, j’ai sérieusement brodé autour du sujet, mais je suis content, je suis resté dans le timebox à une minute près (à part les questions).
Toujours très enthousiasmant de parler devant un bon nombre de personnes intéressées. Le feedback informel était bon, et un des organisateurs m’a dit qu’un urbaniste informatique de la SNCF avait apprécié nos métaphores pour expliquer l’essence de l’urbanisation. Rien que pour ce retour, ça valait le coup de passer du temps à monter cette conférence !
Les deux questions à la fin étaient :
- Comment éviter la “tour d’ivoire” ? J’ai répondu par l’abandon des signes extérieurs, genre bureau à part ou autre. Perso, je me suis récemment installé au plus près des équipes qui auront besoin d’un urbaniste, quitte à abandonner mon bureau avec fenêtre et retourner à la cave, sous l’escalier, au coin. Aussi, j’essaie de ne pas diffuser les schémas que je fais aux équipes, mais plutôt des bonnes pratiques et des explications de la vision pour qu’elles montent les workflows BPMN par elles-mêmes.
- Comment choisir entre des services métier ou orientés ressources ? Pour moi, je ne crois pas aux approches SOA 2.0, WOA ou ROA. Il faut d’abord qu’on fasse proprement du SOA et honnêtement, à part les banques et assurances, il n’y a personne qui en fait aujourd’hui, en tout cas sur le domaine que je connais. Quelques-uns de nos clients ont une approche urbanisée, mais nous sommes en phase d’évangélisation pour beaucoup. Alors, parler de SOA 2.0 parait extrêmement prématuré. Pour ce qui est de ROA plus particulièrement, l’approche n’a finalement qu’une importance technique: est-ce qu’il vaut mieux appeler une fonction de paiement sur une entité subvention ou est-ce qu’il vaut mieux créer une ressource de type paiement ? Si la deuxième entité a un sens conceptuelle pour le client utilisateur, la deuxième solution parait la meilleure. Sinon, l’un comme l’autre sont correctes.
Le prétotyping : assurez-vous que vous êtes en train de développer le bon produit
C’est toujours dur de faire la dernière session de la journée, mais l’intervenant s’en est tiré comme un chef, avec de nombreux exemples très percutants.
Des remarques comme “nous avions un super produit que nous n’arrivions pas à vendre” sonnent particulièrement à mes oreilles. Ca m’est arrivé dans chacun de mes emplois en informatique. Et même en mécanique d’ailleurs, quand je travaillais l’été en atelier d’estampage.
Quelque chose de très intéressant est la statistique sur les échecs des nouveaux produits ou idées, mais surtout la remarque : le taux d’échec ne dépend pas de la qualité d’exécution. Bref, une idée a le même pourcentage de chance d’échouer si elle est bien ou pas bien réalisée. Ce qui fait la différence est uniquement si elle est en adéquation au besoin. Bref, il vaut toujours mieux avoir le bon produit que bien le réaliser, en tout cas dans un premier temps évidemment.
C’est là le but du prétotyping : tester le plus vite possible le maximum d’idées, pour voir lesquelles ont un avenir, quitte à avoir une réalisation très légère derrière, voire rien du tout. Un prototype, à l’inverse, nécessite déjà de la réalisation, car il est là pour prouver non pas que l’idée est bonne, mais qu’elle est réalisable. Le but du prétotyping est de tester la valeur de l’idée, en amont de sa faisabilité. Comme ça, on dégage le plus en amont possible toutes les “bonnes” idées qui en fait n’ont pas de public.
Et il y en a souvent des bonnes idées qui ne le sont pas vraiment. Pourquoi ? Parce que la plupart des gens qu’on consulte n’osent pas nous le dire, veulent nous faire plaisir, nous encourager. Personnellement, j’ai appris pendant ma thèse que la franchise absolue avait du bon, même si elle faisait mal. Après que plusieurs personnes que j’avais consultées m’aient toutes dit que mon logiciel apportait un plus, qu’il était bien programmé, que l’approche était bonne, j’ai posé la question à une personne qui s’avéra être un Hollandais. Et les Hollandais sont “blunt”, c’est-à-dire qu’ils ne s’embarrassent pas de pincettes et disent directement ce qu’ils pensent. Dans mon cas, mon interlocuteur m’a dit que s’il était un industriel, il n’utiliserait pas le logiciel issu de ma thèse. Ce qui m’a fait super mal, d’autant qu’il avait des arguments. Ma première réaction a été le déni, mais j’ai tout de même pris en compte ses remarques, car elles étaient bonnes, et au final, le logiciel était bien meilleur qu’il aurait été. Je ne dis pas qu’il était bon, mais sans lui, je me rends rétrospectivement compte qu’il aurait été vraiment mauvais.
Mais revenons à nos moutons de compte-rendu de session. L’intervenant encourage à aller voir le cas de WebVan, qui était un concurrent d’Amazon et qui avait l’idée de faire dans les produits frais, ce qu’Amazon se lance à peine à faire aujourd’hui, après dix ans d’expérience. Le défaut de WebVan, pour lui, a été de commencer trop gros trop vite. Ils ont voulu couvrir toutes les villes, tous les produits, etc. et se sont noyés.
Attention donc aux “vanity metrics” qui sont faites pour nous dire ce qu’on veut entendre. Il faut sortir au plus vite du “royaume des opinions” et confronter les idées à la réalité de l’adoption, quitte à ce qu’il n’y ait rien derrière. Par exemple, un site web pour vendre un livre qui ne sera écrit que s’il y a des commandes. Ou bien un logiciel qui fonctionne avec une intervention humaine cachée le temps qu’on voit s’il y a de l’intérêt à réellement l’automatiser.
Pour donner une autre définition de la différence :
- prétotype : est-ce que ce sera utilisé comme on le pense ?
- prototype : est-ce qu’on peut le concevoir et le réaliser ?
Conclusion
Comme d’habitude, plein de super bonnes idées à cet Agile Tour Nantes. On repart la tête pleine de choses à tester, de bonnes pratiques à mettre en œuvre, et on discute pendant tout le trajet du retour. Enfin, pas pour Johan cette année, car il n’avait vraiment plus de voix.
