SAFe n’est pas Agile. SAFe n’est même pas Scrum

Préface d’Agile Lounge

Nous publions ici la version française d’un article original en anglais publié ici par Mike Beedle sur le groupe Scrum Alliance de LinkedIN.  Agile Lounge a bien sur obtenu l’autorisation de Mike et nous en sommes très heureux.   À la fin du présent article traduit, nous irons de nos propres commentaires sur le Scaling des équipes Srcum  dans les grandes organisations.

S_Fe n’est pas Agile. S_Fe n’est même pas Scrum.

par Mike Beedle, co-auteur du Manifeste Agile.

Lorsque nous avons écrit le Manifeste Agile:
http://www.agilemanifesto.org

Nous avons déclaré que «les personnes et les interactions», «logiciels (ou solutions) fonctionnels», «collaboration client» et «réponse au changement» étaient importants.  Cependant, S_Fe ne met pas ces principes en avant et viole les valeurs du Manifeste Agile.

S_Fe ne se préoccupe pas des gens et des interactions entre eux – c’est plus un processus rigoureux et massif, vous voyez le topo!?  Cela ne met pas les personnes et les interactions en premier: il n’y a pas de base culturel de transformation des valeurs, il n’y a qu’un fond de processus avec des hiérarchies profondes.  Totalement anti-Agile.  Voilà pourquoi nous l’écrivons sans le «A» !

S_Fe ne nécessite pas d’intégration et de test tous les jours – même Sprint par Sprint; Ce n’est pas une architecture de subsomption.  Par conséquent, il encourage de la dette technologique et il est sujet à des problèmes systémiques comme les retards massifs, la construction de la “mauvaise chose” et le manque d’adaptabilité. S_Fe n’offre pas non plus de choix structurels ou temporels pour des architectures d’entreprise, des programmes avec ou sans logiciel, ou de grands produits / services, à fournir sur CDep, CDel, Sprint etc… Ce n’est que le choix du « delegated _RT» –  et une taille ne convient pas à tous!!!

S_Fe dit que le _RT, concerne les «flux de valeurs» au niveau du programme ou du portefeuille, mais nous savons que chaque équipe Scrum doit fournir une valeur commerciale pour se nommer Scrum.  Ah Ah!

Enfin, et probablement le plus important, S_Fe n’a pas suffisamment de mécanismes d’adaptation – pas même les fondamentaux de Scrum, à constamment “répondre aux changements” dans la véritable flexibilité pour des applications à réelles valeurs pour les utilisateurs. Si les affaires changent, les changements technologiques, les changements architecturaux, les changements d’équipe viennent au milieu d’un _RT, vous vous briserez le cou!

Ne soyez pas dupé – S_Fe n’est pas Agile. S_Fe n’est même pas Scrum. Il existe de nombreux autres meilleurs choix.

La Réflexion d’Agile Lounge

Voilà!  Vlan dans les dents de celles et ceux qui croient, avec S_Fe,  faire de la transformation culturelle de la manière de travailler en Agile en adoptant des «systèmes lourds» et déviant de la mission Agile et de l’efficacité Scrum.

Tout comme Mike, nous croyons en une véritable flexibilité tout en renforçant les valeurs de l’Agilité et des méthodes efficientes amenant de la réelle valeur aux produits, aux entreprises et surtout aux clients et utilisateurs!

Dans nos nombreux mandats réussis chez Agile Lounge et ses partenaires, les regroupements dans la grande entreprise qui ont bien fonctionné utilisaient des «Scaling» tel LeSS ou encore mieux le flexible SoS (Scrum of Scrum) unissant la force de plusieurs ScrumMasters et Product Owners partageant une véritable vision de programme ou de portfolio de produits ou services.    L’interaction entre les équipes Scrum étaient aussi saine et libre que dans les équipes dédiées elles-mêmes.

Notre équipe de Coachs Loungers Agile trouvaient important de mettre de l’avant ce billet de Mike dans la langue de Molière afin de contribuer au débat le plus largement possible et de mettre la table de notre nouvelle marque Agile Lounge™ avec la philosophie de l’Agilité que nous partageons dans la communauté.

S_Fe se faux rassurant face au changement!

S_Fe semble, sur Montréal en tout cas et malheureusement dans bien trop de grands centres d’innovation technologique nord-américain, devenir le «SAFE-garde» sécurisant des décideurs d’affaires qui ont peur de «La transformation du mode de travail» et de l’autogestion des équipes qui produisent la valeur ajoutée et réelle des produits à livrer aux commerciaux et surtour aux humaines les utilisant (User fisrt & #H2H).

Arrêtez d’avoir peur et de faire peur.  Aimer ce que vous faites et partagez le.

Ce genre de «framework» dilue la philosophie et la culture à la base d’Agile ce qui la rend FR_Agile!  De plus, tout ne devient que Buzzword A-G-I-L-E et Scrum et on s’invente des histoires pour justifier inefficacité de ce que nous appelons les «succès manqués» face à cette résistance sournoise à ces valeurs importantes d’évolution tant technologique qu’humaine que sont :  «les personnes et les interactions», «logiciels et solutions fonctionnels» et la «collaboration client»

Tiens!  parlant d’interaction et de transformation, participez vous aussi au débat d’idée sur la notion de «regroupement», programme ou multi-usage de portfolio en Scrum avec des valeurs Agile.     Continuez la conversation ici !

Share:

Recent Posts

Send us your comment

Inscrivez-vous pour être à l'affût!

Subscribe to be notified!

INSCRIVEZ-VOUS / SUBSCRIBE  
​Vos informations ne seront jamais partagées
Your information will never be shared


 
close-link

Ask Us for a Custom Workshop

Subscribe our Value List