Note de lecture : The Back of the Napkin, par Dan Roam

Note : 7 ; Le grand classique de la résolution de problèmes par la visualisation

Cela faisait un moment que je tournais autour de ce grand classique. Il n’y a plus pour moi aucun doute sur la raison pour laquelle ce titre mérite sa réputation, et elle est grandement méritée. Par contre, il ne va pas être très facile de résumer cela ! Tout d’abord le livre lui-même est d’un format inhabituel (il est de format carré), et ses 256 pages se comparent difficilement à un format classique. Ceci sans compter les très nombreux dessins de l’auteur qui sont l’âme même du livre.

La dernière représentation de l’auteur, page 255, résume parfaitement la teneur du propos, c’est à dire l’articulation de la démarche proposée en 4 plans.

  • Tout d’abord les « basic visual thinking tools » : les yeux, les « yeux de l’esprit » et la coordination œil-main. Il n’y a pas de chapitre à proprement consacré à ce plan, mais il est abordé au chapitre 2, avec une vue générale du framework.
  • Les 4 étapes de la pensée visuelle : regarder, voir, imaginer et montrer. L’auteur décompose ce processus au chapitre 3, en s’appuyant sur une partie de Poker ! Un cheminement qui met en valeur les qualités pédagogiques de l’auteur.
  • Le SQVID. Il s’agit d’un « framework de visualisation », probablement la partie la plus délicate de l’ouvrage. Elle est abordée au chapitre 6. Celui-ci méritera (au moins) une seconde passe.
  • Les 6 façons de regarder, qui correspondent à 6 questions : Qui / quoi ? Combien ? Où ? Quand ? Comment ? Pourquoi ? Abordé au chapitre 5, ce framework que l’auteur présente comme le <6><6> rules est développé réellement au chapitre 7.

Lire la suite

What is Scrum ? Par Henrik Kniberg

Une façon classique de présenter le sujet est de commencer par le manifeste, puis d’évoquer le « parapluie agile » et les différentes approches qu’elle abrite : Scrum, XP, Kanban, etc.

Mais c’est surtout : délivrer tôt de la valeur métier et « moins de bureaucratie ». Pour illustrer cela, Kniberg nous trace le Value Stream Map d’une entreprise développant des jeux : un temps de cycle de 25 mois pour 3 mois de travail utile seulement ! La logique de telles entreprises est de minimiser les coûts en maximisant l’utilisation des ressources.

Optimiser l’utilisation des ressources

Il s’agit d’une illusion à plusieur titres. Tout d’abord occuper au mieux l’équipe ne garanti pas une meilleure productivité, au contraire. Preuve nous en est donnée lors des week-end de départ en vacances…

Par ailleurs, notre travail n’est pas de produire du logiciel … mais de résoudre des problèmes. Et si possible en produisant le moins de logiciel possible pour ce faire !

Lire la suite

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…

What is an agile tester ?

Rôle, quel rôle ?

Oui, le tester agile n’a plus la même place qu’avant. Tout d’abord, il n’y a plus d’équipe de test, mais un testeur intégré dans une équipe pluridisciplinaire ! Ce qui signifie aussi par voie de conséquence qu’il n’y a plus de phase de test. En fait, pour aller plus loin, il n’y a plus non plus de rôle de testeur !

La qualité est désormais l’affaire de tous, on passe de la notion d’assurance qualité à celle d’assistance qualité. C’est pourquoi ce n’est plus le rôle de testeur qui primer mais la compétence qu’il véhicule et injecte dans l’équipe. Kniberg nous débarque le concept de « T shape compétences », que personnellement je n’aime pas trop.

S’assurer que le produit marche

L’assistance qualité, dans une équipe agile recouvre un certain nombre d’activité que l’auteur nous énumère. Mais surtout, le testeur agile doit travailler en interaction avec les développeurs et les utilisateurs afin de toujours raccourcir la boucle de feedback, une idée qui s’inscrit bien dans la philosophie du « continuous delivery ».

Parlons tests

A un moment donné il faut bien parler tests. Mais de quel tests ? Petite leçon de vocabulaire de la part d’Henrik, et aussi de la nécessité des tests exploratoires… et d’inclure la dette technique dans la notion de qualité.

Kniberg nous propose aussi de maintenir un « tests automation backlog », et aussi un « tech backlog » qui s’injecte dans les sprints en fonction d’une bande passante réservée.

