Maîtriser les projets agiles

Une approche de projet agile est contemporaine et est postulée comme une panacée. Quelle entreprise ne veut pas être agile ? Cependant, le changement vers une agilité (partielle) dans une organisation nécessite deux circonstances fondamentales :

• Cela doit en valoir la peine : Avec des procédures agiles, de meilleurs résultats de projet sont obtenus ou les résultats du projet sont amenés plus rapidement à la maturité du produit avec une acceptation suffisante.
• Cela doit être possible : Les approches agiles nécessitent de sérieux ajustements de la culture organisationnelle, c'est-à-dire de l'attitude et du comportement des personnes à tous les niveaux de la hiérarchie. En outre, il doit être possible d'étendre itérativement le résultat d'un projet et de le mener progressivement à maturité.

Entrer dans le détail de tous les aspects d'une transformation agile réussie dépasserait le cadre de cet article. Les conditions préalables les plus importantes sont résumées dans le tableau 1. Il faut également tenir compte du fait que tout changement dans une organisation - y compris celui qui vise à l'agilité - nécessite beaucoup de temps de maturation en plus d'une bonne préparation et d'une bonne mise en œuvre.

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 de cœur et d'âme et une gestion prudente du changement. Cependant, la pleine expression de l'agilité ne s'adapte pas à tous les environnements. Fondamentalement, nous voyons trois modèles différents pour l'application de l'agilité dans les organisations (voir Fig. 1) :

1. Le modèle hybride : des projets agiles combinés à une gestion classique de portefeuille de projets et de programmes
2. Le modèle bi-modal (également appelé à deux vitesses) : les projets classiques et agiles coexistent et sont priorisés par la gestion classique ou agile du portefeuille de projets et des programmes.
3. L'agilité complète : les approches de gestion agiles au niveau du portefeuille de projets, des programmes et des projets

Les éléments classiques et agiles peuvent être bien combinés et atteindre ensemble une grande efficacité. Le mélange de modèles est soit l'objectif final, soit une étape intermédiaire sur la voie de la transformation agile. Il n'y a pas de bien ou de mal, mais seulement une adaptation meilleure ou pire aux besoins et aux capacités d'une organisation.

Opportunités, risques et qualité
Dans notre travail avec les clients, nous sommes souvent confrontés à des questions telles que : les opportunités, les risques et la gestion de la qualité sont-ils même prévus dans le monde agile ? Comment pouvons-nous nous assurer que notre projet n'échappe pas à tout contrôle ? Qui est responsable s'il n'y a pas de chefs de projet classiques ?

L'approche agile traite implicitement les opportunités et les risques de manière active et répétée : avec des réunions régulières (Planification Sprint, SCRUM quotidienne, Rétrospective Sprint) et des Revues Sprint. Nous recommandons d'accentuer les opportunités et les risques de manière à ce que le propriétaire du produit conserve et évalue ses propres arriérés d'opportunités et de risques. Les éléments correspondants de l'arriéré peuvent être inclus dans la planification du sprint en tant que besoins. Cela présente l'avantage que le traitement des opportunités et des risques s'intègre naturellement et de façon naturelle dans le traitement opérationnel du projet. Les obstacles sont également détectés et résolus en temps utile. Ce processus est soutenu par le maître de la SCRUM dans son rôle central de recherche de solutions et d'élimination des obstacles.

La gestion de la qualité dans l'exécution de projets agiles est similaire (voir tableau 2) : la qualité doit être fournie en permanence. L'assurance qualité et les éventuelles corrections sont effectuées à chaque itération. La qualité est évaluée au moyen de critères d'acceptation préalablement définis pour les témoignages des utilisateurs. Le respect des critères génère des bénéfices commerciaux d'une part et garantit que la qualité requise est atteinte d'autre part.

À notre avis, les approches agiles fournissent de bons moyens de traiter les opportunités, les risques et la qualité plus fréquemment, de manière plus transparente et dans le cadre de rôles multiples. Nous avons eu une bonne expérience avec la recommandation de traiter explicitement ces questions.

