Il y a officiellement 2 organismes de certification SCRUM :

Scrum-Alliance qui propose une certification valable 2 ans et qui - selon les rumeurs - s'obtient assez facilement à la fin d'une formation de deux jours. Scrum.org qui permet de passer sa certification en remplissant un QCM en anglais de 80 questions. Il faut ensuite avoir 85% de bonnes réponses pour valider la certification. Cette certification est valide à vie.

Il est à noter que les certifications scrum-alliance sce font avec un "scrum-trainer" homologué là où les certifications "scrum.org" peuvent se faire en candidat libre.

(A noter que SAFe propose aussi des formations certifiantes PO mais qui ne sont pas reconnues par SCRUM…)

La certification SCRUM.org permet de se (re)poser clairement les fondamentaux d'une équipe agile qui fonctionne bien : le nombre de personnes présentes dans l'équipe, les différentes responsabilités proposées aux Dev, PO et SM, le côté "équipe autogérée"… Bref, ces certifications nous obligent à penser à l'agilité au "vrais sens" du terme.

Je parle de "vrai sens" en opposition à l'agilité que l'on retrouve dans beaucoup de grands groupes où l'agilité est réduite à une somme de méthodes appliquées sans conviction, où la hiérarchie, la planification, la contractualisation et la bureaucratie prennent toute la place.

Dans la certification SCRUM, les inspirations Agile, Lean et surtout eXtreme Programming sont très fortes et très présentes. Le Scrum Guide transpire l'agilité qu'on aimerait voir appliquer plus souvent.

Mieux, les questions de la certification appuient là où cela fait mal. Lorsqu'il pose la question "Est-ce que le PO doit être présent lors du daily ?", La réponse est non parce que c'est un événement réservé aux développeurs.

Est-ce qu'on voit, sur le terrain, des daily sans PO ? Ça ne m'est jamais arrivé en 8 ans de travail dans l'agilité !

Est-ce que c'est intéressant ? Oui : pédagogiquement cela nous force à nous rappeler que l'équipe de développeurs doit être autonome dans son organisation et donc dans ses points de synchronisation.

Est-ce que ça fait mal ? Oui, parce qu'on a encore du mal à voir des équipes de développement qui soient vraiment auto-organisées.

Après avoir passé la certification Scrum Master et après avoir beaucoup révisé, j'ai tenté de passer une première fois la certification PO. Je l'ai ratée à une question près ! Fou de rage, j'ai re-bossé le soir a fond pour la repasser - et l'obtenir - le lendemain après-midi suivant.

J'avais passé 15 tests à blanc (de longueurs différentes et sur des sites différents) pour passer la certification SM et autant avant de passer ma première certification PO. On est donc sur un total d'une 30 aines de tests. A cela, j'ai noté les questions que j'avais raté pour mieux réviser.

Lire le Scrum Guide ne suffit pas à passer les certifications, Il faut :

