Un peu d'histoire

Scrum, Lean, Agile... Des mots qui sont parfois considérés comme synonymes... Et qui ne le sont pas. Il ne s'agit pas ici de retranscrire l'historique du manifeste, simplement de rappeler ce qu'est, tout simplement, le mouvement agile et pourquoi il est important de connaître sa - courte - définition.

Agile... Le "tronc commun" à différentes méthodes ou cadres nés dans les années 90, qui se définissaient à l'époque comme méthodes légères en opposition aux approches lourdes telles que "cascade" ou RUP. De nombreux rôles, de nombreux documents... Et surtout des stratégies fausses : croire que la production d'un document prouve réellement un certain avancement, croire que l'Utilisateur peut tout spécifier, que l'intégration peut attendre des mois... Croire que l'on peut créer dès le départ un plan-projet et que ce plan est prédictif. Bref, croire que l'on est dans un domaine suffisamment connu pour être "modélisé" dans des plannings, des plans "qualité". Or, l'agilité est basée sur un autre paradigme : ce que nous faisons est trop complexe pour être théorisé, adoptons alors une approche empirique. Voir à ce sujet les premiers articles sur Scrum.

Voici donc nos valeureux et créatifs concepteurs de méthodes légères réunis dans une station de ski de l'Utah en février 2001. Ils se définissent comme Anarchistes organisationnels.

Anarchistes-organisationnels

Et que font ces Anarchistes Organisationnels ? Ils rédigent - sous forme de texte court nommé Manifeste - ce qui les rassemble dans ces approches "anti-lourd", empiriques.

En pratiquant et en aidant les autres à pratiquer, nous découvrons de nouvelles façons de développer des logiciels. Grâce à ce travail, nous en sommes arrivés à considérer :

* Les personnes et leurs interactions plus que les processus et les outils,

* Un logiciel opérationnel plus qu'une bonne documentation,

* La collaboration du Client plus que la négociation contractuelle,

* Répondre aux changements plus que suivre un plan.

Autrement dit, si les items sur la droite sont importants, nous donnons encore plus de valeur à ceux de gauche.

Valeurs et "potentiel" agile d'une organisation

Pourquoi ces valeurs sont-elles importantes ?
Pour une raison simple : si votre organisation ne souscrit pas à ces valeurs, les pratiques agiles viendront "percuter" la culture de l'entreprise et risquent fort d'être rejetées plus ou moins violemment. Concrètement, si votre organisation pratique

  • le secret plutôt que le partage des informations
  • la performance individuelle plutôt que collective
  • la manipulation plutôt que le respect des collaborateurs
  • ... En un mot, si votre organisation ne considère pas les personnes qui la composent comme une véritable richesse...

Alors il est peut-être préférable de se tourner vers une approche non agile, telle que RUP.

Les principes agiles

Les quatre valeurs agiles sont complétées par une douzaine de principes qui précisent très concrètement ce qu'est l'agilité. Ces principes sont parfois sujets à interprétation, bien souvent, ils sont tout à fait objectifs.
Chacun de ces principes est alors décliné de façon plus ou moins compatible par les différentes méthodes qui se réclament du mouvement agile.

Notre plus grande priorité est de satisfaire le Client en livrant tôt et continuellement un logiciel qui lui apporte une valeur ajoutée.

Cela a à voir avec la notion de retour sur investissement et également de feedback concret de l'utilisation.

Nous accueillons les changements, même lorsque le développement est avancé. Les processus agiles renforcent les possibilités de "changement" au service de l'avantage compétitif du Client.

Les changements ne sont plus vus comme des "empêcheurs de suivre le plan initial", mais comme un signe de la vie du produit.

Nous livrons fréquemment un logiciel opérationnel, le cycle de livraison étant de deux semaines à deux mois.

Livrez-vous une "grosse version" de temps à temps ? Si oui, l'agile recommande de remplacer ce rythme par des "versions fréquentes". Ce principe vient préciser le premier.

