Gestion de projets classique ou agile

Les disciplines traditionnelles appartiennent-elles au passé ?

Comme évoqué dans l’article paru en 2009 dans Eraneos FOCUS, nous
savons par expérience que ces constatations ont été consacrées par la
pratique. Toutefois, suite aux questions fréquentes que se posent nos clients,
nous souhaitons apporter une clarification de fond, en commençant par les
thèmes suivants :

• Quelles possibilités les organisations ont-elles d’utiliser des méthodes
agiles ?

• Quel rôle peuvent jouer les disciplines classiques de gestion de projets,
comme la gestion des risques, la gestion de la qualité et le reporting,
dans des projets réalisés avec une approche agile ?

Comme SCRUM s’est principalement imposé parmi les approches agiles,
nous allons nous concentrer principalement sur cette méthode quand nous
parlons d’agilité dans le présent numéro d’Eraneos FOCUS. À l’aide d’exemples
pratiques, nous exposerons les voies vers l’agilité qu’une organisation
peut emprunter, mais aussi l’importance que nos clients des transports ferroviaires
attachent à ce thème, ainsi que le modèle hybride adopté au sein
de l’administration fédérale. Nous montrons par ailleurs que les disciplines
traditionnelles de la gestion de projets ne sont pas un modèle dépassé, mais
qu’elles renforcent considérablement la professionnalisation de l’exécution
de projets, dans une approche classique comme dans une approche agile.
Nous vous souhaitons une lecture enrichissante et espérons vous donner de
nombreuses nouvelles idées.

Maîtriser les projets agiles
Les disciplines de gestion de projets bien intégrées comme
facteur de réussite

Conditions cadre
Une procédure de projet agile est moderne, on la considère donc comme la
panacée. Quelle entreprise n’a pas envie d’être agile ? Le passage à l’agilité
(partielle) dans une organisation requiert toutefois deux conditions fondamentales :

• Elle doit valoir la peine : avec des procédures agiles, les projets débouchent
sur de meilleurs résultats ou sur des produits suffisamment mature pour être
approuvés par les parties prenantes.

• Elle doit être possible : des approches agiles nécessitent d’importants changements
de la culture d’organisation, en d’autres termes de l’attitude et du
comportement des personnes à tous les échelons hiérarchiques. En outre,
un résultat de projet doit se développer de façon itérative et conduire par
étapes à la maturité du produit.

Analyser dans le détail tous les aspects d’une transformation agile réussie
outrepasserait les limites de cet article. Les principales conditions sont
résumées dans le tableau 1 ci-dessous. Par ailleurs, il faut tenir compte du
fait que toute modification d’une organisation, y compris celles qui mènent
à l’agilité, demande non seulement une bonne préparation et une bonne
exécution, mais aussi beaucoup de temps de maturation.

Modèles d’application et transformation
Les organisations abordent généralement la transformation agile – le passage
d’une approche de projet classique à une approche agile – avec beaucoup
d’enthousiasme et une gestion prudente du changement. La manifestation
intégrale de l’agilité ne convient toutefois pas à tous les contextes.
Nous considérons qu’il existe en principe trois modèles de mise en oeuvre de
l’agilité dans l’organisation (cf. ill. 1) :

1 Le modèle hybride : les projets réalisés de manière agile sont combinés
avec une gestion classique du portefeuille de projets et des programmes.

2 Le modèle bimodal (aussi appelé two speed) : les projets réalisés de manière
classique ou agile coexistent et leur degré de priorité est établi par une
gestion classique ou agile du portefeuille de projets et des programmes.

3 L’agilité intégrale : l’approche de gestion agile s’applique aux échelons du
portefeuille de projets, des programmes et des projets.
Les éléments classiques et agiles peuvent être combinés facilement et

atteignent ensemble une efficience élevée. Le mélange des modèles est l’objectif
final ou un stade intermédiaire sur la voie de la transformation agile.
Il n’y a en l’occurrence pas de vrai ou de faux, mais seulement une meilleure
ou une moins bonne adaptation aux attentes et aux capacités d’une organisation.
L’interview du client (objectif agilité comme développement final)
en page 7 ou l’exemple pratique (premiers pas dans un système bimodal) en
page 10 illustrent clairement les différentes approches.

