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

Water – Scrum – Fall … la réalité d’aujourd’hui ?

Le constat

Oui, l’agilité gagne en popularité dans les organisations ! Du moins, apparemment. Les idées qui en sont à la base comme le « people centric » génèrent un réel intérêt. Aujourd’hui plus encore qu’hier, « agile » rime avec « Scrum ». Cet article met en exergue ce qui était déjà un soupçon fort, ce que j’appelle le Scrum « Canada Dry » dans mon article Scrum Shu Ha Ri :

  • La MOA rebaptisée « Product Owner ».
  • L’organisation matricielle, avec les développeurs devant partager leur temps sur plusieurs projets (je l’avait raté celle-ci)
  • Des itérations qui ne couvrent que partiellement le cycle logiciel
  • La « culture projet » où les équipes se font et se défont régulièrement au grée des projets.

Les organisations elle-même créent un carcan dans lequel inscrire un projet agile devient compliqué, à moins d’en pervertir la logique : logique budgétaire, silotage des activités, prédominance de la « logique document » et des releases parcimonieuses pour d’apparentes raisons économiques et culturelles.

Pourquoi ?

Ce constat met en relief un aspect quasi schizophrénique de l’adoption de l’agilité (d’où le titre de l’article). Celui-ci s’explique du fait de l’adoption des processus agiles par les praticiens qui tend à cloisonner l’agilité dans les équipes de développement, les équipes connexes restant attachées à leurs anciens processus. La réalité du « water-scrum-fall » se traduit par :

  • En amont : de lourds processus budgétaire et cadrage qui engagent les développements sur des besoins mal connus ou erronnés mais définis à l’avance. Non seulement ce passage de relai anihile la flexibilité que l’on attend des processus agiles, mais il démobilise les équipes.
  • Un développement « agile » mais au mandat amendé :
    • Moins de « cross-fonctionnalité » car les besoins sont traités ailleurs.
    • Pas réellement de « potentiellement déployable » car le test est déféré hors du sprint.
    • Pas d’interaction avec le client, car c’est l’objet du cycle amont.
    • Pas d’adaptation au changement car le plan est fixé quand le développement arrive à l’équipe.
  • En aval : Une ligne de démarcation importante stigmatisée par une « séparation des responsabilités » qui crée une situation de confrontation entre développement et opérations conduisant à des releases moins fréquentes. Ces deux équipes ont par ailleurs des objectifs différents : la réponse aux besoins du business pour l’un, la stabilité et le maintient en conditions opérationnelle pour l’autre.

Quelles recommandations ?

Pour l’auteur, on peut enclencher les bénéfices de l’agilité avec ce modèle à 3 bandes :

  • Faire maigrir la phase amont. La plus grande partie de la production de cette phase est du gâchis.
  • Rendre l’équipe de développement réellement pluridisciplinaire. Donc en intégrant les capacité d’analyse et la relation avec l’utilisateur.
  • Accroitre la fréquence des déploiements en aval.

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.

Champfrogs Checklist, un Management Workout par Jurgen Appelo

Pour Jurgen Appelo, le business ne doit plus seulement être adaptatif, il doit être transformatif ! Et pour rendre cela possible, nous devons, en tant que personnes, être des transformateurs. Etre un transformateur dans notre monde super-connecté signifie être soi-même connecté et surtout pouvoir influencer les autres dans la direction qui nous convient.

Où l’on parle de motivation intrinsèque…

Oui, être agent du changement, c’est bien mais en réalité les personnes que nous voulons changer répondent d’avantage à leur part d’irrationnel (leurs envies, leurs peurs) qu’à leur part de rationnel. C’est là qu’interviennent les « moving motivators », la détection des motivations intrinsèques qui servirnt de levier au changement, que Jurgen Appelo a popularisé dans son jeu. L’auteur a lui-même repris Daniel Pink qui les évoquent dans Drive :

  • L’acceptation (par les autres, par les collègues)
  • La nourriture. Ce sont les besoins essentiels, cux qui constituent le niveau de base de la pyramide de Maslow.
  • La famille
  • La liberté, l’indépendance.
  • Le sens. C’est la nécessité de savoir que l’on oeuvre dans un but, pour une finalité.
  • Le sens de l’honneur et de l’intégrité.
  • La compétence et la maîtrise.
  • Le sens de l’ordre et donc de la stabilité. Un besoin qui tire plutôt dans une direction différente des entreprises connecté et du changement.
  • Le pouvoir et l’influence, si chers à nos hommes politiques.
  • La connexion sociale et le besoin de tisser des liens.
  • L’amour. Disons que c’est l’étape suivante !
  • Le sens de la propriété, l’appartenance.
  • Le status social.
  • La sécurité et la tranquilité (retour à la pyramide de Maslow)