Pendant ce temps, chez Spotify…

Kniberg est aussi connu pour avoir popularisé le mode de fonctionnement chez Spotify. Je ne vais pas revenir dessus, cela a été largement exposé. La culture Spotify amène par ailleurs à privilégier le « failure recovery » au « failure avoidance », selon une approche que l’auteur appelle le « limited blast radius ».

Big government

Chez ces institutionnels, la structuration en phases est de mise, une approche que nous agilistes abborhons. A cette approche, Henrik Kniberg propose comme alternative une approche Kanban en « multi-swimlanes ». La présence de plusieurs équipes permet aux testeurs (et aux autres communautés aussi, d’ailleurs) de se synchroniser au sein de stand-up transverses.

Une autre pratique spécifique aux tests au sein de ce type de projet : le « ready for system tests », qui est un moyen d’intégrer les tests système au sein des itérations.

Un process spécifique de traitement des anomalies peut aussi s’avérer nécessaire. Piètre constat mais que j’ai moi-même fait à différentes occasions.

Management Workouts 3.0, par Jurgen Appelo

Management Workout, c’est le titre du dernier ouvrage de Jurgen Appelo. J’ai distillé ici une partie des ces exercices que l’auteur a mis à disposition. Le management workout, ce sont des exercices conçus pour pouvoir être mis en oeuvre « dès lundi matin » ! Cette présentation en survole un certain nombre.

  • Improvement dialogues : Ou comment générer des conversations nous guidant vers l’action.
  • Personal Maps : Ou comment gérer la relation à son travail et à ses collègues en terme de distances physiques et cognitives.
  • Kudo Box : Savoir valoriser le remerciement, c’est déjà changer la dynamique des relations dans une organisation.
  • Work Expo : Une organisation doit savoir être fière du travail de ses collaborateurs… et le montrer !
  • Project Credits : Comment penser le titre de votre job ou gérer votre réputation ?
  • Salary Formula : Comment concevoir les abaques salariaux ?
  • Delegation Board : Où comment partager le niveau de décision entre managers et équipes.
  • Metrics Ecosystem : Comment mesurer la performance d’une organisation et quels sont les impacts de ces pratiques ?
  • Merit Money : Le système des bonus ne porte pas la collaboration que l’on souhaiterai dans l’organisation. Repensons la façon de rétribuer !
  • Yay Questions : Des questions qui nous invitent à célébrer ce que nous avons bien fait !

Ce survol ne fait que picorer dans le différents sujets. Il y a mieux à faire : lire effectivement les workouts. Ou encore mieux : acquérir le livre de Jurgen … il y a de nombreux autres workouts à découvrir !

Scrum Shu Ha Ri, le live

Voici la vidéo de ma présentation « Scrum Shu Ha Ri » faite lors du Printemps Agile organisé à Caen. Un grand merci à l’équipe du CEMU qui a effectué la prise vidéo et le montage. Vous pouvez retrouver cette vidéo (et d’autres du Printemps Agile) sur cette page. J’avais par ailleurs fait deux posts sur cette conférence, accessibles ici et ici (), et une galerie photo visible ici.

Le support de cette présentation se trouve ici. J’ai par ailleurs rédigé un article un article s’appuyant sur le matériel de cette présentation que vous trouverez ici.

Spotify Engineering Culture

Henrik Kniberg communique beaucoup autour de Spotify qui constitue aujourd’hui le gros de son activité !

1ère partie

J’avais partagé précédemment les papiers de Kniberg sur l’agilité à grande échelle et la manière dont Spotify construit ses produits.
Cette vidéo, ou plutôt cette animation nous explique à la fois le cheminement, l’organisation et la dynamique de cette “culture agile”.

Pour résumer plus brièvement cette vidéo, peut-être préfèrerez-vous la fresque ?

image

2nd partie

Ici, Kniberg évoque le « fail friendly environment » qui favorise l’apprentissage ! Ainsi les incidents ne sont clos que quand les laçons en sont tirées, pas à la résolution du problème. Accepter d’échouer, c’est aussi le faire sur une petite échelle afin de pouvoir s’en remettre, d’où les « Limited Blast Radius ».

Le développement des fonctionnalités suit le cycle Lean Startup. Là encore, ce sont des choses qui ont été évoquées dans « How Spotify Builds Products ». Lean Startup signifie aussi focus sur l’innovation, ce qui va à l’encontre de la vélocité trop souvent mise en avant !