Chances, risques et qualité
Dans notre activité auprès des clients, les questions suivantes sont récurrentes :
les chances, la gestion des risques et la gestion de la qualité sont-elles
vraiment prévues dans le monde agile ? Comment pouvez-vous garantir que
notre projet ne va pas échapper à tout contrôle ? Qui est responsable, s’il n’y
a pas de chef de projet classique ?
L’approche agile aborde d’une manière implicitement active et répétée les
chances et les risques grâce à des réunions régulières (sprint planning, daily
SCRUM, sprint retrospective) et des sprint reviews. Nous recommandons de
faire en sorte que le product owner gère et analyse lui-même ses backlogs
de chances et de risques. Les éléments du backlog peuvent être intégrés
comme exigences dans la planification des sprints. Il en résulte que la maîtrise
des chances et des risques est intégrée naturellement et de manière
évidente dans la mise en oeuvre opérationnelle du projet. Les obstacles
(impediments) sont aussi détectés et levés au plus vite de la même manière.
Ce processus bénéficie du soutien du SCRUM master, qui joue le rôle central
de découvreur de solutions et de leveur d’obstacles.
Dans la mise en oeuvre de projet agile, la gestion de la qualité suit le même
principe (cf. tabl. 2) : la qualité doit être fournie en permanence. L’assurance qualité
et d’éventuelles corrections sont assurées à chaque itération.
La qualité est analysée pour les user stories sur la base de critères d’acceptation
préalablement définis. Le respect de ces critères produit d’une part, de l’utilité
commerciale et assure, d’autre part, que la qualité exigée soit atteinte.
De notre point de vue, les approches agiles sont un bon moyen de traiter les
chances, les risques et la qualité plus souvent, de façon plus transparente et
en répartissant la charge sur davantage de rôles. Nous avons fait de bonnes
expériences avec le traitement explicite de ces thèmes, tel que l’approche
agile le recommande.

Controlling et reporting
Dans les projets réalisés selon le modèle classique, le controlling porte
davantage sur les éléments suivants : qualité, périmètre (scope), dépenses
ou coûts, risques et durée. Ces éléments sont également présents dans les
projets agiles, mais sont toutefois traités de manière implicite :

• Qualité : les exigences de qualité sont un élément de critères d’acceptation.
La réalisation et l’acceptation d’une user story dans un sprint intègre
toujours la qualité, en plus de l’utilité commerciale.

• Scope : l’étendue du service et le scope d’un projet sont définis par le backlog
management et vérifiés dans le sprint review (souvent en combinaison
avec le contrôle des coûts).

• Coûts : les coûts du projet sont généralement considérés comme fixes, et
pour ce faire, on modifie le scope.
• Risques : les chances et les risques se retrouvent dans leurs propres backlogs
et sont automatiquement intégrés dans la planification des sprints.

• Durée : les sprints sont prévus à date fixe. Les écarts de délais dans les projets
sont uniquement dus à la réalisation de sprints supplémentaires.

En raison de la tendance à définir des coûts fixes et à aménager le scope de
façon variable, le controlling des projets agiles est souvent limité à l’exécution
des product backlogs et au nombre nécessaire de sprints. Grâce à
l’utilisation adéquate de procédures de projets agiles, le controlling au sein
de chaque sprint se déroule pratiquement en temps réel, ce qui augmente la
transparence et la vitesse de réaction. Les faiblesses sont en revanche détectées
lors du controlling général portant sur l’ensemble du projet. Comme on
procède aussi à des investissements dans les projets réalisés avec la méthode
agile, le controlling lié au projet ne doit pas être négligé. Nous recommandons
de porter un regard aiguisé sur tous les éléments cités plus haut, y compris
sur la combinaison coûts – scope.
Compte tenu des conditions d’utilisation suivantes, nous avons fait de très
bonnes expériences avec la méthode earned value1 pour le controlling et le
reporting de projets agiles :

• La communication se fait à partir de graphiques desquels des tendances
peuvent être déduites.

• La courbe de la planned value est calculée précisément par rapport au
nombre total ou partiel de sprints prévus. Elle représente la somme de toutes
les tâches nécessaires à la réalisation des éléments du backlog dans
chaque sprint.

