Toltèque Agile

SAFe : trois points de vigilance

25 novembre 2017

SAFe, de par sa portée, accentue les risques de faux-agile bien souvent résultat  constaté d'une mise en oeuvre inconsidérée  au niveau d'une équipe.

Je voudrais partager avec vous mes trois points de vigilance à propos d'un voyage agile (certains parlent de transition ou transformation), avec ou sans échelle.

Bien entendu, ce périple vers plus d'agile, suppose d''autres attentions : donner du sens par une vision, expliquer par un déclencheur, etc.

 

Cet article fait suite à Même sans échelle, SAFe agilise votre Scrum.

 

Trois collèges

Quelle que soit la méthode, le ou les niveaux considérés, un cadre agile se construit à partir de trois collèges ou catégories d'activités et de responsabilités. Afin de m'exempter de tel ou tel référentiel (XP, Scrum...) je nomme ces collèges :

Besoin (représenté par le Client dans XP, le Product Owner dans Scrum...)

Solution (typiquement les Développeurs)

Soutien (Managers, ScrumMaster dans Scrum, Big Boss et Coach dans XP...).

 

En ce qui concerne SAFe, vous constatez que ces trois collèges existent à tous les niveaux :

Portfolio : Epic Owner, Enterprise Architect, Lean Portfolio Management

Program : Product Management, System Architect, RTE

etc.

 

Autre chose : contrairement à ce qui est parfois "colporté", un cadre agile n'est pas un cadre de management. Dans cet ordre d'idée, le rôle de ScrumMaster dans Scrum est décrit dans sa partie directement liée au développement de produit (par exemple : supprimer les obstacles) et ne décrit pas d'autres aspects (gestion de ressources matérielles...).

Je crois d'ailleurs que SAFe, en proposant le collège LeanPortfolioManagement, va beaucoup plus loin dans cette description.

 

Voici donc ces trois points d'attention qui, vous l'aurez compris, sont spécifiques à chacun des trois collèges.

 

Vigilance collège Besoin

Des années de planification par les activités, dans un cycle one-shot qui l'autorise, créent un biais cognitif dont il faut mesurer l'impact : même avec des stories, les heuristiques de planification peuvent rester centrés 'techno" et pas valeur. C'est un point d'attention important : ce n'est pas parce que le PO gère un backlog de stories qu'il planifie en agile. D'ailleurs à ce sujet, je vous suggère de lire Planification agile sur ce site. Attention aux itérations de "socle technique" et autre "conception de base de données". Un indicateur intéressant est tout simplement la valeur obtenue à la fin d'un itération, cumul des points de valeur des stories terminées, tout comme la vélocité est le cumul des points d'effort.

 

Cela est vrai pour  Scrum au niveau d'une équipe (ou d'une tribu dans SAFe). Si vous pratiquez vraiment SAFe, vous savez qu'il ne s'agit pas de Scrum mais de ScrumXP.  Et si vous savez ce qu'est vraiment XP, cela ne devrait poser aucun problème : le concept de story, apparu dans XP au tout début des années 2000, impose un attribut qui est la valeur de la story.

La planification dont je m'inspire dans l'article dito est une petite adaptation du Planning Game de l'Extreme Programming. Ci-dessous un extrait de "Planning Extreme Programming" co-signé par Kent Beck et Martin Fowler  (Oh... Mes Mentors !) en 2001.

 

 

 

Aujourd’hui, je rajoute le respect des personnes comme 5ème variable (respect du temps de travail, de leur avis comme dans Stop the Line de Lean...). Simple constat.


Vigilance Collège Solution

Le changement vers l'agile "pique les yeux".

L'agile au niveau d'un produit malléable comme le logiciel suppose une conception émergente (voir les principes du Manifeste agile). Cela se traduit par les pratiques qui perdurent comme définition de l'Extreme Programming (largement réductrice...) dans l’inconscient collectif de la communauté agile.

Concrètement un trio inséparable :

  • conception simple (type KISS pour ceux qui connaissent ou YAGNI...)
  • Test Driven Development, que l'on pourrait traduire par "développement d'un code propre piloté par une conception émergente exprimée en tests progressifs"
  • Refactoring (il existe un refactoring "avant" pour adapter un code et un refactoring "après" pour le nettoyer, ce qui est une étape du TDD).

 

