Table
Avant-Propos
Craig est canadien. Il est très agréable à écouter car il parle un anglais très compréhensible tant sur le rythme que sur le vocabulaire choisi.
Pendant sa présence à Paris, il donne le premier cours de certification LeSS au monde. Après avoir incité la Scrum Alliance à un programme sur l’Agile à grande échelle, le récent ajout de certification dans la Scrum Alliance correspond à cette certification LeSS.
Durant son intervention, il a peu présenté le framework LeSS mais d’avantages les causes profondes (root causes) qui empêche d’être réellement Agile.
Les cause profondes
Le Contract Game
Pour illustrer son propos, Craig a utilisé les spectateurs pour mettre en scène une structure hiérarchique typique dont les fondements expliquent les difficultés rencontrées en Agile. Prenons un client interne qui demande un projet informatique. Il s’adresse au manager informatique qui se retourne vers un chef de programme qui lui-même encadre un chef de projet gérant un chef d’équipe et des développeurs.
Régulièrement, ils font des bilans d’avancement. La loi de la hiérarchie implique nécessairement une déformation du message au fur et à mesure qu’il remonte dans la hiérarchie. Les difficultés sont cachées ou amoindries car chacun a un objectif financier personnel à faire avancer le projet. Le moindre son de cloche négatif et c’est la prime qui saute, si ce n’est pas le licenciement.
Dans la dernière ligne droite, le projet va prendre des raccourcis catastrophiques pour tenir des délais acceptables (pas trop de retard), générant non seulement une dette technique mais aussi une dette d’organisation. La dette d’organisation, ce sont les démotivations des personnels, voire le départ des meilleurs.
L’humour
Au passage, Craig mentionne le PMI, qu’il appelle le Project Magic Institute. Formé à cette école, le chef de projet utilise des incantations magiques lors de cérémonies. Parmi ses outils magiques, on retrouve le diagramme de planification (tellement utilisé qu’on le nomme comme l’outil d’un éditeur très célèbre) ainsi que les réunions d’avancement (appelées Status Meeting).
Conséquences du Contract Game
Comme le Contract Game est institutionnalisé (avec sa gouvernance et ses PMOs), c’est une des causes profondes du dysfonctionnement du système.
Pour Craig, la gestion de projet informatique repose sur un faux axiome : le logiciel est un domaine de faible variabilité comme l’industrie.
Si on n’élimine pas le rôle de chef de projet, on ne fera toujours qu’un semblant de Scrum. Scrum en soi est une élimination complète du Contract Game.
Les lois de Larman sur l’organisation
Craig énonce ainsi les différents lois qu’il a édictées :
- Les organisations sont implicitement optimisées pour maintenir le statu quo des managers et des spécialistes.
- Comme un corollaire de 1, la nouvelle terminologie due à l’initiative de changement sera redéfinie pour maintenir le statu quo.
- Également comme un corollaire de 1, l’initiative de changement sera critiquée et moquée comme puriste, théorique, académique et nécessitant une adaptation pragmatique aux moyens locaux.
- La culture suit la structure.
Les changements n’apparaissent que lorsqu’on challenge le statu quo des managers et spécialistes en place.
L’organisation, la structure : équipes composants ou équipes fonctionnalités ?
Une autre cause profonde est le modèle d’organisation en équipe de composants qui implique plusieurs travers.
Entre chaque composant, il faut définir des interfaces. On a donc recourt à des analystes métier pour découper les fonctionnalités selon les composants.
Le rythme de chaque équipe étant différent, les différents composants d’une fonctionnalité sont développés à des moments différents. Ainsi, la réalisation d’une fonctionnalité complète prend beaucoup de temps, noyant complètement la réalisation et sa démonstration.
En attendant la complète disponibilité, les équipes sont amenées à créer des branches. Or chacun sait que les branches sont le chemin vers l’enfer !
Avec ce modèle, on ne trie pas les fonctionnalités par la valeur métier, mais de façon à maintenir les équipes occupées. Avec une telle structure, la nomination d’un chef d’équipe demande de lui maintenir une équipe consistante et donc une activité appropriée. Même si une équipe n’a pas de raison de travailler, elle continue de produire des lignes de code. La taille du code s’accroît ainsi sans que ce soit nécessaire.
Dans certains domaines, le mot d’ordre lors d’une revue de code est de chercher systématiquement si on peut supprimer chaque ligne de code.
Les recherches montrent que ce modèle génère le plus de coût. A l’inverse, des recherches datant de 1978-82 montrent aussi que les les équipes cross-fonctionnelles coutent moins. C’est d’ailleurs l’origine du fameux article de Takeuchi et Nonaka (1).
La mise en place de LeSS
La nouvelle organisation
L’adoption de LeSS commence donc par remettre à plat la structure de l’organisation appuyé par le top manager (CEO).
En Scrum, il n’y a pas de groupes d’architectes, de testeurs ou autres. Une équipe Scrum est cross-fonctionnelle. Elle n’est pas composée seulement de programmeurs et de testeurs, elle contient aussi des architectes, des DBA, des UX/UI, …
Chez Toyota, la mise en place du Lean s’est accompagnée d’un principe fondamental : la sécurité de l’emploi et la sécurité des salaires. Cela fait partie de leur culture.
Mais attention, la sécurité de l’emploi n’est pas la sécurité du poste (message chez Toyota). Il faut nécessairement qu’il y ait une perte de pouvoir pour augmenter l’auto-management et l’auto-organisation.
L’organisation doit être volontaire pour cet auto-management.
Il suffit d’une à deux heures pour réorganiser les équipes. Dans une première itérations, les personnes se réunissent en équipe. La seconde itération sert à ajuster selon les compétences nécessaires dans l’équipe. Ensuite, l’équipe se choisit un Scrum Master parmi le pool de Scrum Masters disponibles. On peut ensuite se poser des questions sur les qualités de ceux qui restent à la fin 😉 Un Scrum Master s’occupera de 3 équipes au maximum.
Les points d’attention
Pour que cette transformation perdure, il est nécessaire de créer des communautés de pratiques (2) pour chaque compétence : architecture, tests, UX, … Ces communautés sont informelles et non structurelles. Un gardien, tout aussi membre d’une équipe, veille à la bonne tenue des travaux de sa communauté. Chaque communauté traitera des sujets comme la standardisation des pratiques, la formation, les designs spéculatifs. Mais attention, si ces communautés identifient le travail, ce ne sont pas elles, comme structure, qui l’effectuent !
(1) The New New Product Development Game, par Hirotaka Takeuchi et Ikujiro Nonaka. Cet article introduit le terme Scrum dont se serviront Schwaber et Sutherland pour leur fameuse méthode.