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.

Lire la suite

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 :

Lire la suite

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

Lire la suite

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.

Lire la suite

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.

Lire la suite

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 !

C++ en 1983…

J’ai posté il y a peu une note de lecture sur l’Annotated Reference Manual (l’ARM pour les intimes). Cela m’a incité à aller chercher plus loin. C’est ainsi que j’ai mis la main sur un document dont on devine à sa seule apparence qu’il est plutôt ancien. Je ne peux résister au plaisir, en passant, de vous livrer la photo de famille du premier meeting du groupe de travail sur C++.

Initial meeting Group C++

Bjarne Stroustrup n’a pas tellement changé, vous allez le reconnaitre facilement !

Voici le document en question.

On ne peut pas vraiment parler de norme, ce document décrit le langage C++ d’une manière que l’on dirait aujourd’hui sommaire. Certains éléments du langage sont absent de cette version préhistorique. Les plus remarquables sont l’absence des mots-clé pour les visibilités private et protected !