Contrôle et rapports
Dans les projets gérés de manière classique, le contrôle basé sur les dimensions QUARZ (Q = qualité, U = portée, A = effort ou coûts, R = risques, Z = temps) est de plus en plus établi. Ces dimensions sont également présentes dans les projets agiles, mais sont traitées de manière implicite :

• Qualité : Les exigences de qualité font partie des critères d'acceptation. La réalisation et l'acceptation d'une histoire d'utilisateur dans un sprint inclut donc toujours la qualité en plus du bénéfice commercial.
• Portée : la portée de la livraison et l'étendue d'un projet sont déterminées par la gestion de l'arriéré et vérifiées lors de l'examen rapide - souvent en combinaison avec le contrôle des coûts.
• Coûts : Les coûts des projets ont tendance à être fixes, mais leur portée est modifiée.
• Risques : les opportunités et les risques se reflètent dans des arriérés distincts et sont automatiquement intégrés dans la planification du sprint.
• Temps : Les sprints sont chronométrés. Les écarts par rapport aux délais des projets ne se produisent que par l'exécution de sprints supplémentaires.

En raison de la tendance à fixer les coûts et à en varier la portée, le contrôle dans les projets agiles se réduit souvent au traitement de l'arriéré de produits et au nombre nécessaire de sprints. Grâce à une application adéquate des procédures de projet agiles, le contrôle au sein des différents sprints se fait quasiment en temps réel, ce qui augmente la transparence et la vitesse de réaction. D'autre part, nous constatons des faiblesses dans le contrôle des empreintes croisées liées à l'ensemble du projet. Étant donné que les investissements sont également réalisés dans des projets agiles, le contrôle des projets ne doit pas être négligé. Nous recommandons d'examiner attentivement toutes les dimensions du QUARZ, y compris la combinaison coût-scope.

En tenant compte des conditions d'application suivantes, nous avons eu une très bonne expérience de la méthode de la valeur acquise pour le contrôle et le reporting dans les projets agiles :

• Nous communiquons avec des graphiques dont les tendances peuvent être déduites.
• La courbe des valeurs planifiées est conçue comme une ligne droite sur l'ensemble ou une partie des sprints prévus. Il représente la somme de toutes les tâches nécessaires pour remplir les points en suspens dans le sprint respectif.
• Pour déterminer la courbe de valeur acquise, nous ne considérons que les tâches terminées (approche 0/100) de la planification du sprint.
• Pour la courbe des budgets brûlés, nous utilisons l'effort réel cumulé que l'équipe de la SCRUM fait par semaine.
• Pour rendre toutes les valeurs comparables entre elles, nous les présentons relativement en pourcentage.
• Les courbes de la valeur acquise et du budget brûlé sont tracées de manière à se chevaucher et sont donc comparables à la ligne droite de la valeur prévue.

La figure 2 illustre cette procédure. Les méthodes de valeur acquise ainsi adaptées permettent un contrôle de projet efficace et croisé et sont faciles à intégrer dans les rapports de projet. Le résultat est un aperçu significatif de l'avancement du projet (portée), des coûts du projet et de la tendance par dimension. Les autres dimensions du QUARZ sont directement liées à la portée et aux coûts et complètent le contrôle du projet.

Remarque : pour faciliter la transition vers les véritables "agilistes", nous renonçons généralement à la nomenclature de la valeur acquise, en étiquetant les courbes "progrès prévu", "progrès réel" et "effort réel", par exemple, et en nommant le graphique "graphique de l'épuisement du projet".

Conclusion
Les exemples ci-dessus montrent à quel point les méthodes/outils classiques sont précieux dans les procédures de projet agiles et qu'ils peuvent être bien intégrés. Selon notre expérience, des disciplines de gestion de projet correctement exécutées sont un facteur de succès intrinsèque malgré ou précisément à cause de l'agilité. Des organisations telles que l'International Project Management Association (IPMA) ou le Federal IT Steering Committee (FSUIT) ont intégré des approches agiles dans leurs normes actuelles de gestion de projet.

Nous savons comment les mondes parfois presque dogmatiquement séparés des approches classique et agile peuvent être combinés de manière profitable. Utilisez notre expérience à votre avantage.