• connaître les bases de Nexus (framework à l'échelle - distinct SAFe),
• avoir lut certains article du blog scrum.org,
• connaitre les outils ou pratiques hors-SCRUM (tels que la vélocité, les user story, la dette technique…)
• Et connaitres certaines questions pièges !

Il est à noter que la certification PO demande plus de savoir "externe" que la certification Scrum Master.

Le test blanc officiel de Scrum.org est assez simple mais ".dangereux/" : on obtient vite le score de 85% et on se sent prêt à passer le vrai examen final, mais les véritables tests "PO" et "SM" sont bien plus difficile.

En commençant les tests sur internet, on se rend compte qu'il y a des questions pièges qui ne peuvent se résoudre qu'en bachotant.

A la question : "Quand l'équipe Scrum est autorisée à interagir avec les principales parties prenantes ?"

• A la Sprint Retrospective
• Au Daily Scrum
• Chaque fois qu’il est utile d’avoir l’avis des parties prenantes
• A la Sprint Review"

Le Scrum Guide dit que la "Sprint Review" est LE moment pour interagir avec l'équipe et récupérer du feedback. Mais la bonne réponse est "Chaque fois qu'il est utile d'avoir l'avis des parties prenantes".

Si vous n'êtes pas tombé dans ce piège au moins une fois, il est difficile de tomber juste du premier coup ou par application de la logique pure.

On bascule d'un passage qui va d'une compréhension de SCRUM à un apprentissage par cœur des questions les plus retorses et alambiquées possibles.

Autres problèmes, sur internet il y a des dizaines de tests. Certains sont gratuits (ex laplschine) mais ne sont pas toujours à jour avec la version 2020 du Scrum Guide. D'autres sites sont payants mais semblent un peu louches (certains ont pleins de publicités douteuses, d'autres mélangent des questions SCRUM avec d'autres examens …).

Enfin, on a des sortes de forums où les gens votent sur les réponses les plus probables aux questions … La légitimité de ces réponses laisse donc à désirer. Dans ces cas-là, à quoi sert de réviser si on n'est jamais sûr de la bonne réponse ?

Une question se pose : SCRUM étant une marque déposée et les questions des certifications étant sûrement couvertes par un brevet X ou Y, comment se fait-il qu'elles se retrouvent sur internet ?

Avant de commencer le test, il est légitime de savoir ce que serait ou ne serait pas de la triche. Par exemple, est-ce que s'entraîner sur des examens blancs officiels est de la triche ?

Personnellement j'ai réalisé une "cheat-sheet" avec tous les points importants que j'avais notés pendant mes révisions et que j'ai imprimé le jour de l'examen.

Autre point, pendant l'examen, un script interdit de sélectionner les questions ce qui empêche les copier / coller dans google. Sans être expert informatique, une extension sur son navigateur permet de passer outre… Et on comprend ensuite pourquoi ces questions se retrouvent telles quelles sur des sites de tests en ligne !

En vérité, le timing est très serré pour faire 80 questions en 1 heure. Il faut lire, comprendre et répondre à chacune de ces questions en moins d'une minute. N'espérez pas obtenir votre certification en tentant de trouver les réponses en trifouillant des réponses issues de forums obscurs grâce à votre moteur de recherche.

La triche n'est donc pas impossible mais reste limitée voir quasi-impossible pour quelqu'un qui n'a pas bossé sérieusement sa certification.

La certification SCRUM.org est intéressante dans le sens où elle pose des questions pertinentes sur nos organisations et notre manière d'appliquer l'agilité. Elle ancre certains réflexes nécessaires à un Product Owner ou à un Scrum Master. Elle sait appuyer là où nos organisations pourraient faire mieux.

On peut donc dire que la certification PO / SM implique de vraies connaissances de l'agilité. Des connaissances qui sont éloignées de ce que l'on trouve dans la plupart des grandes boîtes qui se revendiquent " agiles ".

En revanche, la certification devient lourde et inutilement complexe quand on se rend compte de la part nécessaire d´apprentissage par-coeur . Avoir ces certifications demande une capacité certaine de bachotage. Mais est-ce utile pour un PO ou un SM lorsqu'il est sur le terrain ? Les QCM en ligne ne permettront jamais de gagner des compétences en intelligence émotionnelle, en coaching ou en management. Ils ne permettront pas non plus de développer une réflexion sur un contexte précis ou elle ne permettent pas une meilleure analyse des organisations.

Pour moi, le rapport investissement-valeur ne semble pas très positif Au final, j'en conclus que le temps investi dans ces certifications n'est pas rentable par rapport au niveau de connaissances obtenues.

Pour ce qui est du côté "nouveau badge sur le C.V.", il me semble que passer une certification que l'on dit plus simple (comme celle de SCRUM-Alliance ou celle de SAFe) aurait été plus profitable : moins de temps perdu, pour une valorisation égale sur le marché. Le scrum-guide de 15 pages suffit à la connaissance de SCRUM.

Malheureusement connaître SCRUM, n'est pas savoir faire scrum. Une certification ne garantit pas que le candidat sera bon ou meilleur qu'un autre sur le terrain. Personnellement, j'en arrive à la conclusion qu'entre 2 candidats de même expérience, l'argument "certifié" ne fonctionnera pas pour moi.

Au final, les meilleures formations AGILE que j'ai faites et que je conseilles sont des formations non-certifiantes que l'on donne dans mon entreprise, ou les formations axées "Soft skills " et développement personnel. (Formation prise de parole en publique, formation présentation, formation intelligence émotionnelle, formation communication non-violente…)

Il me semble que la capacité de communication, le style de management, la réflexion autour des organisations, la capacité à convaincre, les convictions sont des atouts bien plus indispensables aux PO et SM.

• Les planètes sont, dans l'ensemble, vides et ne donnent pas du tout envie de rester
• Une fois dépassé les avants-postes on se retrouve sur du grand rien avec quelques animaux moches qu'on peut tuer
• On va avoir quelques ressources à scanner pour une sorte de pokedex interne mais c'est tout
• Les 2 premières villes que j'ai vue sont vraiment nuls: Déjà ça laggue, c'est trop grand, trop horizontale, trop attendu ou trop caricaturale.
• Et puis c'est vide. On se retrouve dans un magasin hyper grand, il n'y a qu'un seul PNJ qui n'a pas de dialogue. Ça semble totalement mort et faux.
• Je pense notamment à la ville cowboy qui fait vraiment tache par rapport au reste de l'univers. Pourquoi des cowboys dans l'espace alors que tout le reste est futuriste ? Ça ne colle pas.
• Et puis c'est long, les temps de chargement après chaque porte ouverte, ça n'est plus possible en 2023.
• Quand on compare avec un NightCity et sa ville qui vit a fond et sans temps de chargement, on joue clairement pas dans la même court.
• De manière générale, la DA est un échec : on tente une vision futuriste proche mais du coup, c'est laid comme une zone industrielle au bord nogent-sur-marne.

• Les dialogues sont plutôt con-con et prévisible.
• Le coter "Point de charisme" fait quelques trucs marrant, mais on est à des années-lumières de ce qui se passe sur un BG3.

• Les personnages sont pas intéressants et pas attachant parce que ultra caricaturaux. La working girl bourrine, le bad-boy cowboy, l'homme d'affaires cupide…

  • A coté de cela, on a quand même sortie Baldur's Gate 3 et Cyberpunk 2077 avec de vrais personnages, complexe qui ont de vrais personnalités.
• Le pitch est super mauvais : "On est le club des scientifiques qui veulent connaître le monde ! Mais dans le groupe y a plein de gens qui ont l'air d'en avoir rien à faire de la science."
• Bref, l'intrigue de base est nul

• Toutes les interfaces sont chiante. Bethesda ne s'est toujours pas améliorée là-dessus depuis Skyrim
• Les bastons dans l'espace sont mal branlés, notamment l'assignement de l'énergie dans ton vaisseau entre les missiles et les boucliers
• L'amélioration de ton vaisseau spatiale est incompréhensible. J'ai très vite abandonné l'idée de le customiser
• J'ai amélioré plein de trucs dans le centre de recherche. Je n'ai jamais compris à quoi servait ces améliorations ! 🙃

• Le sac est toujours trop petit
• Le lock picking est complexe
• Le jeu lag pourtant je joue sur un Shadow PC boosté
• Sur steamdeck le jeu est d'une laideur sans nom
• Sur mon linux classique avec une GTX 1060, ça tourne pas. C'est con mais Cyberpunk 2077, lui tourne de manière acceptable

Mais j'ai du mal à le croire, de toute façon, je n'ai plus envie d'y jouer.

Pour 70 euros, on a de la quête (fedexe) en masse et c'est son point positif. La durée de vie semble extrêmement longue. Au final, on parle d'un remix de Skyrim - l'ambiance épique en moins - dans l'espace.

Si il était sorti en 2011 comme son grand frère, ce jeu aurait mérité un bon 8/10 .

Mais en 2023, après Baldur's Gate 3, après No Man's Sky, après Cyberpunk2077… Honnêtement y a rien qui va pour un AAA avec des millions de budgets. Je ne comprends pas comment et pourquoi la presse vidéo-ludique lui met des notes aussi haut.

Ma note finale : 4/10

PS : Je finis cet article ayant lancé Cyber Punk 2077 : Phantom Liberty. J'ai pris plus de plaisir en 3 heures à Night City que 15h dans les étoiles de Starfield…

On parle ici de type d'interraction entre les équipes.

• Team Topologie est très théorique, il n'y a rien de concret ni guide "pret à l'emploi"
• Par aillieurs Team Topologies se veut un programme très viuel. On peut télécharger sur des modèles pour mieux visualiser ses organisations

A et B divergent, ils ont des intérêts ou des agendas opposés :

On observe que A et B ont des intérêts personnels qui divergent.

On nomme cette divergence d'intérêt un conflit.

Le conflit pousse à des actions qui peuvent être pensées.

Voici une liste de stratégies possibles :

Exemple:

Jean veut installer une base de donnée MySql sur le serveur et Jacques veut installer une base PostGreSQL.

On joue la montre, on retarde les décisions, on remet des décisions à plus tard, on met sous le tapis, on attend une décision d'ailleurs…

Exemple:

Jean reporte 2 fois la réunion sur le choix de la base de donnée et Jacques ne vient pas à la 3e réunion. Lors d'une 4e réunion, ils s'accordent pour dire qu'ils n'ont pas assez d'information pour faire un choix et vont attendre le retour de vacance de Bill l'architecte pour replanifier une réunion.

C'est une stratégie similaire à la stratégie de la fuite, mais orientée vers un nouvel acteur. On oublie ou l'on fuit ses intérêts personnelle pour se concentrer sur un sujet externe.

Exemple: Jean et Jacques accuse Bill, l'architecte en chef, de ne pas avoir préciser quel devait être le type de base de donnée dans son dossier d'architecture.

On force quelqu'un a faire Quelque chose qu'il ne veut pas. (Coup de pression, engueulade, ruses politiques…)

Dans ce cas-là, A et B ne sont plus au même niveau.

L'un prend le pouvoir sur l'autre.

Ou

Exemple:

Jean annonce à Jacques que si MySQL n'est pas installé, il ne lui fournira pas l'API dont il à besoin pour son projet et qu'il le fera chier en commission sur son projet. Jacques joue sa carrière sur son projet bidule. Il cède et installe MySQL.

Ici A & B vont chercher une décision chez un supérieur hiearchique (N+1).

Dans cette stratégie, les N+1 de A et de B s'accordent pour faire appliquer une décision sur A et B.

Il peut arriver que N+1 de A et N+1 de B soient eux aussi en désaccord.

Exemple:

Jean va voir son bosse, Bill l'architecte générale, qui est aussi le N+1 de Jacques et lui demande de trancher entre MySQL et PostGreSQL.

C'est une variante de l'escalde.

A et B vont chercher une authoritée, une expertise en dehors de leur cercle pour prendre une décision.

Dans cette stratégie, A et de B s'accordent pour donner le pouvoir de décision à une personne c.

Exemple:

Jean et Jaques vont voir Fred l'expert en base de donnée de la boite. Fred est reconnue par tous sur son expertise.

Prendre une décision qui irait à l'encontre de l'avis de Fred décridibiliserait la position de A ou de B.

A et B trouvent des intérêts communs qui sont supérieurs aux intérêts individuels.

Ils réussissent à prendre une décision.

Exemple:

Jean arrête de négocier et accepte d'installer PostGreSQL parce qu'il faut prendre une décision rapidement pour terminer le projet.

A et B échangent diverses valeurs qui rendent possible une décision.

Exemple:

Jean proposes à Jacques d'installer MySQL en échange de quoi, il lui promet d'installer PostGreSQL sur le prochain projet qui devra être lancé l'année prochaine. Jacques est d'accord avec cette proposition.

Sans vouloir résoudre ces conflits, connaître ces stratégies permet de mieux les anticiper et, potentiellement, de les éviter.

La valeur d'échange est quantifiable, c'est le prix d'un produit. C'est ce que l'on paye pour acheter ou pour vendre un produit. Dans un marché, la valeur d'échange, évolue en fonction de l'offre et de la demande.

* Pour être précis, l'économiste barbu estime que la valeur d'échange est déterminée par le temps de travail nécessaire pour produire un produit.

La valeur d'usage est le prix qu'estime le consommateur lorsqu'il "utilise" ce produit. C'est une notion qui n'existe que dans la tête du consommateur et qui n'existe qu'à un seul véritable moment : lorsqu'il utilise réellement ce produit. Par exemple, on connaît la vraie valeur d'un vin qu'on a acheté uniquement lorsqu'on le boit ! La valeur d'usage est donc une valeur subjective, floue et pas vraiment quantifiable mais qui existe tout de même !

On comprend aussi vite que ces 2 types de valeurs sont liées : les gens achètent des produits avec une valeur marchande qui devrait correspondre à une certaine valeur d'usage. Si le produit déçoit (faible valeur d'usage), alors sa valeur marchande risque de baisser. Et inversement !

