La méthode Agile facilite la gestion du changement au sein du gouvernement

Publié le 1er mars 2022 en Transformation numérique du gouvernement

La méthode agile est-elle la solution miracle pour la réussite des projets gouvernementaux ? Nous sommes des défenseurs de la méthode agile en raison de l'amélioration des taux de réussite grâce au développement agile de produits, à la gestion agile de projets et au développement agile de pays. Notre méthodologie, A-i³+qM s'appuie sur des bonnes pratiques éprouvées et sur près de 40 ans de mise en œuvre exclusive auprès des pouvoirs publics.

Comment la gestion du changement est-elle liée à la méthodologie agile ?

Les techniques agiles, lorsqu'elles sont adaptées à l'administration, intègrent changer. Au-delà de la gestion du changement logiciel, vers un véritable changement organisationnel. Planification des ressources publiques (GRP) est configuré pour répondre efficacement aux besoins réels.

Lorsqu'elle est pratiquée correctement, la méthode agile implique les parties prenantes tôt et souvent. La résistance au changement se dissipe au fur et à mesure que les problèmes sont résolus et que les progrès sont prouvés. Comme l'observe Jason Little, "L'agilité n'est pas une question d'agilité, c'est une question de changement.“.

Gestion du changement dans l'administration est particulièrement importante pour la mise en œuvre de nouveaux systèmes financiers, de ressources humaines, de marchés publics ou de performance. Dans les Cadre cynefin (schéma ci-dessus), la mise en œuvre du PRG est plus que technique. Elle n'est pas simple, même si beaucoup espèrent que les gouvernements suivent "meilleures pratiques". Nombre de ces pratiques sont inadaptées au contexte gouvernemental de l'époque.

De plus, la mise en œuvre d'un PRG est bien plus qu'un simple projet de gestion du changement de logiciel. C'est transformationnel. Des réformes juridiques, de nouveaux processus, des réorganisations et de nouvelles mesures de performance doivent être mis en place.

L'objectif de la mise en œuvre des PRV est de soutenir bonnes pratiquesce qui complique les mises en œuvre. En réalité, les mises en œuvre deviennent complexes, parfois chaotiques, en raison des contraintes propres au secteur public :

• Les parties prenantes ne sont pas seulement les gouvernements, mais aussi les citoyens
• Capacités et incitations des services publics
• De la politique, de la politique et encore de la politique

Comment la gestion du changement fait-elle partie intégrante de la méthode Agile ?

Bien qu'il existe de nombreuses techniques agiles, (voir glossaire ci-dessous), la gestion du changement organisationnel dans le secteur public est implicite depuis la création de l'Union européenne. Manifeste Agile. Les valeurs du manifeste montrent que les personnes, la collaboration et la flexibilité sont primordiales.

• Les individus et les interactions plutôt que les processus et les outilsL'interaction fréquente avec les parties prenantes et les utilisateurs réduit la résistance au changement tout en augmentant la probabilité que les besoins réels soient pris en compte (un principe agile : "les gens d'affaires et les développeurs doivent travailler ensemble quotidiennement tout au long du projet").
• Logiciel fonctionnel et documentation complèteLa documentation n'aboutit pas à une compréhension partagée avec les parties prenantes et les utilisateurs - retarde souvent la mise en œuvre, ce qui donne du temps pour la mise en œuvre de l'application. résistance au changement augmenter (principe agile : "la méthode la plus efficace pour transmettre des informations à une équipe de développement et au sein de celle-ci est la conversation en face à face").
• La collaboration avec le client plutôt que la négociation du contratLa collaboration permet aux parties prenantes et aux utilisateurs de s'exprimer
• Répondre au changement plutôt que suivre un planle contexte est appris au fil des conversations, et non par une planification rigide

Comment réussir la gestion agile du changement dans l'administration publique ?

La méthode agile fonctionne bien lorsque confiance est possible et encouragée. L'approche Agile permet de gérer le changement dans les administrations publiques lorsqu'elle est correctement gérée :

