“I want to run an agile project”
https://www.ibm.com/developerworks/community/blogs/julian/entry/iwanttorunanagileproject?lang=en par Julian Holmes
Prologue
Comme la valeur des pratiques Agile est mieux comprise, de courageux chefs de projet commencent à défier les pratiques normales de l’organisation et demandent l’opportunité d’adopter une approche plus agile.
Dans les films animés “I want to run an agile project” (par Carson Holmes et Julian Holmes (Julian) ), nous suivons les expériences de Luke, un tel chef de projet courageux, et nombre de ses différentes rencontres partout dans l’entreprise, comme il travaille pour mettre en place et livrer son projet Agile.
Après avoir observé son voyage tristement distrayant, dans cet article nous expliquons ce qui se passe vraiment, et commençons à mettre en évidence les raisons qui se cachent derrière ses ennuis et comment une organisation peut les surmonter.
Scène 1 – la Partie prenante
Établir qu’il y ait un besoin business d’investir dans un projet est seulement le début de travail avec la partie prenante. Ils peuvent penser qu’ils savent de quoi ils ont besoin, ils pensent probablement qu’ils savent à quoi ressemble la solution, mais quoi qu’ils pensent savoir, ils doivent travailler avec l’équipe projet pour faire du projet un succès.
Ceci est où tant de projets s’engluent. Ils supposent qu’ils peuvent définir et communiquer clairement leurs besoins à l’équipe projet via un document sur leurs perceptions de ce que fera le système: "un seau de « doit faire ceci »"! Ceci réussit rarement.
Cependant, établir une Vision commune et une relation de travail proche avec la partie prenante et leurs utilisateurs métier permettra au projet de commencer rapidement, de collaborer avec les parties prenantes pour identifier des besoins critiques et de travailler pour livrer rapidement un retour sur investissement pour le business.
Sans cette collaboration, les « doit faire ceci » tourneront rapidement en suppositions, les spécifications en spéculations et nous aurons une forte probabilité que tout effort investi ne livrera pas ce que la partie prenante considère vraiment nécessaire.
Scène 2 – Approvisionnement
L’établissement d’un besoin business et avoir des parties prenantes désirant s’engager sur le projet est un bon début, mais ceci nous amène typiquement au besoin de compléter des procédures de financement, que ce soit à travers des équipes d’acheteurs externes, ou des PMOs internes.
Ces équipes veulent savoir ce qu’elles financent et ce qu’elles obtiendront pour leur argent.
Malheureusement, ils fonctionnent typiquement sur des suppositions simplistes telles que le business connait tous les détails de ce dont ils ont vraiment besoin à l’avance et que les besoins business ne changeront pas pendant la vie du projet.
Faire évoluer leur mentalité vers un engagement sur seulement de petits investissements et observer les retours sur investissement avant d’investir de nouveau peut sembler facile. Mais, quand les organisations n’ont jamais expérimenté d’un rapide ROI auparavant, elles s’attendent à ce que chaque projet traîne dans le temps et livre tard des résultats décevants.
Les gens des approvisionnements/achats doivent être courageux et poser quelques questions difficiles aux projets à livrer :
- Et si nous avions à couper le financement au milieu du projet ?
- Pouvons-nous confirmer de premiers revenus business qui financeront le reste du projet ?
- Pouvons-nous financer progressivement votre projet sur la base de résultats démontrés ?
Notre chef de projet Agile serait heureux de répondre à ces questions.
Partenaire de DantotsuPM
Scène 3 – Gouvernance et conformité
Il y a de bonnes raisons pour lesquelles les organisations ont fondé cette gouvernance et ces équipes de conformité. Les règles de conformité réglementaire de l’industrie doivent être respectées et bien des organisations se sont brulées les doigts avec des projets, typiquement avec la méthode dite "en cascade", aussi, des filets de sécurité ont été exigés pour protéger le business de projets dévoyés et dangereux.
Cependant, ces règles de gouvernance peuvent aussi empêcher le projet d’utiliser des pratiques fructueuses et de mettre en application certaines des pratiques que les règles de gouvernance essayent d’éviter!
Des améliorations progressives du succès de livraison peuvent être réalisées en mettant en application des mesures draconiennes sur les projets. Mais faire une évolution radicale dans le succès des projets exige un changement plus significatif : une livraison progressive et agile.
Comprenez-nous bien, il n’y a rien de mal à poser des questions au projet comme :
- "pouvez-vous prouver que vous comprenez nos besoins ?"
- "pouvez-vous démontrer que vous avez une solution saine qui répondra à ces besoins ?"
- "comprenez-vous les risques impliqués et pouvez-vous montrer comment vous les surmonterez ?"
- "pouvez-vous démontrer que votre solution respecte les attentes des parties prenantes ?"
- etc.
Cependant, le plus souvent, l’équipe de gouvernance a demandé sur ce sujet de la documentation pour supporter les réponses à ces questions par opposition à la preuve, à l’évidence concrète que l’équipe délivre ces résultats.
Revenir sur l’objectif du "point de contrôle" permettra typiquement à une équipe agile d’établir quelles mesures de progrès elle doit présenter pour fournir de meilleures mesures du réel progrès qu’une preuve écrite typique ne pourra jamais fournir.
Scène 4 – Architecture d’entreprise
Il y a beaucoup de valeur dont n’importe quel projet peut tirer profit à travailler avec l’Architecture d’Entreprise (EA) : Compréhension des technologies stratégiques de l’organisation; Établissement des besoins non-fonctionnels et techniques du projet; Alignement sur les autres systèmes de l’entreprise; Retours sur la vision technique du projet; pour en citer seulement quelques-uns.
Cependant, l’EA ne devrait pas chercher à définir le détail de la solution que l’équipe doit déterminer et livrer. Elle devrait ressembler à une partie prenante; aider à définir des besoins, à valider la valeur business et collaborer régulièrement avec l’équipe.
De cette façon, l’EA fournit une source de valeur de gouvernance technique stratégique et d’alignement sur la stratégie d’affaires.
Livrer un gros design d’entrée de jeu mène seulement à la spéculation et à la preuve par la documentation qu’une solution technique fonctionnera. Il vaut mieux démontrer une architecture exécutable et les équipes EA seront d’accord quand elles commencent à se rendre compte qu’il est possible de travailler de cette façon.
Scène 5 – équipe de développement
Non, tout sur le projet ne sera pas techniquement facile. Beaucoup de choses demandées à l’équipe projet seront nouvelles pour elle. Les développeurs auront des expériences différentes et la meilleure manière de surmonter les défis pour l’équipe sera de les encourager à collaborer.
Malheureusement beaucoup de membres d’équipes de développement ont eu des carrières où ils ont été encouragés à agir comme des héros. Ils ont été mesurés par leur performance individuelle et non par le succès de leur équipe projet.
Quand la livraison régulière de réussite démontrable devient importante, l’équipe a besoin à reconnaître ceci et chaque fois que des défis techniques surgissent, de travailler collaborativement pour trouver une solution. Ceci sera d’autant plus efficace que cela permettra de construire un sentiment d’équipe.
Le « Pairing » est une approche pour réaliser ceci, mais ce n’est pas exigé tout le temps, seulement quand quelqu’un sur l’équipe éprouve une difficulté et demande de l’aide. Alors un membre de l’équipe offrira son aide, aussi longtemps que durera le défi.
Scène 6 – Déploiement
Il n’est pas étonnant que les équipes de déploiement considèrent les équipes de développement avec prudence. Ils ont si souvent été en réception de solutions exécutables qui ont été précipitées dans le déploiement, mal évaluées, et pas conçues pour supporter efficacement un environnement de production. Cependant, si elles sont traitées comme une autre partie prenante du projet, on peut facilement répondre à leurs besoins et ainsi apaiser leurs craintes.
On s’attend aussi à ce qu’ils protègent le business et quand les projets ont rarement répondu aux attentes, ils se méfient beaucoup des nouvelles solutions qui sont fréquemment livrées et s’attendent à un déploiement fréquent. L’engagement régulier de l’équipe de déploiement dans le projet, leur permettre de voir les tests de pré-déploiement réussis et leur démontrer un plan de déploiement qui marche, aidera l’équipe à gagner leur confiance pour prévoir les déploiements fréquents de l’équipe Agile.
Scène 7 – Acceptation de la Partie Prenante
Au moment où l’équipe projet Agile est prête à déployer une solution qui ajoute de la valeur au business, il ne devrait y avoir aucune surprise pour le business sur ce qui va arriver. Leur participation continue en tant que membres de l’équipe projet et/ou leur présence aux démonstrations régulières, devraient leur fournir de suffisantes opportunités de s’assurer que le projet livre ce dont ils ont besoin, même si leur besoin a changé ou s’ils étaient incertains de ce qu’ils voulaient avant de l’avoir vu pour la première fois.
Cependant, même dans le scénario catastrophe où les parties prenantes voient seulement la solution à l’instant où une première solution de base pourrait être déployée, ils peuvent tout de même changer le cours du projet beaucoup plus tôt que ce ne serait possible avec un cycle de vie plus traditionnel.
Épilogue
Notre courageux chef de projet, Luke, a vraiment réussi à faire adopter son projet Agile par l’organisation, et même si ce fut un voyage pénible, ça en valait la peine. Le client a vraiment reçu de la valeur très tôt et Luke a établi un précédent avec beaucoup d’autres fonctions de l’organisation.
Au fil du temps il trouvera que le reste de l’organisation commence à reconnaître la valeur de l’approche Agile et des barrières tomberont ou seront ajustées pour apprécier la livraison de valeur au plus tôt.
Cependant, ce processus prendra du temps et cela nécessitera plus que les seuls efforts de Luke pour réaliser ce changement.