On l’on évoque (enfin) le Champfrog

De cette longue série, Jurgen Appelo extrait les éléments qu’il juge pertinent dans le contexte d’une organisation. C’est le fameux acronyme CHAMPFROG.

  • Curiosité : Se demander comment et quoi apprendre, mais aussi donner de la perspective sur les idées des autres.
  • Honneur : Quel est notre engagement de confiance et de responsabilité envers les autres ? Comment construire une confiance réciproque ?
  • Accepation (ou approbation) : De quelle manière notre comportement, nos signes extérieurs sont inclusifs envers les autres ? Utiliser le principe d’association lors de réussite pour construire une acceptation collective.
  • Maîtrise : Comment gagner en compétence et en tant qu’organisation rendre cette acquisition de compétence possible ? Mais aussi : comment valoriser la compétence des autres ?
  • Pouvoir : Montrer son autorité sur un sujet sans faire preuve d’arrogance, c’est l’autorité situationnelle. L’étape suivante est de parvenir à abandonner cette autorité aux autres.
  • Freedom (liberté) : Littéralement, c’est abandonner les contraintes implicites et explicites que l’organisation fait peser sur ses membres pour qu’ils puisse juste faire ce qui est nécessaire…
  • Relations sociales : Etre connecté, c’est d’abord s’ouvrir aux autres. C’est le prémice pour avoir un impact sur les personnes qui nous entourent.
  • Ordre : Il répond à un besoin de simplicité, de limpidité même dans la façon dont une organisation fonctionne.
  • Goal (But) : Pour Jurgen Appelo, la recherche d’un but a à voir avec l’optimisme et l’alignement des besoins de l’entreprise et de ses employés.
  • Statut social : C’est la crédibilité que nous avons et celle que nous accordons aux autres. Sur quels critères est-elle basée ?

Et après ?

Après, il y a le « moving motivator », une activité pour reflechir et expliciter nos motivations… Et bien sûr le présent « workout » !

The New New Product Development game, par takeuchi et Nonaka

Cette publication est connue pour être la source d’inspiration des créateurs de Scrum. Il fut publié en 1986 dans le Harvard Business Review et Hirotaka Takeuchi et Ikujiro Nonaka en sont les auteurs. Ils viennent du marketing et non du développement logiciel.

Les 6 caractéristiques du “Scrum”

On parle bien déjà de Scrum ! Et l’on prête à ce processus 6 propriétés fondamentales :

  • Une instabilité intrinsèque : le top management ne donne aux équipes qu’une direction générale avec un challenge très élevé à relever. Par ailleurs ce management donne une grande liberté d’action et d’interprétation. Cela crée une tension dans l’équipe à même de favoriser la créativité.
  • Des équipes auto-organisées. Elle apparait quand sont réunies 3 conditions :
  • L’autonomie : peu d’intervention du top management, son rôle est de fournir les ressources adéquates. L’entité fonctionne comme une startup.
  • L’auto-transcendance : L’équipe est dans une quête continuelle pour dépasser ses limites.
  • L’auto-fertilisation : une équipe pluri-disciplinaire renforçant leur connaissances respectives à l’image d’un impact hub.

Des phases de développement en chevauchement : le rythme de développement agit comme le poul de l’équipe. Pour permettre le développement selon ces phases courtes, il faut adopter le “sashimi system”. Le multi-apprentissage : il s’effectue à différents niveaux (individuel, collectif, entreprise) et dans les différents domaines d’expertise de l’équipe.

  • Le contrôle subtil : le management influe par petites touches sur l’équipe pour prévenir le chaos. Les auteurs identifient 7 axes d’action :
  • La sélection des membres de l’équipe
  • L’environnement de travail
  • L’encouragement à voir ce qu’il en est sur le terrain (où l’on rejoint le Lean…)
  • Une évaluation et des récompenses au niveau du groupe et non au niveau individuel
  • Gérer des différences de rythmes entre le début et la fin du projet.
  • Tolérer et anticiper les erreurs.
  • Encourager les fournisseurs à devenir eu-même auto-organisés.

