Cet article est le dernier de la série consacrée aux pièges de la méthode agile. Après avoir vu les erreurs lors de la rédactions des user stories et celles lors des cérémonies agiles. Aujourd’hui nous allons nous consacrer aux erreurs commises lors de l’application des principes agiles.
Etre en mode mini-cycle en V plutôt que SCRUM
Etre en cycle itératif ou faire un mini cycle en V en l’espace d’un sprint n’implique pas être agile. En effet, cela va à l’encontre même de l’agilité ! Dans cette mise en pratique, l’erreur peut être expliquée par un certain nombre de points communs entre les deux méthodologies :
- Daily standup quotidien,
- Itération limitée dans le temps,
- Possibilité d’effectuer des changements de spécification en cours de route mais pas durant l’itération elle-même.
Au-delà de ces points communs, voyons quelles sont les différences.
Premièrement, les équipes scrum démarrent avec très peu de contrôle et de planification. Elles partent avec juste ce qu’il faut pour que l’effort de développement puisse commencer. Une fois que le logiciel commence à prendre forme, il est corrigé et ajusté au fur et à mesure.
Dans un cycle en V, les équipes passent un temps important en amont dans l’étude, l’analyse et la planification du projet. Rien ne démarre vraiment tant que tout le plan n’est pas en place.
Scrum garde en point de mire la livraison de fonctionnalité et de « valeur » au métier, ou aux utilisateurs à la fin de chaque sprint. Même si cet objectif n’est pas atteint au terme de celui-ci, cela reste une préoccupation constante dans la mise en pratique de l’agilité. Le cycle en V itératif tend à découper les fonctionnalités en morceaux de sorte à les faire tenir dans une itération, avec le risque toutefois de ne pas les rendre utilisable ou visible par le métier, jusque tardivement dans le projet.
Le workflow entre les deux méthodes diffère lui aussi. En Scrum, une User Story, une fois qu’elle est incluse dans un backlog de sprint à deux états « en cours » ou bien « effectuée ». En cycle en V itératif une fonctionnalité passe par les étapes bien connues : analyse, design, développement, intégration et test comme s’il s’agissait d’un seul bloc.
Une autre différence importante est la constitution des équipes et le rôle des éléments la composant. Scrum privilégie des équipes qui sont responsables de leurs projets et autosuffisantes dans leur capacité à fournir le produit désiré. A l’inverse, le mini cycle en V repose sur l’agrégation de plusieurs personnalités de différents départements (tels que gestion de projet, architecture, développeur, QA etc…) avec des liens hiérarchiques qui ne sont pas dans l’équipe mais au sein des départements respectifs. Le degré d’implication et les délimitations hiérarchiques peuvent être un frein à la fluidité de l’ensemble et s’oppose encore une fois à l’opposé de l’esprit agile.
Recommandation
Une transition agile dépasse souvent le simple fait d’organiser des cérémonies quotidiennes sur une base régulière ou la livraison de certains artefacts spécifiques à ce Framework. Il s’agit bien souvent d’une transformation profonde, organisationnelle, changement d’état d’esprit voire politique au sein d’une entreprise. Le livrable de fin de sprint ou la vélocité d’une équipe ne doivent pas être les seuls benchmarks qui servent d’indicateurs à une transition agile réussie ou non. Agile implique des changements profonds de mentalité dans la structure d’une entreprise qui bien souvent lorsqu’elles ne sont pas agiles, sont très hiérarchisées, cloisonnées et/ou rigides. L’un des nombreux freins étant la dissolution des structures de contrôle propres aux anciennes organisations.
L’agilité a pour corollaire de responsabiliser les équipes, les impliquer et les motiver afin de pouvoir les rendre meilleures. Elles brisent les murs hiérarchiques et rend les process plus visibles et transparents. C’est cette compréhension de l’agilité qu’il est important de faire passer au sein des acteurs de l’agilité en vue d’une adhésion pleine des premiers intéressés qui en seront les acteurs.
Il est tout à fait indispensable de prendre la mesure de ce bouleversement, notamment en terme de conduite du changement et des résistances, de se faire accompagner par des SM et des coachs agiles, aguerris et expérimentés.
Cela apparaît comme impératif afin que la transition puisse se faire de la manière la plus réussie et que la culture agile puisse être intégrée au mieux et que la formation des utilisateurs dans ce domaine soit réalisée.
Transformation agile mal préparée
Une transformation agile nécessite de consulter les ressources en personnel de l’entreprise, les processus, l’IT et déterminer où il est pertinent de mettre en œuvre l’agilité.
Il faut garder à l’esprit que l’approche agile, bien que prometteuse en terme de bénéfices, n’est pas une solution miracle. Il faut effectuer une évaluation des domaines les plus appropriés. C’est cette évaluation qui guidera ensuite la transition. Faire des itérations agiles mal encadrées peut se révéler inefficace et contre-productif. Une approche transitionnelle bien définie est indispensable.
Recommandation :
Pour être bien menée une transition agile doit s’axer autour de 3 points :
- La communication : elle doit être claire, cohérente et impliquer autant le métier, les équipes d’affaire que les équipes IT. La qualité de cette communication aura un impact important sur la compréhension de l’agilité et le niveau d’engagement des équipes concernées.
- Un sponsorship hiérarchique important. L’agilité doit être soutenue par la direction et le management de l’entreprise. Et se transmettre à la base afin de pouvoir emporter une forte adhésion et mobilisation.
- Une collaboration étroite entre le métier et les équipes IT, car seules les équipes IT peuvent mettre en place l’agilité. Cette collaboration doit se faire de manière continue et avec la participation de la direction.
Discuter de manière transparente et objective des apports et des inconvénients de la mise en place de l’agilité sans chercher à la « vendre » coûte que coûte.
Changement intempestifs
Selon le manifeste agile, l’une des valeurs est de privilégier la « Réactivité au changement plus que le suivi d’un plan. ». Le changement fait parti intégrante du développement, il faut l’accepter et mieux l’accueillir positivement.
Répondre positivement au changement du PO permet de faire évoluer le logiciel dans le sens désiré et ainsi augmenter les chances de satisfaction du client.
Cependant, si des changements sont trop nombreux et trop fréquents, cela peut mener à une frustration de l’équipe du développement aisément compréhensible.
Recommandations
Afin de ne pas de limiter ces changements mais de mieux les traiter, il peut être judicieux de mettre en place quelques précautions :
- Toujours écrire les demandes sous forme de US (« en tant qu’utilisateur je veux pouvoir effectuer telle action dans le but de »), sans négliger les « critères d’acceptance/condition de satisfaction » de ladite US : c’est indispensable. Cela aidera les développeurs et testeurs à se forger une idée claire sur ce que le client attend. La partie prenante qui est à l’origine de ce changement doit fournir cette US ou être impliquée durant l’affinement du backlog.
- Ne pas accepter de changement en cours de sprint. Ceci a pour conséquence de faire comprendre que tout ce qui est engagé est dû, que le pilotage trop changeant a un coût. Si une nouvelle demande est effectuée, l’estimer et l’inclure dans le sprint suivant.
- Accepter d’intégrer un changement dans un sprint en cours, mais en contrepartie faire sortir un ou plusieurs items équivalents, cette décision revenant à l’équipe de développement.
Conclusion
Les erreurs que nous avons vues dans les différents articles sont inhérentes à la pratique et font aussi parties de l’apprentissage. La démarche judicieuse qu’il peut être intéressant d’adopter serait identique à celle de l’amélioration continue du produit que Scrum entraine quand il est bien exécuté. Se pencher et se questionner sur la qualité de sa pratique agile permet une amélioration constante de cette dernière.
Enfin, l’agilité a une très forte incidence et portée sur l’état d’esprit et le management, voire « sociétale » au sein de l’entreprise. En prenant en compte cet aspect et en essayant de l’améliorer, l’agilité peut alors être correctement appliquée et tenir ses promesses en termes de bénéfices apportés.