ScrumDay 2015 : Reinventing organizations, avec M. Sahota et O. Lewitz

Cette session, co-animée par Olaf Lewitz et Michael Sahota se voulait un workshop. Moins workshop que je ne m’y attendais toutefois, cat on était plutôt dans le 80% « lecture » et le 20% « workshop »… dans le meilleurs des cas !

Qu’importe, il me tardait de participer à une session menée par deux personnes qui je suis par leurs publications depuis quelque temps. Ici toutefois, la session ne s’articulait pas autour des écrits de l’un des deux conférenciers, mais autour du texte de Frédéric Laloux : Reinventing Organizations.

image

La culture, la clé du changement

C’est l’élément le plus important des organisations, et pourtant le moins visible. De fait, c’est aussi le plus gros frein à l’adoption de l’agilité. La culture de l’organisation est à la croisée des chemins de la structure et des hommes (et des femmes).

Les tentative de changement localisées à la structure ne sont promises qu’à des succès limités. Il faut agir de manière concomitante sur la structure et auprès des personnes. C’est ainsi que se définit la « culture organisationnelle » selon Michael Sahota : Structure + Personnes.

Si l’on souhaite changer le comportement des personnes, la structure doit évoluer en conséquence pour permettre ces changements (sinon, ils seront étouffés). A l’inverse, si on crée une structure moins contrainte sans que les vieilles habitudes se modifient, on crée un vide, sonc une instabilité de l’organisation !

Seconde question clé : quelle profondeur de changement envisageons-nous ? C’est en fait un prémisse de la première. En effet, le changement culturel implique de profonde modification. Mais ce n’est pas nécessairement l’impact recherché. Sahota et Lewitz distingue deux autres niveaux :

  • Changements stratégiques : ils nécessitent des modifications organisationnels.
  • Changements tactiques : ils concernent essentiellement la communication, et les processus.

Quelle est la couleur de votre organisation ?

Pour comprendre comment faire évoluer un organisation (ou la réinventer comme le dit Frédéric Laloux), il faut apprendre à la reconnaitre. L’auteur de « reinventing organization » nous propose un modèle à 4 niveaux.

  • Les organisations « ambre » favorisent la stabilité en s’appuyant sur les rôles, l’organisation et les processus.
  • En passant à « orange », c’est l’accomplissement que l’on reconnait. Les propriétés de ces organisations sont liées à l’engagement et la méritocratie.
  • On franchit une frontière en passant au vert, les organisations basées sur les valeurs et le sens, où l’on remet les hommes au sens de la structure
  • Ce n’est plus au seuls hommes, mais au réseau qu’ils forment que le niveau « teal » s’adresse. C’est le « self-management » qui est symptomatique de ce niveau.

La progression au long de ces 4 niveau est synonyme de progression en terme de confiance et d’engagement.

Parlons confiance

C’est mon « take away » de cette session, je le dois à Olaf : parler de la confiance, c’est déjà augmenter cette confiance en créant la prise de conscience. Olaf et Michael nous proposent le VAST cycle, directement inspiré des travaux des McCarthy. :

  • Vulnerability
  • Authenticity
  • Safety
  • Trust

La présentation contient les visuels illustrant le propos

InfoQ propose aussi 2 interviews des orateurs, ici et ici.

Si vous êtes vraiment motivés, vous pouvez aussi visionner le Webminar de Michael Sahota ici. Attention, il paratage mon goût pour les chemises atypiques…

Note de lecture : Service Design Patterns, par Robert Daigneau

Note : 5 ; Des patterns qui sont plutôt des exemples d’implémentation…

Ce texte, ce devrait être en principe le complément des Enterprise Integration Patterns de Gregor Hope. Dans la pratique, il n’est pas à la hauteur de son ainé, même s’il nous permet d’apprendre certaines choses sur les web services, qu’ils soient SOAP ou REST.

En pratique, ce texte de 270 pages est découpé en 7 chapitres. Il faut aussi compter les annexes qui ajoutent une trentaine de pages de glossaire et référence de patterns. Les 10 pages du premier chapitre servant d’introduction ne nous apprennent pas grand chose, passons ! Le second chapitre est plus conséquent, en nombre de pages d’abord car on en compte 40, mais surtout par le contenu. C’est de « style de web services » dont il est question, de 3 styles plus précisément : RPC, orienté messages et orienté ressources. Ce chapitre focalise sur les considérations d’architecture liées à ces 3 styles, c’est donc en fait la véritable introduction au reste du livre ! En tout cas, le contenu est digne de Martin Fowler.