Les personnes du métier doivent travailler chaque jour avec les Développeurs durant tout le projet.

Voila bien un principe agile souvent malmené. En Scrum cela signifie que le Product Owner travaille tous les jours avec les Développeurs de l'équipe et non pas uniquement en début et fin de sprint. On ne peut pas avoir le beurre et l'argent du beurre, ne plus faire de "gros dossier de spécifications" et en même temps ne pas appliquer les 3C des User Stories.

Montez des équipes projets avec des personnes motivées. Donnez-leur l'environnement et le support dont elles ont besoin. Et faites confiance à leurs capacités à réaliser le travail.

C'est une pratique de management agile parfois appelée "couverture aérienne". Elle consiste pour le Manager à "lâcher-prise". Notez tout de même que l'équipe a rendez-vous à chaque fin de sprint avec ce même management et que l'avancement se mesure par les fonctionnalités effectivement validées par le Product Owner en Scrum (voir la deuxième valeur).

Le dialogue en présenciel (face à face) est la façon la plus efficace de transmettre une information à - et dans - une équipe de Développeurs.

Nous retrouvons ici en particulier la nécessité de présence de la part des représentants "métier" dans un principe précédent.

Le logiciel opérationnel est la mesure de base de l'avancement.

Dire "J'en suis à 80% du Dossier de Conception, j'ai donc bien avancé dans le produit" fait "sourire" un Agiliste.

Les processus agiles promeuvent un rythme viable. Les sponsors, Développeurs, Utilisateurs... doivent pouvoir maintenir indéfiniment un rythme constant.

Ce principe, connu dès XPv1 sous forme de "rythme durable" vaut aussi pour les Utilisateurs, le service "exploitation"... Bref, tous les intervenants qui contribuent au produit. Il est à mettre en regard des principes de livraison fréquente.

L'Agilité est renforcée par une attention continue à l'excellence technique et à la qualité de la conception.

Voila un principe qui coupe court à bien des rumeurs anti-agile telles que "Agile c'est faire vite et mal" ou encore "pas de conception en agilité". Au contraire, la qualité n'est pas une option pour un Développeur agile.

La simplicité - l'art de maximiser tout ce qui n'est pas à faire - est essentielle en agilité.

Certainement l'un des principes les plus difficiles à mettre en œuvre. Voir par exemple le fameux "Burn down chart" de Scrum :-)

Les exigences, conceptions, architectures les meilleures émergent d'équipe auto-organisées.

Encore un principe pas si évident. Équipes auto-organisées... Et oui, une équipe auto-organisée sera plus libre de... s'auto-améliorer.

Régulièrement, l'équipe réfléchit sur les moyens d'être efficace, elle modifie alors son comportement en fonction des axes d'amélioration définis.

Nous retrouvons se principe dans la pratique "Rétrospective" de Scrum ou bien dans le principe de "Réflexion" d'XP.

Nous voyons donc que certains principes sont effectivement subjectifs, par exemple celui concernant la simplicité. D'autres sont tout à fait clairs, comme celui concernant la participation quotidienne du Product Manager ou Owner.

Quatre valeurs et douze principes

Voila donc la définition originale de l'agilité, ces 4 valeurs et 12 principes. C'est la naissance du mouvement agile en 2001, comme suite logique des expérimentations de méthodes légères.

Le manifeste agile

Lorsque vous écoutez une conférence, vous lisez un article ou une interview... Souvenez-vous de ces principes originaux. Cela vous permettra de mieux apprécier qui est agile... et qui ne l'est pas.

Ce n'est pas une question d'orthodoxie. C'est, comme je le rappelais en introduction, si facile de proclamer l'inefficacité de l'agilité alors qu'elle n'est pas appliquée. Au contraire, appliquer ces principes agiles, par exemple en déployant Scrum+XP, est un gage de réussite.

Illustration : agilemanifesto.org