Sure et Sauf: AgilePM et SAFe

AgilePM est une démarche de « management de projets agiles créée afin d’offrir aux chefs de projet une approche rodée, évolutive, et adaptée à l’échelle de l’entreprise ».  SAFe (Scaled Agile Framework) est présentée comme une « base de connaissances interactive pour la mise en œuvre des pratiques agiles à l’échelle de l'entreprise ».  Quelle est la distinction la plus importante entre ces deux approches ?

 

Pour moi, la prochaine question essentielle pour les démarches  agiles, de tout genre, consiste à impliquer la direction pour des projets de grande importance stratégique, à savoir les projets qui auront un impact significatif sur l'avenir de l'organisation. D'après mon expérience, les décisions stratégiques dans des projets agiles sont prises chaque jour sur les sujets concernant les technologies et les clients, alors que, malheureusement, les cadres supérieurs se tiennent en dehors du processus.

 

Ainsi, les équipes sont "au pouvoir",  en principe (car souvent sans pouvoir budgétaire), mais cela ne signifie pas que « la hiérarchie » doit être absente.  À mon avis, dans un projet hautement stratégique, les directeurs doivent se rendre disponibles lorsque la situation l'exige, et même en pleine «timebox » (en principe,  un« sprint » ne permet pas cela).

 

La philosophie de SAFe exprimée dans les «41 choses que vous devez savoir» évoque l’idée « d’une stratégie centralisée» avec «une exécution locale.  Mais, comment alors la direction peut-elle participer à «l'exécution locale » ?  Réfléchissez comment une personne telle que Jobs, Gates, Dyson, Bezos ou Chanel participerait à des projets stratégiques.  Donnez de l'espace à l’équipe, mais mettez-vous à leur disposition le cas échéant, leur donnez du courage et encouragez les membres de l'équipe en cas de besoin. (Ne pas les étouffez, mais leur donnez de l'oxygène.)

 

Scrum décrit le rôle d'un «Product Owner» et SAFe esquisse les grandes lignes du rôle de «Product Manager ».  Toutefois, ces rôles sont souvent délégués à un niveau plus bas que la prise de décision stratégique.  Compte tenu de l'importance des décisions qui seront prises au cours du cycle de vie souvent mouvementé d'un projet agile, la gouvernance d'un projet «stratégique» devrait être située au niveau du conseil d’entreprise.  Combien de «chefs de produit» siègent au conseil d'administration?

 

J’ose identifier dans AgilePM / DSDM de l’APMG des ingrédients pour une présence renforcée de la direction : au sein du « rôle de visionnaire » et les conseils pour l'utilisation d’un « business case », et dans le détail des « Stage Gates » de Robert Cooper (des « portes avec des dents ») la participation des équipes dans les jalons, et dans des oeuvres de conception et de développement de produits,  tels que dans approche d'ingénierie stratégique d’Ulrich et Eppinger via le «livre de contrat», et «design thinking» en général, et dans le BABOK de l'IIBA.  Je ne le vois pas explicitement dans Lean pour la production, mais en Lean Start-Up d'Eric Ries, via les «pivots» et les «indicateurs réalisables».  On le voit aussi dans la gestion des parties prenantes dans le PMBOK v5 de PMI et dans la structure de rapports d'exception de PRINCE2 de l'APMG, et dans le rôle de «Sponsor» agissant en tant que «Champion Exécutif», présent dans toutes les approches susmentionnées.

 

Pour moi AgilePM est une façon d'envelopper toutes ces choses ensemble et d'impliquer la direction dans la prise de décisions cruciales au sein de projets agiles d'importance stratégique élevée.   

 

Si vous regardez l’étude annuelle « Agile Trends & Benchmark Report », produite par SwissQ, une société de conseil spécialisée dans les technologies de l'information et des pratiques de tests, et (page 4) vous trouverez une courbe de maturité qui montre que Scrum s’approche d’une phase de  post-maturité et DSDM se trouve dans la phase d'introduction du cycle de vie.

 

L'enquête révèle (page 5) que: "54% de tous les projets agiles échouent en raison de difficultés à concilier la philosophie d'entreprise avec des valeurs agiles»,  «les projets Scrum demeurent des îlots qui sont largement auto-organisés» et que «17,9% de praticiens des méthodes agiles utilisent ‘definition of ready’,  alors que 62,1% utilisent ‘definition of done’».

 

Certes, 42,2% des statistiques sont inventées bien sûr ;-)  Néanmoins, pour moi, la signification est dans les rôles.  Des consultants en pratiques de tests recommandent un «testeur intégré», une notion qui est ancrée au sein de DSDM. Scrum insiste à plusieurs reprises sur l'indépendance de l'équipe de toute intrusion de la direction et le rôle du ‘Product Owner’ consiste à «servir le client». (Eh oui: il est important de savoir ce que les mots «servir» et «client» devrait signifier à chaque fois ;-)

 

SAFe décrit le rôle de ‘Product Manager’ d'une manière qui évoque une gestion hiérarchique.  Le chef de produit "communique la vision" à l'équipe et "maintient la feuille de route du produit." http://www.scaledagileframework.com/product-management/ En substance ce rôle est «typiquement un membre actif de l'équipe de gestion de portefeuille de projets, où on participe à la prise de décisions sur les principaux vecteurs économiques pour les versions futures".

 

Avec DSDM, le visionnaire d'affaires « définit la vision de l'entreprise », favorise l’interprétation de cette vision en actions, surveille l’avancement réalisé en conformité avec la vision de l'entreprise, communique et favorise la vision à toutes les parties intéressées, etc   Ceci est potentiellement un rôle beaucoup plus proactif et élevé.

 

A mon sens, ce sont des points clés: Un projet «stratégique» peut «faire pivoter» la vision de l'entreprise. Un projet stratégique agile peut contraindre à engendrer des réorientations fréquentes de la vision au cours du projet.  Une clarification de cette vision implique un dialogue interactif, un degré de confiance et de respect mutuel entre l'équipe de développement (la technologie) et l'entreprise (le marché).  La phrase « définit la vision de l'entreprise» doit admettre la participation et encourager l'appropriation par les partenaires. Tous les partenaires de cette élaboration et de mise en forme de la vision de l'entreprise doivent apprendre à comprendre le vocabulaire, non seulement de la technologie (agile ou autre), mais aussi de l'entreprise.





rss


sitemap xml