La gestion du transfert de connaissance : Il est réalisé de manière osmotique, en réaffectant les membres de l’équipes sur d’autres équipes une fois le projet terminé.

Limitations et implication du management

  • On parle ici d’efforts extraordinaire, de journées de 60 heures ou plus … on est loin du “sustainable pace"…
  • Ce processus ne s’applique pas aux projets d’innovation disruptive
  • Il ne s’applique pas aux organisations centrées autour d’un "génie”.

Au niveau managérial, il faut 3 changements :

  • Un style de management promouvant ce processus.
  • Le management doit accepter que le développement des produits ne s’opère pas linéairement mais itérativement.
  • Le processus implique une suite d’essais / erreurs.

Les entreprises ont pour habitude de voir les projets innovants comme de nouvelles sources de revenus. Mais ils sont en fait avant tout des agents du changement. C’est donc avant tout un changement culturel.

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

The SCRUM Development Process

Cet article est réellement le premier à présenter Scrum, c’était en 1995. Petit détail que j’ignorais, Ken Schwaber l’a mis en oeuvre pour le développement de Delphi ! Déjà l’auteur présente son approche comme étant « boite noire » et empirique, bien adapté au développement de systèmes complexes. Et oui, Scrum est bien en rapport avec le Rugby !
Bien sûr, à cette époque, il n’était pas encore question du mot « agile ». Ken Schwaber situe Scrum comme une évolution des procesus itératifs, non comme une disruption.

Quand il parle du développement logiciel, c’est toujours à la notion de complexité que revient l’auteur. Il la définit comme suit :

Complexité = f(dev. environnement var. + target env. var.)

Toutes ces varaibles changeant par ailleurs au cours du projet.

Quand il compare Scrum aux procesus classiques, Ken Schwaber ne se contente pas de le comparer au cycle en cascade, déjà il met en évidence que la nature intrinsèque du modèle en spirale de Boehm est identique au cycle en V en cela que l’approche reste linéaire par essence ! Il pousse même ce raisonnement vers les processus itératifs dont il met en évidence qu’ils restent aussi « linéaires ». Une démarche qui reste incomprise de beaucoup plus de 20 ans après ! Car toutes ces méthodes sont basées sur l’illusion que le processus de développement peut être défini !

La méthodologie Scrum

Dans cet article, Ken Schwaber présente Scrum comme structuré en 3 phases

  • Planning et architecture système
  • Sprints
  • Clôture

Une structure que l’on ne retrouvera guère par la suite. Si la 1ère et la dernière sont des phases « définies », l’auteur qualifie la phase des sprints « d’empirique ». Notons aussi que l’auteur inclut dans la phase de clôture un « pré-release testing »… qui va à l’encontre du « potentially shippable » dont on parle aujourd’hui (et dont il ne parlait pas à l’époque) ! Par contre la durée des sprints est présentée simplement comme allant de 1 à 4 semaines, et non 30 jours (ou moins) ! Bref, comme on dit, c’était mieux avant !

A cette époque, on ne parle pas non plus encore « d’inspect and adapt » et donc encore moins de rétrospective !

Au niveau de la structure d’équipe, on ne reconnait guère la description actuelle : un management et des équipes de 3 à 6 personnes (donc l’équivalent de feature teams), responsables de sous-ensembles du backlog ! On ne parle pas encore de Product Owner.

Une emphase importante est mise sur l’utilisation des technologies objet, qui apportent la flexibilité nécessaire à une mise en oeuvre réussie de Scrum.

Les estimations se font en utilisant les points de fonction. Mais … Ken Schwaber met en garde sur la productivité qui est au moins le double du standard ! Sacré garnement !

Scrum an tant que processus

Dans cette partie, l’auteur rentre d’avantage dans la théorie des méthodes de développement, comment elles se définissent par le biais de métamodèles et en quoi il est important de reconnaitre si elles sont définies ou empiriques. Cela permet à l’auteur de revenir sur l’inadéquation des processus théoriques par rapport aux systèmes complexes sous un autre angle.

Et de conclure cet article !