• Considérationles techniques agiles telles que le Design Thinking et le PDIA encouragent l'empathie et la compréhension des problèmes du point de vue des parties prenantes et des utilisateurs
  • IMPACT : les parties prenantes et les utilisateurs se rendent compte que les systèmes ne sont pas imposés par des personnes extérieures.
• Axé sur le clientl'agile travaille à partir du client (ce que nous appelons "outside-in" dans la gestion de produit) plutôt que du produit (ce que nous appelons "inside-out" dans la gestion de produit)
  • IMPACT : les craintes et les aspirations des parties prenantes et des utilisateurs sont intégrées dans les projets
• Communicationcommunication constante : les parties prenantes et les utilisateurs sont tenus au courant par le biais de tableaux et d'autres méthodes de communication visuelle pour présenter les décisions, les progrès et les retards.
  • IMPACT : les parties prenantes et les utilisateurs sont moins enclins à imaginer le pire entre les étapes, lorsque les progrès sont communiqués de manière visible.
• Conversationconversations en face à face avec les parties prenantes et les utilisateurs, y compris des ateliers, des séances de remue-méninges et des story-boards
  • IMPACT : les parties prenantes et les utilisateurs reconnaissent la capacité d'ajuster les produits livrables du projet tout en apprenant davantage sur la valeur du projet pour eux, leur organisation et leur pays afin d'accroître l'acceptation du changement.
