Mon bilan après 4 années de pratique intensive & passionnée d’Agilité est qu’il ne faut jamais perdre de vue les valeurs fondatrices d’une équipe « Agile ». Sans ces valeurs, l’agilité et ses rituels ne seraient que du folklore.
J’ai découvert l’agilité en 2009 lorsque j’ai commencé à travailler, pour des sites de petites annonces immobilières, avec une équipe de dev qui pratiquait Scrum et XP.
Au départ pour moi ma vision de l’agilité était réduite à un rituel quotidien étrange et des post-it collés sur des tableaux blancs.
Puis, j’ai endossé le rôle de Product Owner au sein de cette équipe. Je me suis donc intéressée plus sérieusement au sujet en avalant livres, blogs, formation et conferences. J’ai alors découvert le manifeste Agile, ses valeurs et ses principes. J’ai tout de suite été séduite !!!
Depuis, sprint après sprint, avec le Scrum Master et l’équipe on met tout en oeuvre pour livrer régulièrement des fonctionnalités à forte valeur ajoutée et attendues par le client ; on s’interroge sur la qualité et la pérennité de nos livrables et du code produit par l’équipe ; on cultive la communication, la transparence et la loyauté au sein de l’équipe ; on s’assure que l’équipe à les moyens de s’auto-organiser ; on recherche systématiquement le feed-back du client pour pouvoir ajuster les fonctionnalités livrées ou à livrer…
Pourquoi fait-on tout cela ? Pourquoi une équipe Scrum au moyen de ses 4 rituels et de son tableau de post-i ne dévie pas de la route de la qualité, de la satisfaction client et de l’amélioration continue ?
Tout simplement parce que derrière la méthodologie il y a des valeurs fortes adoptées par l’équipe !
Rappel des 4 valeurs fortes :
→ « Les individus et leurs interactions plus que les processus et les outils. »
L’équipe est très importante. La communication est une notion fondamentale. L’équipe est plus importante que les outils ou les procédures et on préfère avoir une équipe de développeurs soudés et qui communiquent, plutôt qu’une équipe composée d’experts fonctionnant chacun de manière isolée.
→ « Des logiciels opérationnels plus qu’une documentation exhaustive. »
Il est vital que l’application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n’est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l’équipe (on en revient à l’importance de la communication).
→ « La collaboration avec les clients plus que la négociation contractuelle. »
Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes.
→ « L’adaptation au changement plus que le suivi d’un plan. »
La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l’évolution de la demande du client tout au long du projet. Les premières livraisons du logiciel vont souvent provoquer des demandes d’évolution.
Et ses 12 Principes, qui les déclinent :
1/ La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée.
2/ Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage compétitif pour le client.
3/La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte. Livrez fréquemment un logiciel opérationnel.
4/ Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
Les utilisateurs ou leurs représentants le PO (Product Owner) et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
5/ Le projet doit impliquer des personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs. (C’est tellement plus motivant pour tous que le mode Command and Control)
6/ La méthode la plus efficace de transmettre l’information est une conversation en face à face.
7/ L’unité de mesure de la progression du projet est un logiciel fonctionnel (on ne comptabilise donc pas les fonctions non achevées).
8/ Les processus agiles promeuvent un rythme de développement soutenu et soutenable (afin d’éviter la non qualité découlant de la fatigue).
Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
9/ Les processus agiles recommandent une attention continue à l’excellence technique et à la qualité de la conception.
10/ La simplicité et l’art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
11/ Les équipes s’auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
12/ À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.
Ce jeu est tiré du livre « Innovation Games »
Le Product Owner doit être disponible pour l’équipe, afin de répondre aux questions fonctionnelles sur le produit. Mais comment faire avec un emploi du temps très chargé ?
GINKGO & CO 