On n'est pas agile… avec une cascade agile

Beaucoup d'organisations se qualifient elles-mêmes d'agiles. Qui ne voudrait pas être agile ? Si on n'est pas agile, n'est-on pas par définition lourd, lent et léthargique ?

Peu d'organisations se décriraient ainsi ; cependant, dans le monde du développement, de l'amélioration et de la maintenance logicielle, Agile signifie bien plus que simplement pouvoir agir rapidement et avec légèreté. Agile signifie qu'une équipe ou une organisation adopte certains principes qui façonnent les comportements et conduisent à l'intériorisation de certaines méthodes.

Quand les actes ne correspondent pas aux paroles, c'est souvent le management qui fait obstacle aux principes et les praticiens aux méthodes. Les méthodes dans les organisations sont souvent très ancrées et nécessitent un effort de changement considérable. Certaines organisations prétendent utiliser une approche mixte, passant d'une approche plus classique à une combinaison de Scrum, Kanban et Extreme Programming. Cela est perçu comme une approche plus sûre et conservatrice qui permet à une organisation de changer de manière organique. Le problème, cependant, est que cette tactique fonctionne rarement et que les organisations se retrouvent rapidement enlisées. Si on n'investit pas suffisamment de temps et d'efforts dans la gestion du changement, cela conduit rapidement à des frameworks hybrides qui ne sont ni chair ni poisson – et ceux-ci sont très rarement agiles.

Caractéristiques des organisations enlisées (ou potentiellement enlisées)

Le cycle en cascade itératif :

Le cycle en cascade itératif classique trouve ses racines dans le modèle en spirale de Barry W. Boehm. Dans cette pseudo-version du développement itératif, des itérations courtes et limitées dans le temps sont utilisées pour chacune des phases classiques du cycle en cascade. Un sprint de recueil des exigences est suivi d'un sprint de conception, puis d'un sprint de développement, etc. Le modèle en spirale classique comme la pseudo-version d'Agile sont tout de même bien plus adaptés que le modèle en cascade classique pour générer du feedback et livrer de la valeur plus rapidement ; cependant, les organisations cessent alors de progresser vers l'Agile et ne récoltent qu'une partie des bénéfices.

Fixer les exigences en amont :

Dans cette approche hybride de l'Agile, les équipes ou organisations rassemblent toutes les exigences (parfois appelées fonctionnalités) au début du projet et les figent avant que le travail réel ne commence. L'Agile repose sur certaines hypothèses concernant les exigences. Deux des principales hypothèses sont que les exigences émergent constamment et qu'elles disparaissent avec le temps une fois connues. Figer les Product Backlogs à l'avance contredit ces deux hypothèses. De plus, cela ramène les équipes et organisations à une époque où l'on développait des solutions qui ne correspondaient finalement pas aux besoins métier actuels. Cette approche existe généralement lorsque l'adoption de l'Agile se fait par étapes, en commençant par les développeurs puis en intégrant plus tard les Business Analysts, etc. Des frictions supplémentaires peuvent souvent apparaître entre les groupes qui ont intégré l'Agile et ceux qui ne l'ont pas fait, ce qui est fréquemment imputé aux méthodes agiles et complique ainsi les changements ultérieurs.

Tester après que le développement est « done » :

L'une des formes hybrides agiles les plus dangereuses est le test après la fin du développement. J'ai déjà rencontré cette forme hybride sous le nom de « Développement + 1 Sprint ». Dans ce scénario, une équipe développe une solution (du code fonctionnel pour un problème logiciel), la présente aux clients, affirme qu'elle est « done » et ENSUITE la transmet aux testeurs. Les testeurs trouvent TOUJOURS quelque chose. Le logiciel est donc renvoyé pour qu'on y travaille directement (ce qui perturbe le sprint en cours) ou pour être déplacé dans le backlog afin d'être traité plus tard. Les principes agiles soutiennent la livraison de logiciels livrables (ou au moins potentiellement livrables) à la fin de chaque sprint. Livrable signifie TESTÉ. Deux variantes moins dramatiques de ce problème sont l'utilisation de Hardening Sprints et le test tout à la fin d'un projet. Au moins, dans ces cas-là, on ne prétend pas être agile.

Conclusion sur agile et cascade

La façon dont les gens travaillent est le seul indicateur fiable pour savoir si une organisation est agile ou non. Parfois, la façon de travailler de ces personnes reflète une transition vers l'Agile – cependant, je suppose que l'on finira par s'enliser si cette transition n'est pas menée avec beaucoup d'enthousiasme. Quand une équipe ou une organisation veut adopter l'Agile, on choisit un projet et on fait travailler toutes les personnes impliquées dans ce projet avec l'Agile simultanément et tout au long du processus. Si cela signifie qu'il faut coacher un projet entier ou une équipe entière, alors soit. On peut comparer cette approche à un oignon que l'on coupe en tranches et où chaque coupe atteint chaque couche de l'oignon, au lieu d'éplucher couche après couche.

Une dernière remarque : même si ces approches hybrides atteignent un jour leurs limites, elles sont probablement toujours meilleures que la ou les méthodes utilisées auparavant. Ceci n'est pas un réquisitoire contre les personnes qui ont du mal à passer à l'Agile. C'est plutôt un encouragement à continuer.

Ce texte provient du blog de SPamCAST et a été traduit par nos soins en allemand.