Less is more avec Craig Larman
En préambule d’une formation LESS (j’y reviendrais bientôt), Greg Hutchings nous a permis d’assister à une présentation dans le cadre du Scrum User Group. Une présentation autour de LESS, bien entendu. De mon point de vue, une présentation de Craig Larman, ça vaut toujours le détour: ses talents d’orateur ne sont plus à démontrer et même si vous n'adhérez pas à la totalité de son propos, vous êtes sûr de repartir avec de nouvelles connaissances, des idées et surtout de quoi reflechir !
Avant même d'aborder le thème même de la présentation et après la traditionnelle histoire drôle qui ouvre toujours ses présentations, Craig campe l'ambiance : je ne suis pas intéressé par vos opinions ! Je ne suis d'ailleurs pas non plus intéressé par MES opinions. Ce qui compte, ce sont les faits. Même les études de cas sont insuffisantes. Ce qui compte, ce sont les études menées de manière scientifiques sont des échantillons statistiquement signifiants et publiés dans des journaux à comités de lecture. Une approche scientifique sur laquelle l'orateur se revendique de Thomas Kuhn.
Continue Reading
Pour lui, nous sommes à l'âge de l'obscurantisme du management, où les croyances prédominent sur les faits. Où une plus grande attention aux recherches académiques devrait être portée, alors que 50 ans de recherche en management sont simplement ignorées. Alors, laissons tomber les opinions personnelles.
Le "Scrum fake" : à la recherche des causes racines (1ère partie)
Le constat premier de Craig Larman rejoint le mien : il y a de plus en plus de "Scrum Fake" dans les mises en place de Scrum aujourd'hui. Le co-auteur de LESS y voir 2 causes racines. Des causes racines qu'il faut activement adresser, car si notre transition agile ne les adressent pas, celle-ci pourrait faire plus de mal (la déstabilisation liée au changement) que de bien (la mise en place d'un véritable environnement agile).
Cette première cause racine a un nom : le "contract game". C'est à dire le jeu autour du contrat auquel se livrent les équipes de développement d'une part et le client (au sens client interne) d'autre part. Oui, on parle bien d'un contrat "virtuel" interne et non d'un contrat légal avec un client externe. Pourtant le fond reste le même.
La première partie du projet, celle où se joue l'établissement de ce contrat, est le théâtre d'un duel où le business demande "plus, plus, plus" et où l'équipe de développement réponds "moins, moins, moins". Il y a ce combat, car chacun sait qu'au moment où celui-ci sera ficelé, le jeu changera :
Le business n'a plus la main, elle passe au développement qui devient seul maitre.
Le business lui-même ne veut pas être inclus dans le jeu du développement.
Ce contrat est basé sur l'illusion de la faible variabilité. Une illusion dont on sait qu'elle est fausse depuis de nombreuses décennies.
On dit d'un d'un contrat qu'il est aboutit quand les deux parties sont mécontentes de manière équilibrée. Au fait, quel est son rôle au contrat ? Ce n'est pas de permettre la réussite du projet mais de permettre de blâmer l'autre partie en cas d'échec !
Donc on s'engage dans une longue phase de réalisation où le chef de projet fait le lien avec le business. Craig nous parle des outils du PMI (qu'il appelle le Project Magic Intitute) concernant la relation entre le chef de projet et le client :
Comment le chef de projet assure le client de la réussite : en déclarant « je m’engage ! » ; une approche dont on sait depuis longtemps qu’elle ne marche pas !
Comme dans toute magie, on utilise des symboles ésotériques : ici, on les appellent « diagrammes de Gantt » … en fait une illusion de contrôle !
Enfin les managers pilotant ces projets à plusieurs niveaux hiérarchiques de distance transmettent des rapports d’avancements faussement optimistes au grée des remontées d’information entre niveaux hiérarchiques ! Un phénomène appelé « greenshifting ».
Tout cela se paie à la fin du projet : les blâmes sont rejetés entre les acteurs du projet, le périmètre est bâclé en toute urgence pour se débarrasser du projet en sacrifiant la moindre parcelle de qualité. Enfin, le tout se conclut en « dette managériale » : les bons managers et les bons développeurs quittent la structure !
Larman explicite ces fonctionnements par ce qu’il appelle en toute modestie les « lois de Larman » !
1 - Les organisations sont sont implicitement optimisées pour maintenir le statut quo du pouvoir des managers de proximité et des spécialistes
2 - Corollaire de la première loi, toute initiative de changement sera réduite à des changements d’appellation maintenant ce statut quo.
3 - Second corollaire de la première loi, les initiatives de changement seront tournées en dérision, puis qualifiées de « puristes », « théoriques » ou « révolutionnaires », puis « nécessitant des adaptations pragmatiques pour customiser pour l’organisation », menant au statut quo managers / spécialistes.
4 - La culture se calque sur la structure : les plans de carrière favorisent la spécialisation. Changer la culture en tant que tel n’est pas possible.
La seconde cause : le découpage par fonction
Le découpage « orienté composants » présente de graves lacunes :
Du « code privé » : au contraire d’augmenter la qualité, ces groupes créent une complexité artificielle qu’ils ne sont plus capables de voir au bout d’un certain temps !
Les fonctionnalités à délivrer traversent les composants. Mais comme elles deviennent subordonnées aux planning locaux, elles mettent très longtemps à être livrées. Donc un cycle de feedback qui va de même.
Les fonctionnalités étant l’assemblage de fonctionnalités implémentées dans les divers composants, les tests de bout en bout ne peuvent avoir lieu qu’une fois l’ensemble complété. Notre cycle de développement est en fait séquentiel à ce stade. Il subit le syndrome du « hands of » typique du cycle en cascade.
Ce « hands of » n’est pas seulement en aval, il est aussi effectif en amont: chaque fonctionnalité demandée doit être ventilée en éléments de réalisation, il est donc nécessaire d’avoir des analystes effectuant ce découpage au préalable du développement !
Le staffing étant effectué par composant, l’occupation générée par ls demandes n’est pas nécessairement en ligne avec cette disposition de ressources. La priorisation des fonctionnalités finit donc par être dirigée par l’occupation des équipes, plutôt que par les priorités métier !
Hélas, le « découpage par composants » a des airs bien trop familiers pour moi. La démonstration de Craig est plutôt édifiante !
Le point de départ de la reflexion de LESS vient de l’expérience de RUP (j’y ai participé chez Valtech, à la fin des années 90). Les deux grands défauts de RUP, que je partage avec l’orateur, étaient :
Un niveau de détail bien trop grand. Personnellement, je traduis celà comme une rémanence d'une vision Tayloriste du travail .
Un manque de contextualisation.
Le framework LESS est guidé par plusieurs principes :
Celui des organisations apprenantes, en s’inspirant du Shu Ha Ri. Ainsi plutôt que le ras-de-marée de détails, LESS propose des principes et juste « un peu moins que nécessaire » d’éléments de processus. Il se revendique en cela dans la lignée de Scrum.
Une organisation en « feature teams » plutôt qu’en composants. Comme c’est le cas chez Spotify.
Une « serious change initiative » destinée à bouleverser l’organisation et les titres de postes ! LESS se revendique d’inspiration Lean ici : La préservation des emplois ne signifie pas la préservation des rôles !
Pour démarrer tout cela, Larman débute une réorganisation LESS avec 2 points de rencontre très importants :
L’informed consent meeting. C’est un meeting de 2 à 3 jours avec Craig, avec tous les exécutifs ! S’ils ne peuvent y consacrer ce temps, c’est qu’ils ne sont pas sérieux sur leur volonté de changement ! D’après l’orateur, la plupart des organisation n’en valent pas le coup ! Hum...
Une fois le changement décidé, il y a le « flip », qui dure 2 heures. C’est le Design Team Meeting. Il s’agit d’une grande place de marché où les équipes s’auto-forment en s’appuyant sur une « check list ». Cela nécessite parfois plusieurs tours. Une fois cela fait, les équipes embauchent… leur Scrum Master ! Puis… leurs managers !
Il y a de nombreux éléments spécifiques à LESS, comme la façon de gérer les planning meetings, les démos et les sprints synchronisés. Par ailleurs, pour donner de la cohérence à l’ensemble des travaux menés par des features teams indépendantes, il faut des communautés de pratiques: certaines sont requises, d’autres informelles.
Tout d’abord, Craig Larman est un orateur hors pair. Non seulement sa diction est claire, mais son jeu de scène est vivant, son propos est intéressant et souvent pertinent. L’approche de changement des organisations de Larman me semble par ailleurs brutale : le RAZ sans tenir compte de l’existant ou du contexte, avec le dogme que l'organisation LESS est de toute façon la bonne. Pour Olaf Levitz, cela démontre un manque de respect. Je le rejoins sur ce point.
Les pré-requis au passage à LESS sont très importants car Craig Larman n’accepte aucun compromis. De fait peu d’entreprises acceptent un tel changement, mais doit-on dire de fait que les autres ne « valent pas le coup » ? Je ne suis pas non plus l’auteur sur ce point.
LESS est résolument d’inspiration Scrum par sa légèreté. Au contraire de SAFe que je trouve sujet à caution, la fibre agile de ce process me semble réelle. Mais je reste dubitatif sur le concept même et sur la motivation du scaling, quel que soit la dose d’intelligence qui y est mise (ce qui est bien le cas ici). L’idée de « scaler » me semble une réminiscence d’un ancien mode de pensée qui vient infecter le nouveau. Je pense que l’enseignement de l’agilité est différent...
Vous pourrez retrouver quelques éléments de la prose de Craig dans l’interview suivant. Un livre sur le sujet est à venir cette année, mais on trouve déjà une majorité du matériel dans les deux livres co-écrits avec Bas Vodde, dont celui-ci.