100% predictability = 0% innovation

Pour favoriser l’innovation, il y a aussi le 10% « hack time ». La culture est résolument tournée vers l’expérimentation, les choix sont ainsi « data-driven » plutôt que « opinion-driven » !

Parmi les choses qui sont bannies sont les gros projets ! Gros projet signifie gros risques. Essayons donc de les transformer en petits projets !
Autre problème, celui de la croissance, et de la nécessité de trouver le bon équilibre entre bureaucracie et chaos ! Il y a donc des problèmes dans ce monde merveilleux. Mais la culture prévalente est de fixer ces problèmes rapidement. Ainsi :

Une culture saine sait soigner les processus boiteux.

Comme pour la première partie, la fresque est aussi disponible

image

La résistance contre l’ISO 29119 s’organise !

Au départ…

Les agilistes ne sont guère friands de normes et autres standards. Généralement, nous nous contentons de les ignorer. Néanmoins ils sont souvent utiles.

C’est en proclamant l’utilité des standards, de la plupart des standards que James Christie commence sa présentation lors de la conférence CAST 2014, celle par laquelle tout a commencé. Car c’est contre les standard de test que s’élève le présentateur. Son propos rappelle celui de Dominique Dupagne dans La revanche du rameur qui clame que standardiser les processus n’assure en aucun cas la qualité du produit, qu’en fait il s’agit même d’une bonne occasion pour s’en désintéresser !

La question de considérer l’activité de test comme un « commodité » tend à donner une dimension directement économique à ce travail, ce que l’orateur juge trop simpliste (il a lui-même un diplôme en économie). De manière générale, il est d’ailleurs toujours possible de trouver une théorie économique correspondant à ce que l’on cherche à prouver ! James Christie nous ramène lui à Adam Smith, le père du capitalisme et ses 3 facteurs économiques : le travail, le capital, la propriété.

En alignant les processus de tests, les organismes de normalisation servent les cabinets de conseils qui pourront ainsi vendre du conseil sur ces processus normalisés. Les éditeurs devront eux dépenser de l’argent pour se conformer aux normes. Finalement, le consommateur y perdra aussi, car le focus des éditeurs se déplacera de la qualité du produit vers le respect des normes de processus !

La standardisation de l’activité de test nous amènerai vers une « licence » de testeur qui ne serait en aucun cas gage d’efficacité, ce que l’orateur trouve effrayant ! Imaginez un chirurgien : elles-vous jugez de sa qualité du fait du suivi d’un standard ou du nombre de personnes qu’il tue ? Le focus de ces standard est la documentation plutôt que le test réel !

Un autre point soulevé par James Christie est celui de l’asymétrie de la connaissance : plutôt que de communiquer la connaissance à celui qui en a besoin, le standard masque celle-ci par un écran de fumée. Il se réfère aussi aux pratiques d’audit : celles-ci disent qu’il n’y a pas 2 contextes IT semblables, ce qui rend caduque toute idée de checklist générique (institute of internal auditors). Les standards promeuvent plutôt une idée de « sauver ses fesses » en suivant celui-ci à la lettre afin d’être irréprochables !

Finalement l’orateur exhorte le publique à garder ouvert ce début contre l’ISO 29119, car l’absence de consensus seulement permettra de le remettre en cause.

Au fait, c’est quoi l’ISO29119 ?

Tout d’abord, la parole à l’avocat de la défense, Stuart Reid, avec cette introduction à l’ISO 29119

L’ISO 29119 se veut un consensus sur la manière de procéder des tests, c’est une démarche normalisée comprenant définition des processus et de la documentation. Elle est déjà mise en oeuvre par certains cabinets de conseil.

La résistance s’organise

Tout d’abord avec un manifeste, initié lors de cette même conférence CAST 2014 !

image

Une pétition fait suite à cet acte de foi. Difficile toutefois de s’opposer au corporatisme, mais cette communauté a choisi aujourd’hui de ne pas se laisser faire !

Je voulais saluer ce mouvement, bien que n’étant pas testeur, non seulement pour leur courage de défendre leurs idées, mais surtout parce qu’ils ont raison !

Autres ressources

Agile at Home, par Henrik Kniberg