• Pour déterminer la courbe earned value, nous tenons compte uniquement
des tâches terminées (approche 0/100) tirées de la planification des
sprints.

• Pour la courbe budget burned, nous utilisons le travail réel cumulé fourni
chaque semaine par l’équipe SCRUM.

• Pour que toutes les valeurs puissent être comparées entre elles, nous les
présentons en valeur relative (en pourcent).

• Les courbes earned value et budget burned sont tracées pour l’ensemble
des sprints et sont ainsi comparables avec les droites de la planned value.

L’agilité aux CFF Entretien avec un client

Monsieur Krähenbühl, pourquoi les CFF ontils décidé d’adopter des approches agiles ?
Les CFF sont une entreprise solide et plutôt lourde, qui mène de nombreux
projets à long terme. Pensez seulement aux projets d’infrastructure ou à
l’achat du matériel roulant. Cela implique que la méthode en cascade soit
profondément inscrite dans l’ADN de l’entreprise. Dans le domaine des
projets TIC et des projets d’organisation, les méthodes en cascade ont été
longtemps largement répandues. Il en a résulté des montagnes de papier
sans résultats visibles. Ces dernières années et ces derniers mois, la situation
a toutefois beaucoup changé. « IC+ » devrait notamment être un précurseur
dans le domaine de l’agilité.

Comment fonctionnent la planification et le pilotage à la tête du programme ?
C’est un véritable défi. Mais les efforts des personnes concernées en vue
d’une amélioration progressive sont clairement visibles. Les processus de
controlling sont pour la plupart encore basés sur la cascade. Mais les responsables
sont en train d’ « agiliser » leurs processus. Dans les faits, les product
owners/chefs de projets suivent une feuille de route ; ils planifient et exécutent
les tâches de manière itérative. Toutefois, les propositions formelles et
le reporting doivent être soumis aux phases de cascade classiques, tels que
concept, réalisation et mise en service.

La confiance dans le comité de pilotage et l’interaction avec ce dernier sont
donc essentielles. Au sein du comité de pilotage, le fond doit l’emporter sur
les aspects formels. Une telle confiance doit se construire et n’est réelle qu’au
terme de deux ou trois réunions. L’expérience et la bonne réputation du chef
de projet sont, bien entendu, d’une aide précieuse. Si les résultats fournis
sont conformes aux attentes, il en résulte une collaboration orientée sur les
résultats. Le comité de pilotage n’est pas un organe de contrôle ; il soutient,
accompagne et oriente.

Le passage à l’approche agile a certainement été lié à de grands changements. Comment jugez-vous les progrès de la transformation ?
Qu’est-ce qui a changé ? Qu’est-ce qui reste à faire ?
Nous sommes au milieu du gué. Nous, les gens du programme « IC+ », nous
participons deux fois par année à la « retraite du Gurten », à Berne, notamment
pour évaluer nos progrès en matière d’agilité. Nous observons une
légère évolution, mais pour changer une culture, il faut compter au moins
cinq années. Il existe encore du potentiel d’amélioration, p. ex. s’agissant des
conditions cadres pour les équipes (locaux, infrastructures) et la disponibilité
de spécialistes, notamment de représentants du secteur commercial dans
les équipes agiles.

De quels outils et méthodes conventionnels du groupe le programme doit-il
tenir compte ( jalons, planification financière, gestion de la qualité, gestion
des risques) ?
Nous devons tenir compte exactement des mêmes disciplines dans les processus
agiles. La méthode agile ne signifie pas que l’on peut courir tête baissée
sans planification aucune. Il faut gérer les risques et assurer la qualité.
Les approches agiles simplifient et soutiennent ces procédures.

Le traitement du financement des projets et des budgets a-t-il changé ?
Le processus financier n’est pas encore suffisamment transformé pour refléter
complètement les projets agiles. Mais il fait de grands progrès dans cette direction
(p. ex. avec la gestion simplifiée des portefeuilles de projets PPM Light).
Désormais, le budget est fixe et le scope et les résultats s’y adaptent. En la
matière, l’établissement de priorités est essentiel. On est contraint de laisser
tomber tout ce qui est inutile. La devise est la suivante : « plutôt fournir moins
pour que ça fonctionne ». La conséquence de cette nouvelle approche devrait
être la diminution du nombre de crédits supplémentaires.