Au chapitre 3, on consacre 30 pages aux patterns d’interaction client-serveur. J’ai particulièrement aimé le pattern dédié à la négociation de média, et dans une moindre mesure celui sur les services liés. De manière générale, on reste ici sur des choses assez simples.

Le chapitre 4 est plus conséquent, il couvre sur 50 pages les patterns de gestion des réponses. Il s’agit là de patterns à caractère architecturaux. Le chapitre n’est pas très convainquant, trop de place est consacrée à du code d’implémentation qui dépasse largement le cadre de l’illustration des patterns. C’est le cas du DTO, par exemple.

Au chapitre 5, il est question de « styles d’implémentation » sur une trentaine de pages. Il laisse une impression mitigée, car certains patterns nous éclairent comme le workflow adapter et l’opération script (entre autre), mais leur illustration souffre d’un manque de clarté. Encore une fois, le code n’est pas à la hauteur et les diagrammes de séquence (une bonne idée), hélas plutôt mauvais.

Le chapitre 6 consacré à l’infrastructure est le gros morceau du livre, avec plus de 60 pages. Tout comme le chapitre précédent, les sujets sont en principe plutôt bons (dispatcher, asynchronous handlers…) mais le texte échoue à rendre cela passionnant.

Enfin, au chapitre 7, nous consacrons notre attention à la gestion du changement : versionning des services, compatibilité ascendante, etc… Les 40 pages dédiées au sujet ont une allure nettement plus « pattern » que la prose des 2 chapitres précédents. De bonnes idées et réflexions à utiliser et développer !

Globalement, je garde une impression mitigée de ce livre. L’assemblage de patterns est assez hétéroclite. J’ai l’impression que l’auteur à d’avantage cherché à couvrir le terrain qu’à construire un langage de patterns cohérent. De plus, ces patterns n’ont pas la qualité que j’en attend : exprimer de manière claire et synthétique l’essence de la solution, le contexte d’usage avec ses forces et faiblesses. On mise bien trop sur un exemple de code d’implémentation trop lourd pour servir d’explication. Mauvaise pioche !

D’un autre côté, le texte recèle un nombre respectable de patterns tout à fait intéressant et utilisables directement lors de la mise en place de web services. Qui plus est, l’auteur fait un bon effort pour clarifier à quel style de web service chaque pattern est adapté. Au final, une lecture pas indispensable, mais qui n’est pas une perte de temps non plus.

Référence complète : Service Design Patterns – Robert Daigneau – Addison Wesley / Signature series 2012 – ISBN : 978 0 321 54420 9

Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services


https://www.goodreads.com/book/add_to_books_widget_frame/032154420X?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

12 leçons (durement) apprises de transition agile : le live !

Ça a marché pour moi, mais je ne pas garantir que cela marchera pour vous … peut-être la 13ème leçon à garder en mémoire en visionnant mon intervention lors du Printemps Agile 2015.

J’avais posté ici-même le support de présentation il y a peu. Si vous acceptez d’en prendre pour 50 minutes, le propos vous éclairera encore d’avantage. Si j’ai le courage, je convertirais même le tout en article comme je l’ai fait pour la plupart de mes présentations. Mais il faudra être patient.

Si l’éclairage est loin d’être parfait, c’est difficile à nier (et difficile à gérer avec une projection), le CEMU a fait un remarquable travail de montage avec le support. C’est une excellente surprise, qui va bien plus loin qu’une simple synchronisation. Merci et bravo à eux.

Note de lecture : Growing Object-Oriented Software Guided by Tests, par Steve Freeman & Nat Pryce

Note : 8 ; Craftmanship en grandeur réelle

Quand on évoque le craftmanship, on montre des exemples de code, sinon cela n’a pas de sens ! Généralement, il s’agit de 2 ou 3 classes qui se battent en duel que l’on refactore afin d’améliorer les abstractions, éviter les duplications de code et tout et tout… Ce livre-là est différent, car il va faire du design émergent en TDD une réalité en l’appliquant sur la construction d’un logiciel complet, le tout suivi pas à pas ! Pour mener à bien sa mission, le texte compte un peu moins de 330 pages hors annexes, le tout découper en 5 parties très inégales. Je ne vais pas vous compter par le menu les 27 chapitres de l’ouvrage, mais plutôt les 5 parties.