Changement de décors pour cette nouvelle présentation de Henrik Kniber : comment mettre en oeuvre les pratiques agile et Lean à la maison avec 4 enfants !

Kanban

D’abord le Kanban. Il y en a un peu partut chez les Kniberg ! Un Kanban commun pour les tâches partagées, sur le réfrigérateur pour les enfants ou encore pour préparer un barbequeue entre amis.
La famille Kniberg est partie durant 8 mois pour un « familly trip » autour du monde. Il y a eu un Kanban pour préparer cela aussi. Cela comprenait d’ailleurs une expérimentation du concept, avec un séjour de 4 jours à Londres.

WIP limite

Un problème récurrent avec les enfants : le bordel dans la chambre ! Un problème qui ne s’est pas posé durant leur voyage, car la quantité d’affaires à transporter était limitée. Alors on utilise le même système : on limite le nombre de vêtements à ce que peuvent contenir les tiroirs !
Un système qui s’étend ensuite à la cuisine, pour le lavage de la vaisselle, avec une pincée de « definition of done ».

Burnup chart

Junior a du mal a être dans les clous avec ses devoirs ? Son coach de père lui met au point un burnup chart a suivre lui-même au fur et à mesure qu’il fait ses devoirs.

Autres management visuel

Cartes, « dream gallery », Kaizen boards, Henrik Kniberg n’hésites pas non plus à utiliser tout l’arsenal de management visuel à sa disposition.

Ce que j’en pense

Une vraie mise en oeuvre des principes agiles dans la vie réelle. C’est même assez impressionnant, je dois dire, même si je sais que certains de mes confrères s’essaie au même genre de chose..

Et moi alors ?

Eh bien non. En ce qui me concerne, je préfère laisser mon arsenal d’agiliste hors de la famille…

What to do when Scrum doesn’t works

Et d’abord, c’est quoi Scrum ?

Oui, je sais, on peut faire référence au Scrum Guide et à toute ces sortes de choses, mais pour Henrik Kniberg, ce sont :

  • De petits morceaux de fonctionnalités
  • Des équipes subdivisées en petites équipes
  • De petites tranches de temps.
  • Une valeur métier optimisée
  • Avec un processus optimisé !

Et c’est tout !

Pourtant, visiblement, tout ça peut mal se passer. Voyons comment et comment y remédier. Avec 5 cas de figure.

Mal utiliser le processus

S’en prendre à Scrum alors qu’il faudrait plutôt penser à notre façon de l’utiliser est le premier symptôme. Le grand classique est le temps consacré aux cérémonies : s’il est exagérément long, il s’agit simplement d’un avertissement, nous essayons de pratiquer Scrum comme une méthode classique !

Le fondamentalisme ne rend pas non plus beaucoup de services. Ils qualifient d’erroné tout ce qui ne marche pas en agile, tout comme ils qualifient de « cycle en V » tout ce qui n’est pas agile. Pourtant le cycle en V marche aussi dans le bon contexte…

Blâmer le messager

L’une des vertus de Scrum est de faire remonter les problèmes à la surface rapidement : le projet est trop gros ? La qualité n’est pas au rendez-vous ? Il est préférable de le savoir avant qu’après ! Or nous sommes habitués à vivre longtemps dans l’ignorance, il semble naturel de blâmer un processus qui va nous révéler des défaillances dès le premier mois… Il faut alors travailler de manière systématique sur ses faiblesses, via de l’analyse causale.

Henrik Kniberg pointe aussi les « Sadoscrumistes » : si ça fait mal, c’est que c’est bon…

L’impatience

Passer d’une procesus classique à un processus agile, c’est une courbe de changement. Et la première étape du changement, c’est le chaos ! La ou les premières itérations d’un projet agile peuvent donner des résultats moins bons qu’avant. Laissez un peu de sursis à Scrum !

Ne pas adapter le processus

Scrum est un cadre, pas un carcan. Si une pratique ne convient pas, il faut chercher à l’adapter plutôt que jeter brutalement Scrum !

Utiliser le mauvais processus

Certains contextes se prêtent mal à Scrum et plus précisément au rythme des itérations. Scrum n’est pas le seul processus agile ! Il ne faut pas être dogmatique, ce qui nous enferme dans le « Scrum Shu ». Evoluer, ce peut être se détacher de Scrum ou emprunter une autre voie telle que Kanban.

Autres Ressources