Dans le logiciel, c'est pareil !

On passe notre temps à produire des logiciels qui devraient, à la fois être utile et plaisant à un client final tout en étant rentable pour celui qui le produit.

Quand on regarde certains postes de travail que l'on voit dans nos entreprises, on se rend compte qu'ils sont souvent dédiés à une des deux valeurs, prenons le temps de le regarder :

Bien évidemment, nous simplifions la définition des rôles pour la clarté de l'article.

Je vais être honnête, je n'ai encore jamais utilisé ces concepts dans mes missions.

Mais j'imagine facilement utiliser ces concepts dans un atelier "/ rôles et responsabilités/" . Cela permetterait aux équipiers de mieux comprendre ce qu'elles attendent des uns et des autres.

Une autre idée, c'est de poser la question dans un mood meter de rétro : Durant ce sprint, vous avez eu l'impression de travailler pour de la valeur d'usage ou pour de la valeur d'échange ? Je suis certains que les résultats seraient hyper intéressant

Bref, je vais tester cela et je vous re-dirais ici ce que cela a donné !

Bon, on est sur un livre-cahier, avec des pages et où l'on vous invite à écrire des choses… Et en meme temps on vous raconte 3 histoires… Et en même temps, il y a 2 narrateurs qui vous parle directement. Puis au milieu, il y a 2 pages de trucs et astuces à faire et ne pas faire quand vous transformez une orga.

