#frenchsug

Mary Poppendieck nous emmène vers les communautés auto-organisées et vers Elinor Ostrom qui identifie 8 règles de gouvernance des biens communs :

Définir une limite du groupe claire

Faire coïncider les règles gouvernant l’usage du bien commun avec les besoins et les conditions locales.

S’assurer que ceux qui sont affectés par les règles peuvent participer à la modification de ces règles.

S’assurer que le droit d’édicter des règles des membres de la communauté est respecté des autorités extérieures.

Développer un système, porté par les membres de la communauté, permettant de surveiller le comportement des membres.

Faire usage de sanctions graduées envers les violateurs de ces règles.

Donner accès à des moyens de résolution de problèmes à faible coût.

Une gouvernance à multiples niveaux.

Quelle taille de groupe est la plus pertinente ? C’est au nombre de Dunbar qu'évoque l’oratrice, celui évoqué dans le Tribal Leadership, et ses variantes :

Le cercle d’intimité : 3 à 5 personnes

Le groupe de sympathie : 7 à 10 personnes ; c’est la taille d’un groupe pouvant accomplir « quelque chose ».

Le groupe de chasse : de 30 à 70 personnes ; c’est la taille nécessaire pour construire un sous-système indépendant et indépendemment.

Le clan : de 100 à 150 personnes ; C’est la taille d’une compagnie, dans les organisations militaires.

Complexité

Pour aborder la question de la complexité, Mary Poppendieck nous parle de micro-services, en évoquant le livre de Sam Newman (que je n’ai pas encore lu).

Les micro-services fractionnent les ensembles complexes en petits systèmes indépendants (jusqu’à la base de données) qui ne font qu’une seule chose, mais bien. « small » est bien le mot d’ordre pour les micro-services :

Petit services qui font une seule chose, mais bien. Nous l’avons dit.

Petites équipes, capables de prendre en main un service, depuis la compréhension du besoin avec les équipes métiers, jusqu’au suivi en production, en passant bien évidemment par la construction et le déploiement. qui s’effectue indépendamment des autres briques du SI.

Petites itérations et petit coût de démarrage: de zéro à une première étape en 3 semaines !

L’aptitude à réaliser des microservices a des corolaires.

Pas de couplage avec les autres briques du SI (nous l’avons évoqué).

Automatisation extensive des opérations : tests, intégration, déploiement.

« canary release » qui permet de pré-tester le système en situation réelle.

Continuous delivery et aptitude a être toujours « prêt au déploiement ».

Equipes pluridisciplinaires.

Etat d'esprit

Le focus sur le projet a fait son temps ! Place au focus sur le produit !

Vous êtes focalisés sur « le métier » ? Ce n’est même pas un concept … et pendant ce temps on laisse filer le focus sur le client… Il faut changer de regard.

Passer du focus métier au focus client

Passer du gestionnaire de projet à l’entrepreneur leader.

Migrer du développement qui execute les commandes à une équipe proposant des réponses.

Ne plus faire des choix sur les planning, mais sur les marchés.

Abandonner la mentalité « centre de coût » pour un état d’esprit « centre de produit ».

Dans son livre Inspired, Marty Cagan localise la création de grands produits à l’intersection de la valeur, de l’utilisabilité et de la faisabilité ! Pour donner vie à cette vision, il faut 3 personnes d’agal statut, l’un d’entre-eux est le « product manager », qui n’est pas un Product Owner : son rôle n’est pas d’écrire des User Stories ou de concevoir la solution, mais d’être un canal direct avec le client.

Focus

C’est se focaliser sur les bonnes questions. Et comme l’a popularisé Simon Sinek, cela commence par « pourquoi ? ».

Le modèle Cynefin

C’est ce pourquoi Dave Snowden est connu. Il était normal que son auteur nous l’évoque. L’ayant déjà évoqué dans ce blog, je n’y reviendrais pourtant pas. Le billet de Nicolas Lochet développe très bien ce sujet également (de manière plus approfondie que moi pour être franc).

Mais le modèle Cynefin n’est pas statique mais dynamique. C’est pour décrire les transitions entre les états qu’il a été créé. Scrum transite ainsi entre « complexe » et « compliqué », il maintient même une cadence entre ces deux états. A la longue, il peut même revenir vers « évident » !

Simple or simplistic

