Après un peu plus d’un an d’existence, le Scrum User Group a fêté mardi soir dernier son premier anniversaire au cours d’une grande soirée. Hébergé par le centre de conférence de Microsoft à Issy-les-Moulineaux, plus de 200 personnes, 13 orateurs et 4 tracks en parallèle. C’était une belle soirée riche en échange.

La soirée débute par une courte vidéo pré enregistré de Ken Schwaber souhaitant un bon anniversaire à notre SUG. Merci à lui. Ensuite, Luc Legardeur, président de l’association a fait un bref point sur les actions du SUG : 4 soirées sur Paris en présence de Jeff Sutherland, Ken Schwaber et Scott Ambler et plus d’une dizaine de rencontre sur la France. Pas mal en un an d’existence. Il évoque également la possibilité d’un Scrum Gathering à Paris pour l’automne organisé par la Scrum Alliance.

Luc a également annoncé son souhait d’être remplacé à la présidence de l’association. Des éléctions devraient être organisées dans le courant de l’été.

Mastering Common Product Owner Challenges – Roman Pichler

Roman est consultant indépendant et Scrum Trainer de la Scrum Alliance.

Roman nous a donné une présentation dynamique et interactive très intéressante sur le rôle du Product Owner. Après un rapide rappel théorique sur le PO, il expose les challenges de ce rôle et répertoriant les travers que l’on peut rencontrer. Les slides sont assez simples : pour chacun des archétypes de défauts qu’il présente, le slide ne présente qu’une image représentatif.

• le proxy PO : l’image est simple, c’est le Prince Charles. Même s’il la représente, le Prince Charles, n’est pas la Reine. C’est un proxy qui ne pourra jamais l’égaler, ni faire son travail. Il est important que le Product Owner soit son propre représentant et pas un proxy qui parlera à la place de quelqu’un d’autre.
• le PO sans pouvoir : le Product Owner doit avoir un pouvoir décisionnel sur le produit qu’il développe.
• le PO surchargé : le backlog est un élément important dans lequel on retrouve pratiquement tout ce dont l’équipe a besoin pour le transformer en logciel qui fonctionne. le PO peut très vite être surchargé si il doit s’en occuper seul intégralement. L’équipe doit le soutenir pour l’estimation des stories, leur raffinement, l’écriture des tests d’acceptance. … Cependant, c’est le PO qui reste maitre de son contenu. Ken Schwaber dit que l’équipe devrait consacrer environ 10% de son temps à soutenir le PO.
• le PO passif : l’illustration, c’est Homer Simpson. Besoin de plus d’explication ? :)
• le PO bungee : le bungee, c’est le PO qui débarque dans l’open space, énonce ce qu’il veut et repart sans communiquer plus que ça avec son équipe. Et revient quelque temps plus tard, et recommence. Repart. Reviens. Repart. Reviens…
• le PO à distance : le PO doit rester au contact de l’équipe
• le PO perdu : c’est le PO qui n’a pas une vision claire de son produit, et qui ne la communique pas. La vision, c’est le résumé du projet, l’objectif vers lequel on tend.
• le PO qui croit au père noël : il a un backlog de 12000 stories et c’est ingérable. La taille d’un backlog doit rester raisonnable. Quelques dizaines d’élément tout au plus. Au delà, il va être difficile de le gérer et de créer une vision précise et cohérente.

Il en restait bien d’autres sur sa liste, mais les 45 min de la présentation étaient déjà écoulées. Cela n’empêche que l’idée est passée : le rôle de Product Owner est complexe et il ne faut pas le prendre à la légère. C’est un élément clé dans la réussite d’un projet scrum et il a besoin d’être soutenu par l’équipe dont il est partie intégrante et par son organisation qui doit lui laisser la liberté d’action nécessaire à la réalisation de sa tâche.

À noter que Roman a écrit un livre sur le sujet qui paraitra bientôt : Agile Product Manager With Scrum¹

Comment la PNL peut vous aider dans votre projet Scrum – Bruno Sbille