La première partie est introductive (comme on peut s’en douter). Elle ne compte que 3 chapitres sur 25 pages. Il s’agit avant tout de considérations générales, mais non dénuées d’intérêt. On y évoque des principes nouveaux ou anciens comme le cycle ATDD imbriqué dans le cycle TDD, les cartes CRC ou le « tell, don’t ask ».

La seconde partie, longue d’un peu plus de 40 pages sur 5 chapitre, adresse spécifiquement la façon de travailler en TDD sur un projet réel. Cette partie évoque la question du style des tests, comment ils doivent être conçu pour être lisibles et tester des comportements. Mon sujet préféré dans cette partie a trait à l’architecture agile : les auteurs y développent l’architecture hexagonale (Cockburn) ou en oignon (Martin). Cette partie s’étend jusqu’à l’évocation du test logiciel avec les parties tierces (en utilisant des mock), mais il reste léger là-dessus.

La troisième partie occupe la majeure partie du livre. Il compte en effet 150 pages découpées en 11 chapitres, au long desquelles nous allons construire un « auction sniper » ! On ne commence pas par le plus facile, d’ailleurs. Car s’il y a bien un choix discutable, c’est bien de s’être fixé sur une application Swing ! On passe donc les 3 premiers chapitres à faire passer notre premier test ! Par contre, malgré la « glue Swing », on a bel et bien un premier test au sein d’un design simplifié au maximum où la logique métier côtoie l’IHM et les aspects techniques de communication. Et on a aussi une « todo liste » qui nous guidera au long des chapitres suivants ! Les chapitres suivant font progressivement émerger le design, en utilisant les tests comme signal d’alerte de confusion et en s’appliquant à ce que ces refactorings n’aient pas d’effets de bord sur les autres tests. On y introduit aussi les fonctionnalité de JMock. Ou plutôt nous laisse-t-on deviner comment ça marche (les annexes comprennent un tutorial JMock). Les règles de design telles que la gestion du NULL, la gestion des types métier sont introduits progressivement en faisant émerger le design. Au fur et à mesure, le système s’étoffe aussi de nouvelles fonctionnalités. Régulièrement, en plus du code, les auteurs nous livrent des morceaux de modélisation « à main levée ». Toute cette saga ne se lit pas avec la même fluidité d’un bout à l’autre et globalement elle demande pas mal d’attention et de concentration. Mais c’est un sacré exercice riche d’enseignements.

La 4ème partie couvre une cinquantaine de pages sur 5 chapitres. On y aborde des sujets récurrents de tout développements logiciels et souvent éludés en terme de design. Pas de ça ici : les auteurs proposent des positions et des idées qui font honneur au mouvement craftmanship » ! Le sujets abordés sont le logging, les diagnostiques, la lisibilité des tests, la construction de cas de tests avec des structures de données complexes. Entre autre choses. Bref, une partie que j’ai particulièrement appréciée.

La dernière partie occupe 3 chapitres sur 50 pages environ et se focalise sur des sujets avancés en terme de tests unitaires : la persistance, le multithreading et l’asynchronisme. Je le voie plutôt comme du matériel complémentaire, pas réellement nécessaire au propos, mais évidemment intéressant.

Le craftmanship ne recèle pas de tant de titres de qualité. Celui-ci se démarque par son focus sur le design d’application et non sur une vue zoomée de code, comme c’est trop souvent le cas. Le livre est resté longtemps à prendre la poussière sur mes étagères, c’est bien dommage ! N’en faites pas autant.

Référence complète : Growing Object-Oriented Software, Guided by tests – Steve Freeman & Nat Pryce – Addison Wesley / Signature series 2010 – ISBN : 978 0 321 50362 6

Growing Object-Oriented Software, Guided by Tests


https://www.goodreads.com/book/add_to_books_widget_frame/0321503627?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

How do you know that your product works ?

Ai-je vraiment « terminé » ?

C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?

  • Quand le code est commité ?
  • Quand le produit est testé ?
  • Quand il est déployé en production ?

Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.

Où l’on reparle de valeur

La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.

Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.

Un produit commence avec une grande idée