Clairement, la forme est surprenante, pour ne pas dire bordélique. Mais il faut l'avouer, cela à un certain charme.

Hé bien c'est tout le problème, c'est un livre qui est censer vous aider à transformer la culture des organisations, mais qui s'evertue a vous dire qu'il n'y a pas d'outils ou de méthodes pour le faire !

A travers les petites histoires, on vous invite à prendre du temps pour conscience du contexte. On vous invite à avoir une vision organique plus que mécaniste. On sent qu'il y a une envie d'avoir une approche systémique à la palo-alto, mais on ne rentre jamais vraiment dedant. On explique pas comment utiliser cet aproche.

Bon, je suis très dure sur ce petit livre qui m'a quand même marqué. Si on devait résumer, on pourrait dire que c'est un livre à la gloire du coaching en posture basse.

J'ai découvert en le lisant que l'humilité peut être une méthode de travail ! Et ca c'est très fort.

Au final, je suis en phase avec la philosophie de Culture Hacking. Il n'y a pas de méthode de coaching ni de transformation d'organisation universel. Dans mon contexte, ma psychologie, ce que propose le bouquain ne m'interesse pas.

Ma formation d'ingégnieur me pousse à penser en termes de "problème -> solution". Ca tape à côté pour moi.

Sans doute, il plaira à d'autres.

