Scaled Agile Framework - vos RETEX ?

[Deconfine82]

bon, je ne savais pas trop où lancer ce sujet, Divers, ça devrait le faire , même si c'est pas vraiment  la saison.

Mon entreprise ( informatique secteur parapublic dans le monde de la sécu, 1000 personnes)  après quelques expérimentations agiles limitées et localisées (scrum, kanban) , est partie pour opérer une mutation globale vers l'agilité à l'échelle  (cible 2025) en s'appuyant sur le framework SAFe (r) .Je sors juste d'une formation leading SAFe(r) ,  (je précise que je n'avais pas du tout  le grade adapté à cette formation orientée encadrement stratégique à la limite opérationnel, c'est plutôt celles concernant la Developpement Team ou à la limite les Scrum Master ou Product Owner qui auraient plus été adaptées ).

Je sais que cette méthode est assez en vogue  en France (pas seulement pour les DSI (informatique) d'ailleurs. Il semble d'ailleurs qu'il s'agisse de la méthode agile qui a eu récemment le plus les faveurs de nos décideurs.

je me demandais donc s'il n'y avait pas quelques forumeurs qui pourraient avoir de l'expérience sur le sujet, connaitre leurs vécus de terrain voire leurs retours d'expérience pour les plus avancés.

vous pouvez évidemment déborder sur toutes les autres méthodes ou approches agiles et cela que ce soient dans l'informatique, l'ingénierie, l'industrie, ou toutes autres activités.

merci d'avance

ps: coachs agiles s'abstenir

Modifié le 14 juillet 2020 par Deconfine82

[Boule75]

Il y a 2 heures, Deconfine82 a dit :

je me demandais donc s'il n'y avait pas quelques forumeurs qui pourraient avoir de l'expérience sur le sujet, connaitre leurs vécus de terrain voire leurs retours d'expérience pour les plus avancés.

vous pouvez évidemment déborder sur toutes les autres méthodes ou approches agiles et cela que ce soient dans l'informatique, l'ingénierie, l'industrie, ou toutes autres activités.

Ca suppose de la rigueur, rigueur bien rare parmi les cadres sup dans le monde de l'informatique : ne pas confondre "agilité" et "ah bah on peut changer les priorités quand on veut, alors ??" ou encore "on va tester toutes les nouveautés tout le temps et être hyper au top des versions de tous les machins à la mode avec le bling bling qui brille !"

Ca ne permet pas d'ignorer une vision moyen terme sur les projets : si les objectifs fonctionnels généraux sont mal définis, mal compris, mal conçus, si l'architecture globale des projets est moisie, l'agilité ne sauve pas.

 

Donc ça a l'air bien mais pas magique pour le dev.
Par contre, dès que les cycles de réalisation ou de mise en place s'allongent, les itérations courtes sont souvent inopérantes : sur les couches basses typiquement, quand il faut faire avec des circuits d'approvisionnement/déploiement de matériels peu agiles par exemple, ou s'il faut composer avec des équipes sous-dimensionnées auxquelles on demandera de monter "rapidement" en compétences sur des nouvelles technos complexes, avec en prime de fortes attentes de fiabilité et de services connexes. On peut bien sauter en l'air tant qu'on veut en disant agile agile agile ! ça ne change pas grand chose.

Si au moins ça fournit des outils communs à tous et un moyen de présentation des dépendances et travaux unifié et utilisable par tous, c'est déjà ça de pris.

[jean-françois]

De mon expérience, ça se résume souvent à ce que les développeurs comprennent :

"c'est open bar. Ce n'est pas grave si on fait de la merde qui en fonctionne pas, ça sera corrigé à la prochaine itération."

En fait, comme le dit Boule, il faut que ça soit piloté par des chefs de projet trés expérimentés qui sauront gérer proprement chaque itération avec un suivi à la culotte des développeurs.

Ce n''est donc pas une solution miracle ( comme certains voudraient le faire croire ), mais une façon différente de travailler utile dans certains cas, mais ne pouvant pas être généralisé.

[hadriel]

De ma (courte) expérience de SAFE, ça marche bien pour planifier et exécuter à l'horizon de 3 mois (les PI/program increments), au-delà c'est le flou total et il faut utiliser d'autres outils en parallèle. J'aurais tendance à dire que pour vraiment que ça marche bien il faut:

- que tout le monde ou presque soit très polyvalent, ça s’accommode pas hyper bien des petits viviers de compétences très spécialisés

- qu'il y ait un vrai contact avec l'utilisateur (ie version quasi utilisable à tester tous les 3 mois ou moins)

- que du côté de la direction de projet/stratégie commerciale, les décisions se prennent dans une échelle de temps cohérente avec le développement. Si il faut 6 mois pour renégocier un contrat ou raffiner la stratégie commerciale, ça va poser problème.

 Globalement comme toute méthode de conduite de programme, faut pas s'attendre à que ça résolve tous les problèmes. Ca dispense pas d'être intelligent et de devoir parfois rentrer dans le lard quand s'établissent des équilibres négatifs pour l'efficacité globale.

[Deconfine82]

merci à vous pour votre participation. je ne vous connais pas assez pour savoir dans quel domaine vous évoluez. mais bon apparemment, vos avis confortent mes premiers ressenties sur cette mise à l'échelle de l'agilité.

j'ai fait quelques recherches sur le net, et apparemment les directions qui se lancent dans SAFe entendent bien souvent avant tout obtenir une resynchronisation des équipes et des projets ("recadrer" l'agilité)  et la mise en place  "d'une diffusion globale en continue" avec des cycles de livraisons maitrisables (Program Increment de 3 mois environs) .

Chez nous, je crois que c'est aussi le moyen de remettre à plat tous les managements stratégiques et opérationnels suite à la fusion récente dans la même entreprise des maitrises d'ouvrages, de la maitrise d'œuvre, et de la production .

  Pendant 12 ans, on a hyperspécialisé les profils, souvent pour créer des avancements de carrière, ou pouvoir recruter plus haut dans la grille pour rattraper artificiellement les salaires du marché. Mais  dorénavant  tout le monde doit être polyvalent, et le "grade" apparemment deviendrait anecdotique (à part sur la fiche de paye ) on parle juste de fonction et des nouveaux rôles SAFe .

Pour la méthode, bon chez nous, on est mal d'entrée, car déterminer par produit qui sont nos clients  est déjà souvent un case tête ou des vues de l'esprit  

après je ne sais pas chez vous, avec des méthode en V locale, on a grosso modo "planté"  ( débouché au mieux partiellement aux forceps, hors délai et hors budget etc)  tous nos gros projets des 15 dernières années, en particulier les refontes avec une expertise reconnu dans les tunnels à rallonge .

donc il faut s'attendre à un retour de balancier sur les méthodes mais pas forcément de meilleurs résultats