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

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

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.

Focus

Chap 1 : Où l’on parle de flux

Le focus, au niveau de l’entreprise, qu’est-ce que cela signifie ? En premier lieu, de se concentrer sur la chaine de valeur. Et sur le flux, plutôt que l’utilisation des ressources. Le Value Stream Mapping est un des outils permettant de mettre en évidence les possibilités d’amélioration de ce flux.

Le corollaire est de se concentrer sur un petit nombre de features plutôt que sur des gros batches qui mettent du temps à passer dans le rétroviseur. Donc du Focus !

Chap 2 : Se faciliter la vie

Nous avons vu le problème du « trop de choses à faire ». Et le temps pour le faire est limité. Bien entendu, nous avons moins de temps disponible que de choses à faire. Mais en réalité celles qui sont indispensables n’en sont qu’une fraction. On pourrait appeler le reste des « options » ! Nous sommes maitres de nos choix, n’en devenons pas les esclaves.

Chap 3 : Tel un hamster dans sa roue

Les sollicitations nous viennent de toute part ! Elles créent un bruit qui nous empêche de faire ce qui est important. S’isoler de ces perturbations et se concentrer sur une seule chose jusqu’à ce qu’elle soit terminée, il n’y a rien de nouveau là. Quelques techniques peuvent nous aider comme le « zéro inbox » ou le Pomodoro.

Chap 4 : « non, merci »

Nous avons du mal à dire « non ». En tout cas, moi j’ai cette difficulté. Quand, comment et pourquoi dire « non », afin de se focaliser sur ce qui a vraiment de la valeur, c’est le sujet de cette partie. C’est ce que Henrik Kniberg appelle le « value filter ».

Chap 5 : s’échapper de la roue du hamster

Une seule règle : se ménager du mou. Mais du mou qui nous remettre dans une boucle vertueuse … pour enfin sortir du cercle vicieux !

Chap 6 : Ce que nous faisons définit là où nous sommes

Cela signifie (en clair), que pour être maître de notre destin, nous devons nous efforcer de donner la priorité aux tâches nous conduisant à ce que nous voulons faire. C’est un peu un raccourcis, mais c’est un peu l’idée ! Donc travaillons notre répartion de ccharge de travail, non pas en fonction des nécessités du moment (en tout cas pas seulement), mais en fonction de ce que l’on veut qu’elle soit !

Chap 7 : Une histoire (très) personnelle

Où Henrik Kniberg nous parle de son voyage autour du monde avec sa famille. Une approche qui me rapelle en de nombreux points le « solution focus » : plutôt que de lister ce qui nous empêche de le faire, se focaliser sur ce qui est nécessaire pour rendre cela possible. Et planifier ensuite ce qu’il y a à faire ou les expérimentations à mener qui vont valider les hypothèses.

Plus amusant, ce que les enfants ont appris sur la rationalisation de leurs affaires, qu’ils ont ensuite appliqué en rentrant à la maison !
Cet épisode a été largement exposé dans agile@home !

Chap 8 : World WIP Waste

La réutilisation n’est probablement pas du gâchis, car Henrik Kniberg se ressert à tour de bras du matériel de agile@home !

Le gâchis, c’est ce qui nous empêche d’aller vite, donc d’être agile. Dit autrement : on cours moins vite avec des bottes en plomb !

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

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

Bootstraper un déploiement continu sur le cloud avec CloudBees

En 25 minutes, Henrik Kniberg nous fait la démonstration depuis zero de la création d’une petite webapp type « hello world » sous Eclipse, avec son test local avec Jetty et ses tests unitaires, vers la mise sous Git dans CloudBees, l’intégration dans Jenkins et le déploiement dans un sandbox, toujours sur CloudBees. Partant de là, on complexifie l’application en y intégrant une persistance avec MongoDB sur la base des services accessible depuis la plateforme SaaS !

La vidéo montre en totalité le processus de réalisation, étape par étape, y compris la correction d’erreurs, sans rien omettre ! Un véritable guide à suivre pour construire sa première application sur CloudBees !

What is Agile ? Par Henrik Kniberg

Cette présentation de Kniberg est plutôt dédiée à ceux qui veulent découvrir l’agilité : développeurs et managers. Elle répond en terme simple au « pourquoi » et présente l’avènement des approches agiles par le manifeste: ses valeurs, ses principes et les approches logicielles sous-jacentes.

L’auteur présente le cycle agile comme hautement itératif et incrémental. Ce qui est vrai mais un peu réducteur.

C’est ensuite aux questions de planning, d’estimation et de vélocité que s’attaque Kniberg, avec des illustrations ma foi fort bien faites ! Cette partie me semble plutôt destinée aux managers. Elle joue en tout cas un rôle efficace d’introduction au « maximize value, not output ».
Le point suivant me semble clé : donner à l’équipe un problème à résoudre et non une solution à implémenter … ou comment revenir au « start with why » de Simon Sinek ! Cette résolution de problème s’alimente de feedback, qui lui-même permet de maximiser la valeur et de réduire les risques : la cohérence de ce cycle est bien mis en valeur dans cette présentation !

Une équipe agile c’est une équipe pluridisciplinaire, et Kniberg en profite pour rebondir sur le modèle Spotify et la culture « être agile » d’une organisation.

L’agilité ne se limite pas au développement, il va jusqu’à la mise en production, une occasion de mettre en lumière les principe de déliverie continue. En amont, il implique les vrais utilisateurs au jour le jour.

Au niveau de l’organisation, le présentateur expose le « portfolio level Kanban », qui n’est pas sans rappeler les éléments développés dans Lean From the Trenches.

En conclusion : il y a un prix à payer à la mise en place de l’agilité (organisation, environnement, etc.) et « big is bad », aussi bien pour les projets, les fonctionnalités, les cycles ou les équipes !

Kniberg au Scrum Gathering Paris 2013 : Cullture over Process

Henrik Kniberg faisait la keynote d’ouverture lors du Scrum Gathering à Paris en Septembre dernier. La vidéo est en deux parties : la première est ci-dessus et la seconde , ci-dessous !

“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.

Ne ratez pas la conclusion de Kniberg sur le dernier slide : des conseils concis à suivre absolument.