Mais au-delà de cette idée, ou plutôt en chemin, nous avons toute sorte de risques.

  • Des risques techniques : avons-nous la technologie pour réaliser notre produit, la maîtrisons-nous ?
  • Des risques sociaux : pourrons-nous faire travailler ces personnes ensemble.
  • Des risques de coût et de planification : pourrons-nous sortir le produire à temps et aurons-nous les fonds pour le faire ?
  • Mais surtout, surtout : des risques business ! Notre produit doit être pertinent, donc désirable.

Henrik Kniberg nous rappelle ainsi 3 exemples de produits qui ont échoué à l’épreuve de la pertinence, pourtant tous issus de Google !

Suis-je en train de construire le mauvais produit ? C’est là la question clé à laquelle le Lean Startup nous invite à répondre afin de vérifier nos hypothèses par le biais de MVP et d’expérimentations.

C’est l’exemple de Dropbox que j’utilise moi-même souvent (et cité dans le livre d’Eric Ries que Kniberg reprend : ici le MVP est une vidéo ! Une vidéo totalement « fake » bien sûr, mais qui a permis de tester le marché à pas cher !

Une technique alternative est le « paper prototyping ».

De l’idée à la mesure

La « pirate metric ». Pourquoi « pirate », car le cri du pirate à l’abordage, c’est AARRR !!

  • Acquisition : Les clients viennent-ils ?
  • Activation : Utilisent-ils le produit
  • Rétention : Reviennent-ils ?
  • Référent : Nous recommandent-ils à leurs semblables ?
  • Revenu : Paient-ils ?

Le tout en forme de « funnel ».

Après le big bang

Par rapport à ceci, le big bang apparait une approche très risquée : on accumule les coûts en différent l’acquisition de valeur (si jamais elle arrive). Le chaos manifesto 2013 nous explique même que limiter la taille et la complexité est le principal facteur clé de succès. Autant pour ceux qui clament qu’il faut faire de l’agilité à plus grande échelle… Pensez plutôt à descaler, à faire de plus petites choses, de plus petits projets… ou de petites releases. Petites releases qui signifient déploiement en production réellement aisé.

A contrario, l’approche « big bang » nous conduit à faire de grosses releases, donc des releases difficiles. Et comme celles-ci sont difficiles, on s’efforcera d’en faire le moins souvent possible… Pour sortir de ce cercle vicieux, il faut faire de la release une routine. Comme on l’a fait il y a 15 ans pour l’intégration

Si quelque chose est difficile, faites-le souvent.

Où l’on (re)parle de la rapidité d’apprentissage

Déployer plus souvent, c’est avoir un feedback plus rapide de ses utilisateurs : c’est apprendre plus rapidement ! Apprendre plus rapidement cous permet de délivrer ce qui a le plus de valeur en premier, et ainsi de « dépasser la courbe d’investissement » tôt dans le cycle, et ceci en sélectionnant nos fonctionnalités de manière plus pertinente.

Nous le savions déjà, ce n’est pas l’occupation que nous devons optimiser, ni même « l’output », ce que nous délivrons, non c’est la valeur que nous délivrons que nous devons optimiser. Et cela ne peut se faire qu’en apprenant de nos utilisateurs. Henrik Kniberg trouve une manière très élégante d’exprimer cela :

Être focalisé sur la réduction de la distance plutôt que sur l’augmentation de la vitesse.

Spotify again

C’est avec Spotify, bien sûr, que l’orateur choisit d’illustrer tout son fil conducteur.

On part d’une idée. C’est le « think it » de Spotify. Pour toucher terre, il faut l’associer à un « narrative » et déterminer les métriques qui nous guideront.

Le « build it » qui suit s’inspire directement du Lean Startup, car c’est d’un MVP qu’il est question.

Le « ship it » met ce MVP entre les mains de l’utilisateur, pour en recueillir le feedback et en tirer les enseignements. On passe du « guessing » aux enseignements.

De ces enseignements, on tire les ajustements ou les changements de direction à opérer. C’est le « tweak it ».

Plus que savoir, c’est s’assurer que le produit fonctionne : en comprenant le problème, en apprenant de nos utilisateurs. Puis en itérant jusqu’à ce que le problème soit résolu.

La captation est de mauvaise qualité hélas, mais suffisante pour entendre le propos de l’auteur lors d’Agile Ceylon en 2014 à Colombo