Répéter les recettes est attrayant. Mais Snowden nous met en garde contre celles-ci. Et en particulier sur 3 effets :

Le « novelty effect » : Ce n’est pas parce qu’une approche est populaire qu’elle est bonne. Ce disant, Snowden vise SAFe sans aucun détour.

Le « cobra effect » : Il faut se méfier des solutions simples. Vous pensez à récompenser la correction de bugs ? Méditez sur cette histoire : Le gouvernement Britanique voulait réduire le nombre de Cobras pullulant certaines régions et a donc proposé des primes pour la capture des cobras. En retour, les paysans ont commencé a élever les cobras pour pouvoir toucher les primes...

Le « butterfly effect » : Ce n’est pas parce que quelque chose a marché une fois qu’elle continuera a marcher plus tard...

L’ethnographie scalable

Bien sûr, la scalabilité, c’était le thème de ce ScrumDay. L’ethnographie scalable, c’est le modèle que nous propose Dave Snowden. Hélas, je n’ai pas compris grand chose au propos, le point d’orgue étant le « human metadata ». C’est un peu trop pour moi. Je vous livre toutefois une pensée que j’aime bien :

Scale, not by aggregation, but by redistribution.

C’est une autre façon de dire que l’agile à l’échelle tant à la mode aujourd’hui doit se faire, non pas en « scalant », mais en « dé-scalant ».

Pour lui, nous sommes à l'âge de l'obscurantisme du management, où les croyances prédominent sur les faits. Où une plus grande attention aux recherches académiques devrait être portée, alors que 50 ans de recherche en management sont simplement ignorées. Alors, laissons tomber les opinions personnelles.

Le "Scrum fake" : à la recherche des causes racines (1ère partie)

Le constat premier de Craig Larman rejoint le mien : il y a de plus en plus de "Scrum Fake" dans les mises en place de Scrum aujourd'hui. Le co-auteur de LESS y voir 2 causes racines. Des causes racines qu'il faut activement adresser, car si notre transition agile ne les adressent pas, celle-ci pourrait faire plus de mal (la déstabilisation liée au changement) que de bien (la mise en place d'un véritable environnement agile).

Cette première cause racine a un nom : le "contract game". C'est à dire le jeu autour du contrat auquel se livrent les équipes de développement d'une part et le client (au sens client interne) d'autre part. Oui, on parle bien d'un contrat "virtuel" interne et non d'un contrat légal avec un client externe. Pourtant le fond reste le même.

La première partie du projet, celle où se joue l'établissement de ce contrat, est le théâtre d'un duel où le business demande "plus, plus, plus" et où l'équipe de développement réponds "moins, moins, moins". Il y a ce combat, car chacun sait qu'au moment où celui-ci sera ficelé, le jeu changera :

Le business n'a plus la main, elle passe au développement qui devient seul maitre.

Le business lui-même ne veut pas être inclus dans le jeu du développement.

Ce contrat est basé sur l'illusion de la faible variabilité. Une illusion dont on sait qu'elle est fausse depuis de nombreuses décennies.

On dit d'un d'un contrat qu'il est aboutit quand les deux parties sont mécontentes de manière équilibrée. Au fait, quel est son rôle au contrat ? Ce n'est pas de permettre la réussite du projet mais de permettre de blâmer l'autre partie en cas d'échec !

Donc on s'engage dans une longue phase de réalisation où le chef de projet fait le lien avec le business. Craig nous parle des outils du PMI (qu'il appelle le Project Magic Intitute) concernant la relation entre le chef de projet et le client :

Comment le chef de projet assure le client de la réussite : en déclarant « je m’engage ! » ; une approche dont on sait depuis longtemps qu’elle ne marche pas !

Comme dans toute magie, on utilise des symboles ésotériques : ici, on les appellent « diagrammes de Gantt » … en fait une illusion de contrôle !

Enfin les managers pilotant ces projets à plusieurs niveaux hiérarchiques de distance transmettent des rapports d’avancements faussement optimistes au grée des remontées d’information entre niveaux hiérarchiques ! Un phénomène appelé « greenshifting ».

Tout cela se paie à la fin du projet : les blâmes sont rejetés entre les acteurs du projet, le périmètre est bâclé en toute urgence pour se débarrasser du projet en sacrifiant la moindre parcelle de qualité. Enfin, le tout se conclut en « dette managériale » : les bons managers et les bons développeurs quittent la structure !