Y a-t-il des effets sur la gestion des fournisseurs ?
Les contrats actuels contiennent les faits connus à un instant T. Toutefois,
les faits établis se modifient au fil du temps. Avec certains fournisseurs, la
procédure agile fonctionne bien : compréhension, confiance et traitement
correct (donner et prendre) sont de mise.
Le modèle d’affaires d’autres fournisseurs est basé sur des prix d’entrée bas et
sur le claim management qui en résulte. Il existe rarement un bon partenariat
avec de telles entreprises. La base d’une collaboration à long terme n’existe pas.
À l’avenir, les appels d’offres seront réalisés davantage par blocs thématiques
que par chantiers. Par exemple : « nous recherchons un partenaire à long
terme pour le thème de la mobilité ». Dans l’environnement agile, je considère
les dispositions actuelles de la législation sur les marchés publics (LMP/OMP)
comme un obstacle. Nous perdons beaucoup de temps et de flexibilité.

Regrettez-vous quelque chose de l’ancienne méthode ? Quelle en est la conséquence ?
Je ne regrette rien ! Nous devrions devenir agiles encore plus radicalement
et rapidement. Une possibilité serait la délocalisation de projets dans des «
incubateurs », voire la création de spin-off (séparation de la maison mère et
des processus de base). Mais cela est difficile dans les grandes entreprises.

Quel devrait être l’objectif à long terme : tout agile ou le meilleur des deuxmondes ?
Je suis personnellement un partisan résolu des procédures agiles. Je connais
des projets qui ont échoué avec la méthode en cascade et qui n’ont dû leur
salut qu’à la méthode agile. Ce qui me plaît surtout, c’est que la méthode
agile est centrée sur les personnes et l’équipe. C’est pour moi le véritable
facteur de réussite des projets TIC et des projets d’organisation.
Mais cela ne signifie pas qu’il faille abandonner tout contrôle. On aura toujours
besoin de la gestion des risques et de la gestion de la qualité, mais elles
devront être « intelligentes » et « légères » (pas policières : le document X estil
disponible ? La structure du sommaire du document Y est-elle correcte ?)
Actuellement, aux CFF, un chef de projet fonctionne comme « traducteur »
dans le monde conventionnel. Il joue dans les set-up agiles les rôles classiques
du SCRUM master ou du product owner, mais il est aussi responsable
de l’intégration du projet dans les structures supérieures.
L’important, c’est que l’objectif d’entreprise et le point de départ soient clairement
définis. Il ne reste plus qu’à parcourir le chemin qui mène au but de manière agile !

Quelle est votre vision d’une gestion de programme agile idéale ? SAFE, SCRUM of SCRUMS ou éventuellement votre propre solution hybride ?
Pour « IC+ », j’avais espéré travailler encore davantage sur ces sujets. Nous
avons encore du potentiel dans ce domaine.
Ma vision est la suivante : toutes les personnes (product owner, IT facilitator,
teams) savent dans quelle direction le programme est piloté (phare) et ce
que chacun doit fournir. Tous les projets, y compris les projets partiels, savent
ce qu’ils ont à fournir et contribuent au succès global. Les décisions sont
toujours prises dans l’intérêt de l’objectif supérieur. C’est comme en hockey
sur glace : outre un gardien solide, chaque équipe compte quatre lignes
qui contribuent toutes au succès de l’équipe. La quatrième ligne est aussi
importante pour le succès collectif que la première, même si sa contribution,
vue de l’extérieur, n’a rien de spectaculaire.

Que recommandez-vous aux autres entreprises ?
Misez sur l’agilité ! Une étude classique est éventuellement nécessaire avant
le début d’un projet, mais il faut ensuite passer le plus rapidement possible
en mode agile. Nous n’avons pas encore trouvé de projet (TIC ou organisation)
qui soit incompatible avec l’agilité.
Décidez au plus vite si un projet est une « réussite » ou un « échec ». Cela implique
qu’il faut aussi savoir, le cas échéant, interrompre un projet, et même
le plus tôt possible. Mais l’interruption doit être apprise et exercée. Derrière
tout cela, il y a un changement de culture : la réussite d’un projet et la réussite
de la gestion d’un projet ne sont pas la même chose.

