L’agilité : une méthodologie ou un état d’esprit ?

De Adrien Orsier dans Méthodes et Organisation

1 juil 2013

Après 2 ans d’expérience, peut-on dire que l’agilité consiste en la mise en place d’une simple méthodologie ?

Les changements abondants et répétés de notre organisation pourraient laisser à penser que notre approche initiale n’a pas été la bonne. En effet, nous avons commencé par appliquer une méthodologie « à la lettre » prônée par un « expert de l’agilité » pour évoluer durant 2 années vers des process de plus en plus adaptés spécifiquement à notre contexte. Le sujet que je soulève ici est lié à notre perception d’une « méthodologie » et à ce qu’on doit en faire.

De l’importance du cadre

Le dogme agile

Nos premiers Sprints agiles ont consisté en une application stricto-sensu des « règles » qu’on nous avait édictées et dont nous nous faisions un devoir de respecter à la lettre.

Tant de rigidité pour l’application d’une méthodologie portant le nom « Agile » peut sembler contradictoire. Pourtant, avec le recul, je suis en mesure d’affirmer que cette étape est indispensable pour devenir Agile.

Si vous décidez de ne pas prendre l’aide d’un expert et d’initier votre dispositif agile seul en vous documentant, vous risquez d’adapter « à votre sauce » dès le départ les points qui vous semblent incohérents ou qui vous gènent. Ainsi, le risque est de rester dans les mêmes réflexes et contraintes sans regard extérieur sur vos pratiques. Les valeurs importantes de l’agilité risquent fort d’être oubliées ou dénaturées. Par exemple, on peut voir des équipes altérer directement la position de Scrum-master en lui donnant une dimension hiérarchique forte, ou encore ne pas laisser l’équipe de production s’auto-organiser.