Larman explicite ces fonctionnements par ce qu’il appelle en toute modestie les « lois de Larman » !

1 - Les organisations sont sont implicitement optimisées pour maintenir le statut quo du pouvoir des managers de proximité et des spécialistes

2 - Corollaire de la première loi, toute initiative de changement sera réduite à des changements d’appellation maintenant ce statut quo.

3 - Second corollaire de la première loi, les initiatives de changement seront tournées en dérision, puis qualifiées de « puristes », « théoriques » ou « révolutionnaires », puis « nécessitant des adaptations pragmatiques pour customiser pour l’organisation », menant au statut quo managers / spécialistes.

4 - La culture se calque sur la structure : les plans de carrière favorisent la spécialisation. Changer la culture en tant que tel n’est pas possible.

La seconde cause : le découpage par fonction

Le découpage « orienté composants » présente de graves lacunes :

Du « code privé » : au contraire d’augmenter la qualité, ces groupes créent une complexité artificielle qu’ils ne sont plus capables de voir au bout d’un certain temps !

Les fonctionnalités à délivrer traversent les composants. Mais comme elles deviennent subordonnées aux planning locaux, elles mettent très longtemps à être livrées. Donc un cycle de feedback qui va de même.

Les fonctionnalités étant l’assemblage de fonctionnalités implémentées dans les divers composants, les tests de bout en bout ne peuvent avoir lieu qu’une fois l’ensemble complété. Notre cycle de développement est en fait séquentiel à ce stade. Il subit le syndrome du « hands of » typique du cycle en cascade.

Ce « hands of » n’est pas seulement en aval, il est aussi effectif en amont: chaque fonctionnalité demandée doit être ventilée en éléments de réalisation, il est donc nécessaire d’avoir des analystes effectuant ce découpage au préalable du développement !

Le staffing étant effectué par composant, l’occupation générée par ls demandes n’est pas nécessairement en ligne avec cette disposition de ressources. La priorisation des fonctionnalités finit donc par être dirigée par l’occupation des équipes, plutôt que par les priorités métier !

Hélas, le « découpage par composants » a des airs bien trop familiers pour moi. La démonstration de Craig est plutôt édifiante !

Mais alors...

Et LESS, dans tout ça ?

Le point de départ de la reflexion de LESS vient de l’expérience de RUP (j’y ai participé chez Valtech, à la fin des années 90). Les deux grands défauts de RUP, que je partage avec l’orateur, étaient :

Un niveau de détail bien trop grand. Personnellement, je traduis celà comme une rémanence d'une vision Tayloriste du travail .

Un manque de contextualisation.

Le framework LESS est guidé par plusieurs principes :

Celui des organisations apprenantes, en s’inspirant du Shu Ha Ri. Ainsi plutôt que le ras-de-marée de détails, LESS propose des principes et juste « un peu moins que nécessaire » d’éléments de processus. Il se revendique en cela dans la lignée de Scrum.

Une organisation en « feature teams » plutôt qu’en composants. Comme c’est le cas chez Spotify.

Une « serious change initiative » destinée à bouleverser l’organisation et les titres de postes ! LESS se revendique d’inspiration Lean ici : La préservation des emplois ne signifie pas la préservation des rôles !

Pour démarrer tout cela, Larman débute une réorganisation LESS avec 2 points de rencontre très importants :

L’informed consent meeting. C’est un meeting de 2 à 3 jours avec Craig, avec tous les exécutifs ! S’ils ne peuvent y consacrer ce temps, c’est qu’ils ne sont pas sérieux sur leur volonté de changement ! D’après l’orateur, la plupart des organisation n’en valent pas le coup ! Hum...

Une fois le changement décidé, il y a le « flip », qui dure 2 heures. C’est le Design Team Meeting. Il s’agit d’une grande place de marché où les équipes s’auto-forment en s’appuyant sur une « check list ». Cela nécessite parfois plusieurs tours. Une fois cela fait, les équipes embauchent… leur Scrum Master ! Puis… leurs managers !

Il y a de nombreux éléments spécifiques à LESS, comme la façon de gérer les planning meetings, les démos et les sprints synchronisés. Par ailleurs, pour donner de la cohérence à l’ensemble des travaux menés par des features teams indépendantes, il faut des communautés de pratiques: certaines sont requises, d’autres informelles.