Ma dernière recommandation : la mise en place d’une structure agile dans
une entreprise est relativement rapide. Mais il ne faut en aucun cas sous-es-
timer le travail que requiert ce changement. Le passage à l’agilité n’est pas
facile et doit être accompagné. Nombreux sont ceux qui ont de fausses attentes
envers la méthode agile. Le véritable déclic intervient souvent quand
on devient soi-même membre d’une équipe.

Monsieur Krähenbühl, merci sincèrement pour cet entretien aussi passionnant qu’instructif.

À propos d’ « IC+ »

Le programme « IC+ 2017/2018 » est la suite du projet « IC+ » (information
clientèle plus) lancé en 2015 et achevé en 2016. Le succès de la première
partie du programme a conduit à la prolongation du format, auquel on a
assigné de nouveaux objectifs : la promotion de la mobilité combinée et la
personnalisation et le développement des unique selling points (USP), qui
devraient différencier les CFF de la concurrence. Les CFF désirent intégrer les
derniers kilomètres dans la planification et le conseil de voyage (trafic individuel).
Leurs mots clés à ce propos : simplicité, personnalisation, réseau.

Mélange de classique et d’agile Exemple pratique

Adaptation des rôles
Comme certains offices, pour lesquels le CSI-DFJP réalise des projets et développe
des applications, travaillent de manière plutôt classique avec HERMES 5.1, l’
« Agile Guide » dont il est ici question n’est pas une pure approche
SCRUM. Le CSI-DFJP agit en tant que prestataire de services (PS), alors que
les offices sont des acheteurs de prestations (AP). Ces interdépendances se
reflètent dans l’ « Agile Guide », dans la mesure où les rôles SCRUM sont attribués
aux rôles d’HERMES (voir tableau 3). En l’occurrence, le proxy product
owner intervient comme suppléant là où l’acheteur de prestations ne peut
pas assumer lui-même le rôle du product owner.

Fonctionnement
Le SCI-DFJP réalise principalement pour ses acheteurs de prestations des
projets partiels, qui sont concentrés sur l’intégration, le développement ou
l’extension de logiciels au sein du DFJP. La direction générale du projet est la
plupart du temps établie chez l’acheteur de prestations, p. ex. l’Office fédéral
de la police, le Secrétariat d’État aux migrations ou l’Office fédéral de la
justice, qui travaillent conformément aux exigences classiques d’HERMES 5.1.
Le SCI-DFJP élabore certains projets partiels avec l’approche agile disponible
dans HERMES 5.1, qui a été adapté aux besoins du DFJP. Au sein de l’administration
fédérale, la responsabilité de la définition des procédures revient aux
offices. À la Confédération, on trouve donc plusieurs unités organisationnelles
orientées agilité, mais qui n’optent pas pour une approche complètement
agile. Ce mélange pertinent de classique et d’agile est rassemblé dans un
modèle hybride permettant des variations entre les différents offices.

Défis
Le fait qu’une telle configuration puisse provoquer des problèmes n’a rien
d’étonnant. L’un d’entre eux est la dépendance à l’égard de la spécification.
Si la spécification du résultat du projet ne peut pas être répartie entre les
différents sprints, comme SCRUM l’exige, la mise en oeuvre d’une approche
agile n’est guère possible. D’autres difficultés apparaissent dans l’approche
sprint : la procédure de projet adaptée doit être ancrée au sein de l’équipe
SCRUM. Il faut par conséquent accorder une attention suffisante à la gestion
du changement aux niveaux de l’organisation et du personnel.

Pour les modifications d’exploitation, le SCI-DFJP formule par ailleurs des
exigences à respecter impérativement en matière de durée de traitement
et d’installation dans les domaines de l’intégration et de la formation. Une
installation immédiate de la part de la production (continuous delivery), courante
dans le monde agile, demande toujours un gros travail d’explication.
Comme c’est le cas dans de nombreuses entreprises privées, les nouvelles
versions sont installées et testées dans les secteurs de l’intégration et de la
formation avant leur mise en service.