• Contextele contexte du pays et du gouvernement est compris par les équipes de projet (et FreeBalance dispose d'outils pour permettre ce processus)
  • IMPACT : la compréhension partagée entre les participants est améliorée afin de réduire la résistance au changement
• CollaborationLes équipes de projet, les parties prenantes et les utilisateurs travaillent ensemble pour définir les priorités, résoudre les problèmes et discuter des solutions.
  • IMPACT : l'influence sur le projet par l'implication augmente l'acceptation du changement
• CréativitéLes questions relatives à l'environnement : tirer parti de la créativité des parties prenantes et des utilisateurs afin de mieux résoudre les problèmes.
  • IMPACT : les parties prenantes contribuent à résoudre les problèmes, y compris les problèmes de changement.
• Confirmationla collaboration permet aux participants de confirmer les priorités du projet tout au long de son déroulement, plutôt que de se contenter d'une approbation lors des principales étapes.
  • IMPACT : les retards du projet sont réduits grâce à la confirmation itérative, qui laisse peu de temps à la résistance au changement de se développer, tandis que les boucles de retour d'information valident les préoccupations des parties prenantes et des utilisateurs.
• Capacitéla capacité du projet gouvernemental et du domaine de la gouvernance développée au cours des conversations et de la collaboration en tant que mentorat, augmentant la formation et améliorant le succès du projet.
  • IMPACT : maintient la trajectoire du changement organisationnel au-delà du projet (et rend le projet plus durable)

Pourquoi les gouvernements résistent-ils à la gestion agile du changement ?

Certains clients gouvernementaux se demandent pourquoi nous impliquons des non-experts dans la conception de solutions. Les démonstrations semblent être la meilleure approche pour communiquer l'impact de la méthode agile sur l'amélioration de la prise de décision et de la gestion du changement organisationnel dans le secteur public. Outre l'utilisation de agile pour les mises en œuvreNous avons utilisé des exercices agiles lors de nos réunions annuelles. Comité de pilotage international de FreeBalance (FISC), des ateliers sur le changement et des exercices sur le contexte national.

Le changement d'attitude des fonctionnaires est palpable. Au début, la suspicion. Peut-être un peu de confusion. Puis, la collaboration et la conversation. On en arrive au point où chaque groupe de travail veut présenter ses conclusions à l'atelier. Une véritable collaboration.

Qu'est-ce que le processus de gestion du changement organisationnel ?

Les processus traditionnels de gestion du changement organisationnel ont tendance à être linéaires et séquencés, comme le décrit le modèle de la 5 I :

1. Initiation
2. Enquête
3. Intention
4. Introduction
5. Mise en œuvre
6. Intégration

Une autre approche conçue par John Kotter:

Ce sont d'excellents cadres pour le changement organisationnel. L'approche linéaire, cependant, semble s'aligner sur l'approche traditionnelle du changement organisationnel. chute d'eau approches. Tout comme l'approche agile peut s'aligner sur les normes CMMi et ISO, il n'y a aucune raison de ne pas tirer parti de ces approches de manière itérative. L'itération peut améliorer les résultats du changement, tout comme les taux de réussite du développement de logiciels et de la gestion de projets s'améliorent grâce à la méthode agile.

Nous avons vu des projets dans lesquels la gestion du changement organisationnel au sein du gouvernement était considérée comme un complément à la gestion de projet. Il en résulte souvent une gestion du changement inefficace et "au coup par coup".
Il est logique d'avoir des experts en changement dans les projets. Il y a souvent une déconnexion lorsque les experts en changement manquent d'expertise dans le domaine. Il est donc plus efficace que le changement fasse partie intégrante des projets. Il est donc plus efficace que le changement fasse partie intégrante des projets et que le personnel du projet construise le changement et la crédibilité.

Quels sont les avantages de la gestion agile du changement dans les administrations publiques ?

Reed Deshler constate la nécessité d'une approche en temps réel à la gestion du changement dans les projets agiles. Il s'agit notamment d'adapter les processus de gestion du changement aux besoins de chaque projet. Une étude réalisée par Prosci a analysé les pratiques de gestion du changement dans les projets agiles. L'analyse a montré qu'une gestion réussie du changement dans les projets agiles nécessite :

• Approches itératives plutôt que linéaires
  • OBSERVATION : toutes les composantes du projet sont itératives dans le cadre de la méthode agile, et l'impact de la gestion du changement est continu afin d'obtenir l'acceptation du changement.
• Des plans de changement conçus pour s'adapter
  • OBSERVATION : les plans de changement devraient évoluer au fur et à mesure que les participants au projet en apprennent davantage sur le contexte grâce à la conversation et à la collaboration - il s'agit là d'une adaptation au retour d'information.
• Nécessite plus de temps au départ
  • OBSERVATION : la méthode agile fournit un cadre de communication pour le changement afin de faciliter la planification, tandis que la planification du changement se fait davantage en réduisant la planification et la documentation du projet - où la gestion du changement devient une priorité plus importante.

Notre expérience de l'approche agile dans le monde réel est qu'elle génère le type de gains rapides nécessaires pour maintenir l'adhésion au changement. La méthode agile offre des étapes visibles entre les gains rapides grâce à l'implication, à la flexibilité et au prototypage. Nous avons bénéficié de la conception du produit de la FreeBalance Accountability Suite™ grâce à des méthodes de configuration qui permettent de confirmer les règles commerciales et la configuration dans des ateliers. Cela permet le type de développement agile qui n'est pas disponible dans les logiciels gouvernementaux entièrement personnalisés ou dans les logiciels du secteur privé lourdement personnalisés tels que les progiciels de gestion intégrés (ERP).

Approche PDIA de la gestion agile du changement dans l'administration publique

Comme nous l'avons décrit précédemment, le contexte de la gestion du changement organisationnel tend à être plus complexe dans l'administration que dans les entreprises. Adaptation itérative guidée par les problèmes (PDIA), une méthodologie de développement du secteur public et un excellent outil de gestion du changement, répond à ce défi de la complexité. La PDIA est de plus en plus acceptée dans les milieux de la bonne gouvernance et de la gestion du changement. communauté de développement des pays.

Le PDIA a été développé par la Renforcement des capacités de l'État (Building State Capacity facility) de la Harvard Kennedy School of Government (Harvard Kennedy School of Government). Il s'agit de bien plus qu'un exercice académique avec de nombreuses études de cas dans le monde réel. Il s'agit d'une partie de la Faire du développement différemment mouvement. Nous sommes de fervents partisans du PDIA. Nombre de nos cadres ont suivi la formation continue du PDIA. De nombreux membres de notre personnel ont suivi des cours en ligne du PDIA.

La PDIA donne la priorité au changement et à la persuasion, permet de définir les rôles et les stratégies de communication. La cartographie des parties prenantes, la communication et la collaboration sont intégrées dans la PDIA.

La PDIA permet d'analyser les changer d'espaceLe changement : le chevauchement de l'autorité, de la capacité et de l'acceptation. Il s'agit d'une technique de gestion du changement particulièrement efficace. Comme le décrit le Manifeste pour une approche différente du développementLa réussite de l'opération passe par une légitimation "à tous les niveaux (politique, managérial et social), par une appropriation et une dynamique tout au long du processus afin que l'opération soit réellement "prise en charge localement" (et non pas seulement sur le papier)".

Le PDIA reconnaît que les changements substantiels ne dépendent pas d'un leader héroïque. Les changements réussis dans le secteur public sont le fait de nombreux dirigeants. Ce sont des agents. Cela va au-delà de l'approche traditionnelle des agents de changement, qui deviennent des agents d'expansion. Le changement à grande échelle se présente sous la forme d'un flocon de neige métaphore.

Qu'est-ce que la méthodologie Agile de FreeBalance ?

Notre méthodologie a évolué au fil des ans. La version actuelle est A-i³+qM (accéléré, intégré, itératif, axé sur la mise en œuvre, gestion de la qualité) :

• Accéléré en éliminant le plus grand nombre possible de processus en cascade qui conduisent à des problèmes de projet. Il s'agit notamment de la documentation inutile et des plans de projet détaillés, au profit d'ateliers et d'étapes de processus courtes. La taille des équipes est réduite afin de faciliter la communication avec les clients et de réduire les frais de coordination.
• Intégré par le biais d'une méthodologie unique pour soutenir le développement et la mise en œuvre des services. Cette méthodologie est intégrée aux exigences du client par le biais des processus centrés sur le client. Cela permet d'assurer la transparence entre le personnel du client, les responsables de la mise en œuvre et l'équipe de développement. Les équipes de mise en œuvre et de développement de produits sont intégrées selon les pratiques DevOps.
• Itératif d'être réactif aux changements des clients et de la mise en œuvre en utilisant des phases. La méthodologie s'appuie sur le meilleur des méthodes éprouvées de développement de logiciels et de services "allégés", avec des ateliers, des itérations courtes, des récits d'utilisateurs, des jalons et la possibilité de montrer les progrès accomplis. Ces techniques sont étendues au-delà de l'organisation de développement aux services de mise en œuvre, ce qui permet de tirer parti des gains de productivité et de la capacité à réagir aux exigences des clients.
• Axé sur la mise en œuvre avec des modèles de bonnes pratiques et des processus de gestion de programme éprouvés. Cette méthodologie est axée sur la réussite de la mise en œuvre par le client, plutôt que sur une version logicielle qui atteint des objectifs internes ou arbitraires. La mise en œuvre et le développement du produit sont gérés par un bureau de gestion de programme.
• Qualité L'approche de FreeBalance garantit que le logiciel est publié et pris en charge conformément aux bonnes pratiques des produits commerciaux sur étagère (COTS) avec des tests d'unité, de système, de stress et de régression. La qualité est intégrée à la mise en œuvre, FreeBalance effectuant des tests basés sur les environnements des clients.

A-i³+qM reconnaît les déficiences des processus traditionnels de gestion de projet dans la mise en œuvre des PRG. Et les modèles d'échec.

Glossaire Agile

Toutes les définitions, à l'exception de PDIA, via wikipedia.org

• Développement de logiciels adaptatifs (ASD) est un processus de développement logiciel issu des travaux de Jim Highsmith et Sam Bayer sur le développement rapide d'applications (RAD). Il incarne le principe selon lequel l'adaptation continue du processus au travail en cours est l'état normal des choses.
• Développement de logiciels agiles est une approche du développement de logiciels selon laquelle les exigences et les solutions évoluent grâce à la collaboration d'équipes auto-organisées et interfonctionnelles et de leur(s) client(s)/utilisateur(s) final(s)[1]. Elle préconise la planification adaptative, le développement évolutif, la livraison anticipée et l'amélioration continue, et encourage une réponse rapide et flexible au changement.
• Penser en termes de conception désigne les processus cognitifs, stratégiques et pratiques par lesquels les concepts de conception (propositions de nouveaux produits, bâtiments, machines, etc.) sont élaborés par les concepteurs et/ou les équipes de conception. De nombreux concepts et aspects clés de la réflexion sur la conception ont été identifiés grâce à des études, dans différents domaines de la conception, de la cognition et de l'activité de conception en laboratoire et dans des contextes naturels.
• DevOps est un ensemble de pratiques de développement de logiciels qui combine le développement de logiciels (Dev) et l'exploitation des technologies de l'information (Ops) afin de raccourcir le cycle de vie du développement des systèmes tout en fournissant des fonctionnalités, des correctifs et des mises à jour fréquemment en étroite adéquation avec les objectifs de l'entreprise.
• Livraison agile disciplinée (DAD) est un cadre décisionnel qui permet de simplifier les décisions relatives à la fourniture de solutions incrémentielles et itératives. Le DAD s'appuie sur les nombreuses pratiques adoptées par les partisans du développement agile de logiciels, notamment Scrum, la modélisation agile, le développement de logiciels allégés, etc.
• Méthode de développement de systèmes dynamiques (DSDM) est un cadre d'exécution de projet agile, initialement utilisé comme méthode de développement de logiciels.
• Programmation extrême (XP) est une méthodologie de développement de logiciels qui vise à améliorer la qualité des logiciels et la réactivité face à l'évolution des besoins des clients. En tant que type de développement agile de logiciels, elle préconise des "versions" fréquentes dans des cycles de développement courts, ce qui vise à améliorer la productivité et à introduire des points de contrôle permettant d'adopter les nouvelles exigences des clients.
• Développement axé sur les fonctionnalités (FDD) est un processus de développement logiciel itératif et incrémental. Il s'agit d'une méthode légère ou agile de développement de logiciels.
• Développement itératif et incrémental est une combinaison de la conception itérative ou de la méthode itérative et du modèle de construction incrémentielle pour le développement.
• Kanban (en japonais 看板, panneau de signalisation ou panneau d'affichage) est une méthode allégée de gestion et d'amélioration du travail dans les systèmes humains. Cette approche vise à gérer le travail en équilibrant les demandes avec les capacités disponibles et en améliorant le traitement des goulets d'étranglement au niveau du système.
• Développement de logiciels allégés est une transposition des principes et pratiques de la production allégée au domaine du développement de logiciels. Adapté du système de production Toyota, il émerge avec le soutien d'une sous-culture pro-lean au sein de la communauté Agile. Le Lean offre un cadre conceptuel solide, des valeurs et des principes, ainsi que de bonnes pratiques, dérivées de l'expérience, qui soutiennent les organisations agiles.
• Scrum à grande échelle (LeSS) est un cadre de développement de produits qui étend Scrum avec des règles et des lignes directrices de mise à l'échelle sans perdre les objectifs initiaux de Scrum.
• Ingénierie pilotée par les modèles (MDE) est une méthodologie de développement de logiciels qui se concentre sur la création et l'exploitation de modèles de domaine, qui sont des modèles conceptuels de tous les sujets liés à un problème spécifique. Elle met donc l'accent sur les représentations abstraites des connaissances et des activités qui régissent un domaine d'application particulier, plutôt que sur les concepts informatiques (c'est-à-dire algorithmiques).
• Cadre de solutions Microsoft (MSF) est un ensemble de principes, de modèles, de disciplines, de concepts et de lignes directrices pour la fourniture de services de technologie de l'information par Microsoft. Le MSF ne se limite pas au développement d'applications ; il s'applique également à d'autres projets informatiques tels que les projets de déploiement, de mise en réseau ou d'infrastructure. Le MSF n'oblige pas le développeur à utiliser une méthodologie spécifique (telle que le modèle en cascade ou le développement agile de logiciels).
• Les Processus logiciel personnel (PSP) est un processus structuré de développement de logiciels qui a pour but (prévu) d'aider les ingénieurs en logiciel à mieux comprendre et à améliorer leurs performances en disciplinant la manière dont ils développent des logiciels et en suivant le développement prévu et réel du code. Il montre clairement aux développeurs comment gérer la qualité de leurs produits, comment élaborer un plan solide et comment prendre des engagements. Il leur fournit également les données nécessaires pour justifier leurs plans.
• Adaptation itérative guidée par les problèmes (PDIA) est un processus d'émergence facilitée qui se concentre sur les problèmes (et non sur les solutions) et suit un processus étape par étape (et non un plan rigide) qui permet un apprentissage et une adaptation flexibles. Ce processus a été conçu par le service Building State Capacity de la Harvard Kennedy School of Government.
• Développement rapide d'applications (RAD), également appelé Rapid-application building (RAB), est à la fois un terme général, utilisé pour se référer aux approches de développement de logiciels adaptatifs, et le nom de l'approche de James Martin en matière de développement rapide. En général, les approches RAD du développement de logiciels mettent moins l'accent sur la planification et davantage sur un processus adaptatif. Les prototypes sont souvent utilisés en plus ou parfois même à la place des spécifications de conception.
• Les Processus unifié rationnel (RUP) est un cadre de processus itératif de développement de logiciels créé par Rational Software Corporation, une division d'IBM depuis 2003[1]. RUP n'est pas un processus prescriptif unique et concret, mais plutôt un cadre de processus adaptable, destiné à être personnalisé par les organisations de développement et les équipes de projets logiciels qui sélectionneront les éléments du processus qui conviennent à leurs besoins. Le RUP est une mise en œuvre spécifique du processus unifié.
• Les Cadre agile échelonné (abrégé en SAFe), est un ensemble de modèles d'organisation et de flux de travail destinés à guider les entreprises dans la mise à l'échelle des pratiques agiles et allégées. Avec Scrum à grande échelle (LeSS), la livraison agile disciplinée (DAD) et Nexus, SAFe fait partie d'un nombre croissant de cadres qui cherchent à résoudre les problèmes rencontrés lors de la mise à l'échelle au-delà d'une seule équipe.
• Scrum est un cadre agile pour la gestion du travail de connaissance, qui met l'accent sur le développement de logiciels, bien qu'il soit largement appliqué dans d'autres domaines et commence lentement à être exploré par les équipes de projet traditionnelles de manière plus générale. Il est conçu pour des équipes de trois à neuf membres, qui divisent leur travail en actions pouvant être réalisées dans des itérations délimitées dans le temps, appelées sprints, d'une durée maximale d'un mois et le plus souvent de deux semaines, puis suivent les progrès et replanifient au cours de réunions de 15 minutes délimitées dans le temps, appelées mêlées quotidiennes (scrums).
• Scrumban est une méthodologie de gestion Agile décrivant des hybrides de Scrum et Kanban et a été conçue à l'origine comme un moyen de transition entre Scrum et Kanban. Aujourd'hui, Scrumban est un cadre de gestion qui émerge lorsque des équipes utilisent Scrum comme méthode de travail choisie et utilisent la méthode Kanban comme lentille pour voir, comprendre et améliorer continuellement la façon dont elles travaillent.
• SEMAT (Software Engineering Method and Theory) est une initiative visant à remodeler le génie logiciel de manière à ce qu'il soit considéré comme une discipline rigoureuse. L'initiative a été lancée en décembre 2009 par Ivar Jacobson, Bertrand Meyer et Richard Soley avec une déclaration d'appel à l'action et une déclaration de vision. L'initiative a été envisagée comme un effort pluriannuel visant à combler le fossé entre la communauté des développeurs et la communauté universitaire et à créer une communauté apportant de la valeur à l'ensemble de la communauté du logiciel.
• En combinaison avec le processus logiciel personnel (PSP), le processus logiciel personnel (PSP) est le processus logiciel personnel (PSP). processus logiciel en équipe (TSP) fournit un cadre de processus opérationnel défini qui est conçu pour aider les équipes de gestionnaires et d'ingénieurs à organiser des projets et à produire des logiciels qui vont de petits projets de plusieurs milliers de lignes de code (KLOC) à de très grands projets de plus d'un demi-million de lignes de code.
• Le processus unifié de développement de logiciels ou Processus unifié est un cadre de processus de développement logiciel itératif et incrémental. Le raffinement le plus connu et le plus documenté du processus unifié est le Rational Unified Process (RUP). D'autres exemples sont OpenUP et Agile Unified Process.