Page 67/68 :

• [...] Et j'ajoute un élément important : nos choix et décisions sont liés au contexte. Chacun d'entre nous possède un niveau d'influance spécifique lié à son statut, à ses compétences à son expérience, à ses relations... Nous pouvons agir dans la limite de cette zone d'influance: nous avons le pouvoir de prendre certaines décisions seuls; pour d'autres, nous avons besoin de négocier; enfin lorsque nous n'avons aucune influence, ce n'est qu'en l'admettant et en lâchant prise que nous trouvons de la sérénité.
• Tu distingues 3 zones donc ?
• Oui, zone de pouvoir, zone d'influance, zone d'acceptation
• Ca me rappelles un proverbe... une citation... "Que la force me soit donnée de supporter ce qui ne peut être changé; le courrage de changer ce qui peut l'être; la sagesse de distinguer l'un de l'autre"...

Alors, c'est l'histoire de Maxine qui pour des raions de merde se retrouve affecté dans un service informatique horrible. Elle essaye de faire un build du projet et là, elle part dans un tourbillon de tiquets attribué à 1000 services absurdes… Je ne vous spoile pas, mais elle va s'entourner de personnes et réussir à changer la boite pour que tout s'arrange.

Hmm, je dirais que ca parle plus de culture d'OPS que d'agile. En vrais, ca parles un peu de code aussi. (Nottament de Clojure…) En vrais, ca parle surtout d'organisation, de gens. Pour moi qui suis consultant en organisation, je m'y retrouve a 100%. J'ai l'impression que cela parle clairement de mon travail. Bref, tout ca me plait beaucoup.

