Régulièrement, les praticiens de la gestion de projet cherchent à opposer les approches entre elles. Dans notre démarche de management de projet par le flux, nous faisons régulièrement face à ce phénomène :
« Si nous sommes certifiés de cette méthode, c’est que les autres méthodes ne sont pas adaptées pour nous. »
« Nous, nous sommes différents, donc aucune méthode n’est vraiment applicable », etc.
De plus en plus de clients que nous rencontrons utilisent des approches dites AGILE.
Nous entendons très souvent des remarques du type ; « Au début le projet n’était pas sous pression, nous avancions avec notre approche en réalisant des sprints. Puis au bout de quelques temps, le comité de direction est venu imposer des dates de fin à nos tâches et l’approche AGILE a volé en éclat ».
Ce retour est un peu déconcertant car il n’est pas en ligne avec les principes fondateurs de cette approche. Il nous semble important de rappeler qu’à aucun moment les approches dites AGILE n’indiquent de s’affranchir des dates demandées par les clients externes et internes.
Mais il arrive parfois que les méthodes touchent certaines limites, nécessitant alors d’être combinées avec d’autres approches.
Récemment lors d’une de nos missions, nous avons été confrontés à ce phénomène. Nous avons transformé une partie de l’organisation avec un barycentre chaîne critique. Les résultats ont été très positifs car ils ont permis de réduire les délais par 4 et d’assurer un taux de service sous contrôle.
Dans cette organisation, une partie des données d’entrée est générée par des fonctions dites créatives – notamment le marketing. En effet, cette dernière fournit ses idées à la fonction suivante afin qu’elles puissent être conçues. Dans cette relation, quelques caractéristiques sont à prendre en compte :
- Les données d’entrée ne sont jamais vraiment figées et ne peuvent pas l’être.
- Une attention très forte est portée à l’esthétisme ce qui peut avoir pour conséquence de stopper le projet à n’importe quel moment
- L’idée même d’avoir un planning est antinomique avec tout processus de création.
Lorsque vous mettez ces deux organisations si différentes l’une de l’autre, vous devez faire face à quelques conséquences négatives :
- L’équipe avale se plaint qu’elle n’a pas assez de temps pour développer l’idée.
- L’idée n’est pas perçue comme claire par rapport aux besoins en données d’entrée.
- Les données d’entrée sont jugées peu pertinentes par l’équipe amont.
- Le processus de création devient une forme de boîte noire de justification à tout évènement actuel ou futur retard.
Dans cet environnement, la chaîne critique n’est pas applicable en l’état et doit être recomposée.
En effet, il ne peut y avoir de vrais plans de projet avec un processus de création. A partir de là, la planification et le suivi de l’exécution nécessitent d’être réadaptés.
Des équipes japonaises ont d’ailleurs rédigé un livre combinant ces deux approches : AGILE & CCPM [A]. Ces équipes revoient en profondeur une notion fondamentale : le Project Network Diagram (cf Newsletter précédente) et proposent une combinaison avec les pratiques AGILE dans la phase d’exécution.
Dans cette approche, le Network Diagram va inclure les principes de l’AGILE dans les notions de Story Point couplées aux Features. L’approche proposée consiste à identifier les grandes caractéristiques du produits. Par exemple, sur une souris d’ordinateur, nous pourrions imaginer :
- L’ergonomie
- Le nombre de fonctionnalités
- L’alimentation
- Le design général
Lors de la phase de création, vos équipes vont probablement imaginer un produit qui va avoir des poids plus forts sur ces critères. Nous allons donc mettre un poids sur ces 4 grands critères. Puis l’équipe va imaginer l’ensemble des caractéristiques qu’elle voudrait voir dans cette souris.
Ces caractéristiques vont être positionnés dans ces critères puis les poids précédents seront dilués dans ces caractéristiques.
Ainsi au lieu d’avoir un plan de projet classique avec ses liens, ses durées, nous avons un ensemble de caractéristiques avec des poids.
Dans la phase d’exécution, il est proposé d’utilisé la notion de vélocité, propre à l’AGILE :
Le nombre de points d’effort « terminés » au cours d’un sprint (ce qui est entendu par « terminé » est défini par l’équipe).
Il s’agit d’un indicateur qui a pour but d’aider l’équipe de développement lors des séances de planification de sprint (« Sprint Planning ») à évaluer la quantité de travail qu’elle peut sélectionner pour le sprint.
Cet indicateur peut être utilisé par le Product Owner pour l’aider à planifier les livraisons, et ce, à condition de prendre en compte le cône d’incertitude associé.
Ainsi nous avons un plan de projet avec les poids ainsi que la vélocité de l’équipe. Nous pouvons donc découper notre projet en somme de caractéristiques.
Nous pouvons également décider d’un buffer à la fin de cet enchaînement. Le calcul du buffer se fait de la même manière sauf que son unité évolue ; il ne s’agit plus d’un temps classique mais de la combinaison entre le temps et la vélocité de l’équipe.
Dans les faits, lorsque le buffer est dans le Jaune ou Rouge, l’équipe doit prendre des actions pour se faire aider. Ou alors elle peut « sacrifier » quelques caractéristiques avec des poids moins importants. Ainsi l’équipe sait ce qu’elle met en péril sans pour autant mettre en péril les jalons fixés par la direction.
En conclusion, comme souvent en terme de méthodes, il n’y pas une voie unilatérale mais plusieurs qui se combinent entre elles.
Cette approche dite AGILE/CCPM a permis de réaliser un certain nombre de projets avec des cahiers des charges très limités voire inexistants. Le seul trait commun entre ces deux approches, c’est qu’elles apportent une forme de cadre plus ou moins grand. Ce cadre est très souvent un retour que nous recevons tant les équipes sont parfois perdues entre les priorités, les changements de cap et les aléas d’un projet 😉.
Références :
[A] Agile CCPM: Improve organizational performance significantly by making small changes in managing projects (English Edition) de Koichi Ujigawa
[B] Savoiragile.com : http://savoiragile.com/2015/02/12/la-velocite-une-mesure-utile/