Personnellement, j’avais de l’apprehension et de la curiosité pour cette session. Pour moi, jusque là, la PNL, c’était un truc de manipulation utilisé par les commerciaux/VRP pour vous vendre n’importe quoi. En même temps, j’avais déjà eu l’occasion de rencontrer Bruno Sbille lors du dernier SigmaT² et qui m’avait fait une très bonne impression. Je me demandais ce qu’il pouvait bien faire avec ce truc.

Alors la PNL, c’est la Programmation Neuro Linguistique, crée dans les années 70 par un spécialiste en linguistique et un informaticien. Et ça va bien au-delà de ce que je pensais. L’idée de ses concepteurs fut d’observer des gens de talents afin d’en modéliser les structures communes. Le prédicat qui se cache la dessous c’est du genre : si tu fais quelque chose qui marche, si je fais exactement la même chose, il n’y a pas de raison que ça ne marche pas. Évidemment, c’est mon résumé en une phrase, c’est surement un petit peu plus complexe que ça :)

Au final, ça donne quelque chose de très intéressant. Le socle de base est une définition en niveau logique qui caractérise un individu :

• Environnement
• Comportement
• Compétences
• Valeur/Croyances
• Identité
• Système (c’est l’organisation, le groupe auquel on appartient)

Dans les applications de cette caractérisation, on va trouver l’identification des problèmes et sur quel plan il faut les résoudre. Régler un problème de compétence en changer l’environnement ne sert strictement à rien. L’inverse non plus, d’ailleurs. Par contre régler un problème de compétence par une formation appropriée risque d’être plus efficace.

Cela permet aussi de mesurer la porté de ce que l’on dit. Les attaques au niveau de l’identité³ sont totalement improductive. Il vaut mieux en chercher la cause dans les niveaux inférieurs⁴. Cela me rappel un peu le langage du Je en opposition au langage du Tu que l’on retrouve souvent pour la reformulation des conflits⁵.

Après cette brève introduction, Bruno nous présente les méta programme. Il s’agit d’ensemble d’attitudes qui se retrouve au niveau valeurs/croyances et que l’on peut facilement repérer.

• Actif / Passif : celui qui s’agite beaucoup.
• Accord / Désaccord
  • le oui, mais…
  • par comportement : être affalé au fond de son siège et dormir en réunion sont des signes…
  • polarité : celui qui s’oppose toujours
  • commentaire : les petites remarques qui tuent…
  • changement de taille de découpage : discussion sur un autre sujet que celui d’intérêt. Parler foot au milieu d’une réunion d’archi par exemple.

La présentation de Bruno est d’autant plus intéressante qu’il montre tous ces points par l’exemple, avec de réelle mise en situation. C’est drôle, agréable et nettement plus efficace qu’un long discours théorique.

Au-delà de cette catégorisation, ces méta programmes, si on y prete attention, permettent de déceler des désaccords. C’est un bon début pour chercher à les résoudre, ou au moins pour les exposer de façon claire. Bruno rappelle que si l’expression du désaccord est utile, elle peut faire perdre beaucoup d’énergie si celui ci est implicaite. L’idéal est donc de les identifier et les gérer au plus tôt.

Et Scrum dans tout ça ? Bon, quiconque à pratiquer un peu en environnement agile sait que la communication est la base de tout. Dans ce cadre, la PNL est alors une boîte à outils qui peut être utile à tous les membres de l’équipe pour favoriser et améliorer la communication.

Il faut cependant faire attention aux possibles dérives. La PNL peut effectivement être utilisé pour orienté les gens dans leur façon d’agir. Pour éviter cela, tout doit être fait en toute transparence avec honnêteté et déontologie.

Cela me fait penser aux Core Protocols dans ce coté formalisation/modélisation des rapports entre les gens, mais en plus humain et moins froid. Merci à Bruno pour m’avoir fait découvrir cette discipline, il va falloir que je m’y intéresse un peu plus.

Au secours, mes équipes veulent être agiles et je n’ai plus ma place – Alex Boutin

C’est l’une des questions que l’on retrouve souvent : quelle est la place des managers dans les équipes agiles ? Alexandre Boutin nous apporte une réponse simple et pleine de bon sens.