Tout cela est bien joli (si si, je l'ai pratiqué !). Mais il faut un pré-requis : dans ma tête  de Développeur, je crois que le code est un produit plastique, modifiable et je joue avec parce que c'est maintenant possible (machines performantes, environnements de dev qui offrent une analyse syntaxique, voire sémantique, en "live"...). Ce n'était pas le cas lors de mes premiers développements... en cartes perforées (et oui, j'ai grandi avec Stone et Charden, Marcel Amont... les Rolling Stones, Kiss...).

 

Pour être honnête, ce n'est pas simplement une question de Développeur. Vous voyez que c'est lié au Planning Game : arrêtons d'utiliser la qualité, je parle d'ailleurs de dette technique pour être moins ambigu, comme variable d'ajustement.

Il reste que ce n'est pas du tout facile pour un Développeur de passer de la grosse conception du début à la conception émergente. Et à ce sujet, je vous suggère la lecture de ce billet : conception agile : où en sommes-nous  ?

 

Vigilance collège Soutien

Les Managers... Ce collège ne laisse pas indifférent !

Ce rôle existe pourtant dès le début : c'est par exemple le Project Manager dans l'Extreme Programming ou le Big Boss qui correspond plus à l'image que l'on se fait du soutien agile.

C'est le 5ème principe  du Manifeste déjà cité.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.


Dans une organisation hiérarchisée,  de grande ou petite taille, le poids du Management est important : c'est lui qui donne le "la". C'est donc ici que SAFe est plus "risqué" que Scrum (quoique...).

Disons brièvement qu'il s'agit d'abandonner le mode "command & control".

Nous parlons de Manager Coach : comment aider l'équipe sans solutionner le problème. D'où des pratiques qui fleurissent dans la communauté agile, telle que Solution Focus de bon aloi.

Notez aussi que le Manager, et cela a le mérite d'être explicite dans SAFe avec le LeanPortfolioManagement déjà cité, est aussi "partie prenante" : il alloue un budget par exemple. Arrêtons donc de laisser à penser qu'un Manager est inutile ou n'est que dans un rôle de soutien "new age" genre

- j'amène les chocolatines demain.

[ oui, on dit chocolatine, pas pain au chocolat, en tout cas dans mon pays :) ]


Vigilance à l'échelle

Cela s'applique à tous les niveaux de SAFe et il s'agit donc de  moduler la vigilance en fonction de ce niveau.

Si je reprend le collège Solution au  niveau Portfolio, porté donc par le rôle d'Enterprise Architect, la mission est entr'autres de

  • promouvoir DevOps
  • Influencer les pratiques de développement dans le sens de Built-in Quality
  • ...

C'est un exemple de vigilance parmi bien d'autres : s'assurer que le Clean Code est bien une préoccupation au niveau Portfolio.

 

En conclusion...

Tout cela est quand même question de mindset. Je vous invite à

  1. télécharger les diapos de ma prez "Carte boussole et territoire" centrée plutôt sur le Management, elle concerne en fait tous les collèges ;
  2. pourquoi pas envisager la lecture de Managez agile :) ?

 

Voila...

J'espère avoir été un peu plus clair. Il ne s'agit pas d'appliquer SAFe en mode "bourrin". Il s'agit de co-construire une agilité à l'échelle, aujourd'hui demandée par les Clients, en s'inspirant de SAFe, sans ré-inventer l'eau chaude.

Il serait appréciable que les Formateurs à SAFe prennent connaissance de ce qu'est l'agile, son histoire depuis les débuts avec l'Extreme Programming. Et décrivent beaucoup plus précisément ScrumXP (XP) dans la partie "Team".

 

C'est pour cela que j'aime bien SAFe : j'y retrouve le même souffle que dans XP.

Avec ce nouveau saut quantique qui est le passage à l'échelle, en s'appuyant (comme XP) sur ce beau corpus qu'est le Lean.


Et avec un Business Model performant comme celui de Scrum, ce qui le rend audible.

Contrairement à l'Extreme Programming.

 

 

 

 

 

He Wishes for the Cloths of Heaven


 Had I the heavens' embroidered cloths,

Enwrought with the golden and silver light,

The blue and the dim and the dark cloths
Of night and light and half-light,
I would spread the cloths under your feet
But I, being poor, have only my dreams;
I have spread my dreams beneath your feet;
Tread softly because you tread on my dreams...
William Butler Yeats

Marche doucement car tu marches sur mes rêves.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
Formation "Manager agile : concrètement" 13 14 mars 2018 Toulouse Même sans échelle, SAFe agilise votre Scrum