Alors clairement, tu sens que le mec à déjà été coach en transformation. Il décrit parfaitement la vie d'une boite qui galère avec son informatique et ses process improbable. Un bémole, je trouve que la rolution du bouquain est un peu facile… Mais bon, je pardonne.

Un peu comme un manifeste agile, Gene Kim propose 5 idéales idéaux pour une boite qui bosse dans l'informatique :

• Le premier idéal: localité et simplicité
• Le Deuxième idéal: concentration, flow et joie
• Le Troisième idéal: amélioration du travail quotidien
• Le Quatrième idéal: sécurité psychologique
• Le Cinquième idéal: approche centrée sur le client

C'est très juste et très bien amenené.

C'est excellent, lisez-le !

• Quoi ? : Un retour sur la construction d'une bonne boite
• Pour qui ? : Les gens qui veulent transformer leur boite, les gros managers, ceux qui s'intéressent à la cultre des entreprises
• Par qui ? : Ludovic Cinquin , ancien bosse de OCTO
• Facilité de lecure : 8/10 (1 est très complexe, 10 est très simple)
• Note globale : 9/10

Le livre se lit très vite, tout en étant très complet :

• La moitié du livre Parle de OCTO (Son fonctionnement et sa culture)
• 1/4 du livre parle des échecs d'OCTO
• 1/4 du livre parle des doutes de Ludo vis-à-vis du management et de la culture
• Et il n'y a as de conclusion !

Tout y est abordé : Les questions d'augmentation, de transparence, de partage de l'information etc… Tout y est abordé et nottament les choses qui peuvent parraitre annecdotique comme les locaux de l'entreprise ou la manière de gérer des réunions.

C'est à la fois un retour d'experience de la vie de ce dirigent et une théorisation faites autour des nombreux bouquains qu'il à lut. J'ai personellement aimé le passage sur la gestion des personnes toxique, et la lourde responsabilité du chef de devoir les virer.

C'est la 1er intelligence Ludovic Cinquin: il sait que tout est culture et que cela s'ancre dans les petites choses.

Le 2e, c'est son humilité. C'est un des rares dirigent que j'ai vu dire "j'ai raté ca", "on est pas bon là-dedans", "je sais pas". En fait, ces doutes permanant et affiché permettent et l'empathie et la reflexions. Je trouve ca à la fois simple et fort.

Bon, il y a quand y a quand même 3 manques dans son bouquain pour expliquer la fameuse culture-octo :

A part ces 2 points, j'ai beau chercher les décalages entre ce qui est ecrit et la réalité… je n'ai pas trouvé. OCTO est une belle boite, bien pensée. Ludovic Cinquin peut être fiere de ce qu'il a laissé. C'est clairement un très bon bouquain que je conseillerais à tout le monde, nottament aux nouveaux octo ou ceux qui voudraient rejoindre la boite.

• Le fait qu'il marche nickel dans le terminal (Suis passé a à st par aillieurs)
• Sa simplicité d'installation (juste un git clone et ca marche, un bonheur par rapport a doom emacs)
• Son coté "juste ce qu'il faut"
• Les bindings emacs vanilla et intelligent

• L'autoparens qui est activé par défaut. (Mais ca c'est une plaie qu'on trouve sur tout les IDE actuel)
• LGG C-[arrow] qui switch de buffer au lieu de passer de mot en mot (du coup, faut apprandre à utiliser M-f et M-b)

Pour ceux que ca intéresse, y a une liste de starterkit d'emacs dispo ici :