L’agilité vient souvent de l’équipe de dév et l’autogestion rend obsolète le rôle de chef de projet. Ça c’est un point qui est clair : le chef de projet n’a pas d’équivalent agile, il est devenu inutile. Par contre, les managers, eux, ont toutes leur place. Mais leur question qu’est ce que je deviens ? et mes objectifs ? sont légitimes.

Le rôle évolue de contrôler et ordonner il devient stimuler et coordonner. Alex revient alors sur les nouveaux paradoxes dans ce rôle qu’introduit l’arrivée de l’agilité dans leur univers. Paradoxal, mais pas insurmontable, leur rôle n’en sera que plus intéressant à mon sens. Il leur faudra trouver un juste équilibre.

L’agilité va aussi les aider :

• le management visuel à coup de post it leur permettra d’un coup d’oeil de tout savoir de l’état du projet de l’équipe.
• les nombreuses métriques et graphiques dont sont friands les agilistes seront aussi de très intéressant indicateur pour la gestion à haut niveau
• la communication importante de l’équipe entre elle : assister à un meeting du matin permet d’en apprendre beaucoup sur la santé de l’équipe et de ses membres. 15 min très synthétiques, qui montrent énormément de choses.
• la démarche structuré les aidera à avoir confiance dans ce qui se passe.

Bien sur, il leur faudra apprendre à utiliser correctement ces nouveaux outils, et rester au contact des équipes.

Au final, une présentation intéressante, où transparait toute l’expérience et la conviction d’Alex Boutin.

Lean et Scrum, des alliés naturels – Damien Thouvenin

Bon, c’est la présentation qui m’intéressait le moins, non qu’il ne soit pas intéressant mais parce que j’avais déjà pas mal réfléchi au sujet suite à ma première rencontre avec Alex Boutin, et après avoir travailleur sur la traduction de Kanban et Scrum. En plus il était tard, et j’avais 700km dans les jambes. Je dois avouer ne pas avoir été le plus attentif du monde, j’espère que Damien ne m’en tiendra pas rigueur :)

Quelques principes clés du Lean :

• la valeur est définie par le point de vue client
• l’importance de la chaîne de valeur pour éliminer le gaspillage
• flux régulier de travail
• tirer le flux
• viser la perfection

Au vue de ces quelques points, on voit vite les points qui relie Lean et Scrum. Il reste cependant des divergences majeure. En terme portée d’abord : le Lean se joue à l’échelle complète de la société, et par ce biais arrive forcement au niveau du projet. Scrum, lui, concerne en tout premier lieux la gestion de projet. Cette gestion entraineront souvent des modifications qui arriveront jusqu’au niveau de l’entreprise. Mais ce n’est pas obligatoires.

Deuxième point de divergence : le design. Le Lean se base sur le profound knowledge, la connaissance profonde des choses auxquels on s’intéresse qui permettront d’établir des standards fixes⁶. Scrum est plus basé sur l’apprentissage et l’amélioration continue : Inspect & Adapt sont les maîtres mots.

Cela dit, les deux se marient très bien. Du Lean on peut facilement intégrer dans Scrum la régulation des flux d’entrée. Les études montrent que ces flux d’entrées sont le moyens de contrôler le débit du flux de travail⁷. Le WIP⁸ est un bon moyen pour cela.

Damien a ensuite parlé d’une forme de backlog différentes de la liste que l’on utilise habituellement : le backlog en map. Je ne suis pas certains d’avoir bien compris de ce dont il s’agissait, mais ça avait l’air intéressant. Il faudra que je creuse.

En bref, la présentation de Damien est agréable, c’est un orateur qui maîtrise son sujet. D’ailleurs, il le maitrise peut être un peu trop et a du mal à ne pas digresser et sortir de son objectif premier ce qui le rend un peu difficile à suivre. Cela dit, cela reste intéressant :)

Le cocktail

Et oui, toute bonne soirée se fini par un coktail. Et là, c’était la grande classe. Rien de tel pour continuer les conversations que des petits fours, du champagne et des jus de fruit⁹. De quoi poursuivre les discussions avec les orateurs, les présents et mes camarades du bureau du SUG.

Merci à tous pour cette excellente et riche soirée.

L’ensemble des présentations devraient rapidement être en ligne sur le site du SUG