Les méthodologies  « clef en main » des différents experts représentent  des condensés génériques et théoriques de ce qu’ils ont déjà vu fonctionner. Cette vision est basée sur l’expérience et sur une connaissance théorique très solide des concepts mis en avant par l’agilité (voir le manifeste agile qui édicte, entre autre chose,  12 points capitaux pour l’agilité dans une conduite de projet informatique => http://fr.wikipedia.org/wiki/Manifeste_agile).

De ce fait, chacun des points mis en avant par ces experts sont à considérer avec un regard extérieur. Mais ils sont d’abord à connaitre et à expérimenter, avant de les mettre de côté si vous considérez qu’ils ne correspondent pas à votre modèle d’organisation.

 L’objectif de la connaissance des principes de l’agilité est de mettre au centre de votre dispositif les valeurs fondamentales de cette approche, telle que l’importance des rétrospectives dans le cadre de l’amélioration continue. Grâce à ces bases saines et non biaisées, vous pourrez « mettre en route la machine » correctement.

Flux des échanges

Le rituel

Une composante primordiale de notre processus d’agilité est la manière dont il est ritualisé.

Les journées de travail démarrent toujours par un « daily-scrum » qui réunit l’équipe de production, et les itérations se terminent par des démos, suivies de rétrospectives.

La systématisation de ces évènements est vraiment une des clefs de la réussite de l’agilité.

En effet, le rituel a un effet structurant très fort. Ce sont des points fixes dans le déroulement de l’itération qui permettent de prendre du recul sur la production. Le rythme qu’ils engendrent est très important pour « garder le cap » dans son processus agile.

Il faut également toujours avoir en tête que « Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées » (issu du manifeste agile), or le rituel de fin d’itération, la démo, constituent justement des moments idéaux pour échanger avec l’équipe sur l’état de développement du produit.

Le produit est-il finalisé   ? Y a-t-il des parties fondamentales à améliorer pour qu’il soit utilisable ? Ce sont des questions que le PO sera amené à se poser, et les réponses en seront d’autant plus pertinentes s’il est aidé par les personnes qui ont développé son projet.

On voit bien que ces rituels sont des espaces d’échange qui, en plus de souder l’équipe, forment  un véritable terreau pour l’amélioration continue.

 

Apparitions des problèmes

 

C’est durant les rituels de scrum que les point à améliorer (qu’ils soient liés purement à de la production ou à de l’organisation) remonteront.

Ainsi, toute l’équipe de production sera au courant de problèmes répétés que pourrait rencontrer quelqu’un d’autre sur un point technique particulier.  Immanquablement, ce problème ressortira alors en rétrospective, et toute l’équipe, ayant été témoin de ce problème,  pourra réfléchir pour trouver une solution.

Car, une fois le cadre de base bien maîtrisé et compris par l’équipe de production, des problèmes inhérents à votre organisation apparaîtront immanquablement.

Ils peuvent être pléthores. En fait, on peut considérer qu’il y a autant de type de problème que d’équipe, puisque chacune d’entre elles a ses spécificités.

Chez nous, les problèmes principaux tournèrent autour de la maintenance (bloquante ou non) d’application existante et du contexte multi-projet / multi-techno.

Nous avons constaté au bout de quelques itérations que des aménagements allaient être nécessaires pour travailler plus sereinement et efficacement.

Cette démarche est saine. Mieux que ça, une fois le cadre de base mis en place, cette démarche est l’essence même de l’agilité. L’adaptabilité étant la force de cette organisation. Grâce à votre cadre, les problèmes remonteront naturellement en temps et en heure durant les rétrospectives. Il vous faudra alors vous adapter pour les surmonter. L’agilité n’est que perpétuelle amélioration et adaptation de votre organisation. Il n’existe pas de méthodologie idéale, même dans le microcosme de votre équipe.

Adaptations

Une fois les problèmes remontés, il est capital de leur trouver des solutions simples et pragmatiques.

La plupart du temps, de simples petits ajustements peuvent suffire. Par exemple, un ajustement de l’heure de la rétrospective pour que tout le monde puisse y participer, ou encore décider que toutes les démos seront faites sur IE7 pour prendre en compte les bugs d’intégration.

Mais parfois, pour imaginer des solutions, il faudra être imaginatif et ne surtout pas hésiter à remettre en question des thèmes considérés comme « fondamentaux ».  Si une pratique pouvait s’avérer indispensable hier, elle peut être inutile aujourd’hui, et il faut apprendre à avoir ce regard critique tout au long des proscess.

En l’espace d’un peu moins de deux ans, notre agilité s’est beaucoup écartée des règles qui définissaient son cadre originel. Toutefois, sans ce cadre initial, nous aurions eu bien du mal à avoir le recul et la maturité nécessaire à mettre en œuvre notre évolution.

Cela en sera certainement de même pour les règles qui établissent notre cadre aujourd’hui, car l’adaptation se doit d’être permanente dans un environnement sans cesse changeant tel que celui de l’informatique.

Conclusion

Au vu de notre expérience on peut dire que l’agilité se base sur une méthodologie structurée impliquant des règles d’usage collectif. Mais elle ne constitue pas une méthodologie en elle-même.

Elle implique une capacité à s’auto-organiser, et surtout à faire évoluer les process dans le bon sens, en y réfléchissant collectivement.

Il paraît souvent sécurisant de ne rien changer à une façon de faire lorsqu’on pense qu’elle est efficace, mais les contextes de projet évoluent continuellement, et l’équipe aussi. Cela implique forcément de mettre en confiance l’équipe par rapport à l’approche du  changement, et responsabiliser chaque individu de l’équipe vis-à-vis de ses objectifs individuels, afin d’être en mesure de remettre en cause des processus, dans l’objectif de l’amélioration continue.

 

Commentaire

neuf × = 18

iMDEO recrute !

REJOIGNEZ-NOUS

A la recherche de nouveaux talents (développeurs web et mobile, chefs de projet,...)

Voir les annonces