Finalement, les conditions cadres en vigueur dans l’administration fédérale limitent
les compétences nécessaires de l’organisation SCRUM. Le time-to-market,
au sens d’une augmentation du chiffre d’affaires en cas de mise en service
précoce, n’est pas un élément moteur, car la date de lancement est la plupart
du temps définie (p. ex. le jour de l’entrée en vigueur d’une nouvelle loi).

Succès
La mise en oeuvre des projets pilotes en liaison avec le SCRUM fait des progrès.
Tous les participants au projet connaissent la méthode de travail et se
sont préparés aux exigences et aux problèmes liés à ce type de réalisation de
projet. Une bonne relation entre le chef de projet de l’acheteur de prestations
et le chef de projet (partiel) du SCI-DFJP est la condition de base du succès.
Du côté du SCI-DFJP, la collaboration et la répartition des tâches sont organisées
à l’aide de JIRA. Cette application web permet d’accéder sans problème
aux projets SCRUM, de définir les sprints et d’établir des budgets de travail. Il y
est également très facile de relever le travail effectif et d’assurer le controlling
des activités (approximativement sous forme d’une analyse earned value).
Les projets pilotes profitent de l’approche agile dans la mesure où les exigences
de l’acheteur de prestations sont développées en incré ments, c’est-à-dire
en résultats opérationnels testables par le prestataire de services. Le chef de
projet de l’acheteur de prestations accorde l’autorisation d’installation des
paquets livrés dans les environnements suivants (p. ex. formation ou production)
dès qu’une utilité est générée pour l’utilisateur. En général, cet examen
de l’utilité se déroule dans le contexte des tests d’intégration.
Pour tous les projets réalisés au SCI-DFJP en suivant l’approche agile, on
relève une plus forte acceptation des résultats fournis du côté de l’acheteur
de prestations. Cet avantage est imputable dans une large mesure à une
meilleure communication en continu et à la livraison de petits incréments
(l’acheteur voit plus rapidement ce qu’il reçoit).

Succès
La mise en oeuvre des projets pilotes en liaison avec le SCRUM fait des progrès.
Tous les participants au projet connaissent la méthode de travail et se
sont préparés aux exigences et aux problèmes liés à ce type de réalisation de
projet. Une bonne relation entre le chef de projet de l’acheteur de prestations
et le chef de projet (partiel) du SCI-DFJP est la condition de base du succès.
Du côté du SCI-DFJP, la collaboration et la répartition des tâches sont organisées
à l’aide de JIRA. Cette application web permet d’accéder sans problème
aux projets SCRUM, de définir les sprints et d’établir des budgets de travail. Il y
est également très facile de relever le travail effectif et d’assurer le controlling
des activités (approximativement sous forme d’une analyse earned value).
Les projets pilotes profitent de l’approche agile dans la mesure où les exigences
de l’acheteur de prestations sont développées en incré ments, c’est-à-dire
en résultats opérationnels testables par le prestataire de services. Le chef de
projet de l’acheteur de prestations accorde l’autorisation d’installation des
paquets livrés dans les environnements suivants (p. ex. formation ou production)
dès qu’une utilité est générée pour l’utilisateur. En général, cet examen
de l’utilité se déroule dans le contexte des tests d’intégration.
Pour tous les projets réalisés au SCI-DFJP en suivant l’approche agile, on
relève une plus forte acceptation des résultats fournis du côté de l’acheteur
de prestations. Cet avantage est imputable dans une large mesure à une
meilleure communication en continu et à la livraison de petits incréments
(l’acheteur voit plus rapidement ce qu’il reçoit).

Conclusion
L’approche hybride convient en principe à l’environnement de la Confédération
et produit de bons résultats. Les personnes concernées sont convaincues
par la voie empruntée et adaptent la procédure à chaque projet. Dans le
domaine de la mise en service, l’efficience est augmentée par l’engagement
d’une équipe DevOps. Cela vaut particulièrement pour les petits projets ou
les projets auxquels participent des fournisseurs extérieurs, chez lesquels
les résultats doivent « seulement » être installés et intégrés. L’acceptation de
l’agilité au sein de l’administration fédérale pourrait encore s’accroître grâce
à des formations aux méthodes agiles, ce qui influencerait finalement positivement
l’accomplissement de projets.
Les premières étapes ayant été franchies avec succès, il ne reste maintenant
plus qu’à aborder les suivantes.