En conclusion

Tout d’abord, Craig Larman est un orateur hors pair. Non seulement sa diction est claire, mais son jeu de scène est vivant, son propos est intéressant et souvent pertinent. L’approche de changement des organisations de Larman me semble par ailleurs brutale : le RAZ sans tenir compte de l’existant ou du contexte, avec le dogme que l'organisation LESS est de toute façon la bonne. Pour Olaf Levitz, cela démontre un manque de respect. Je le rejoins sur ce point.

Les pré-requis au passage à LESS sont très importants car Craig Larman n’accepte aucun compromis. De fait peu d’entreprises acceptent un tel changement, mais doit-on dire de fait que les autres ne « valent pas le coup » ? Je ne suis pas non plus l’auteur sur ce point.

LESS est résolument d’inspiration Scrum par sa légèreté. Au contraire de SAFe que je trouve sujet à caution, la fibre agile de ce process me semble réelle. Mais je reste dubitatif sur le concept même et sur la motivation du scaling, quel que soit la dose d’intelligence qui y est mise (ce qui est bien le cas ici). L’idée de « scaler » me semble une réminiscence d’un ancien mode de pensée qui vient infecter le nouveau. Je pense que l’enseignement de l’agilité est différent...

Vous pourrez retrouver quelques éléments de la prose de Craig dans l’interview suivant. Un livre sur le sujet est à venir cette année, mais on trouve déjà une majorité du matériel dans les deux livres co-écrits avec Bas Vodde, dont celui-ci.

La transformation numérique de France Télévision

France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.

Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.

Le Lean Startup au service du Product Owner, par Jérôme Guenver

J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !

Des outils du monde de la psychologie… par Bruno Sbille

On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !

Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !

Let’s Sketch together, par Alvin Berthelot

L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…

The big payoff, par Alexandre Boutin

J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.

Faites Revivre vos spécifications

Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).

Open Agile Adoption, par Pablo Pernot et Oana Juncu

Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…

Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.

Créer le bon produit avec le Lean Canvas, par Romain Couturier

Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .

Les nouveaux outils du Product Owner

Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.

Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud

Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !

Introduction to Visual Management, par Natalie Yadrentseva

Je ne suis pas certain de joindre ici le bon support, je l’avoue…

Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013...

Devops Game, par Vincent Daviet

Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.

Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot

A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier

Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard

Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l'association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.

Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.

Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.

Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen

Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?

My Product is a James Bond Movie - part V, par Pierre Neis

Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !

Développer en mode Kick-Ass, par Samuel Le Berrigaud

Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !

De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre

La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !

Le prétotyping, avec Elalami Lafkih

Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…

Kapla Challenge, avec Dragos Dreptate

Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier

Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais

Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !

DSL et refactoring pour les tests d’acceptation, par Laurent Py

Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !

Bon, voici quand même cette présentation…

Les reportages du ScrumDay

Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.

Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn

Ils en parlent aussi…

Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.

Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.

Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.

Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager

Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.

Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !

Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…

"Happy people build better products … and better products makes people happier !". Telle est l'introduction qu'Henrik Kniberg nous assène. Mais quand une compagnie grandit, sa capacité à conserver des employés heureux diminue.

Une fois de plus, c'est de Spotify dont nous parle Kniber avec les clés suivantes:

Pour persister : l'agilité doit devenir une culture plutôt qu'un process.

Au fur et à mesure que la maturité d'une organisation grandit, la vision "shu" de Scrum devient un obstacle. Il faut abandonner certaines pratiques pour passer aux niveaux Ha et Ri.

Les Scrum Teams deviennent des "squads" ; l'autonomie qu'on leur accorde est une clé importante.

Attention à ce que l'autonomie ne devienne pas de l'autarcie : la communication entre squads doit être cultivée.

L'autonomie ne signifie pas discordance : l'alignement avec un leadership fort est possible !

L'autonomie a des impacts sur le découpage architectural du produit.

Passer d'une culture de la crainte de l'échec (Netflix) à une culture de l'apprentissage au travers de l'échec.

Le contrôle favorise la stabilité, mais empêche l'innovation.

Le contrôle se focalise sur la vélocité alors que ce sont les mesures de la valeur et de l'impact qui importent.