Sergej Khackimullin - Fotolia
Gartner : pas d’agilité aboutie sans compétences techniques ni mentalité adaptée
Dans une note de recherche, Mike West pointe du doigt la nécessité de combiner Scrum et Extreme Programming à une mentalité purement agile au risque de voir les gains de l’agilité fondre comme neige au soleil. DevOps compris.
Lorsqu’on entame une démarche agile dans une entreprise, l’application de la seule méthode Scrum ne suffit pas, rapporte le cabinet d’études Gartner dans une note d’étude exclusive que s’est procurée la rédaction du MagIT.
Devenir agile nécessite certes un point de départ, mais sans compétences agiles techniques et sans insuffler une mentalité agile aux équipes, l’entreprise court alors à la catastrophe, résume Mike West, auteur du document publié en septembre dernier. « L’adoption du développement agile de logiciels est une transformation complexe qui ne réussira que si les responsables des applications comprennent et acceptent toute l’étendue du défi », précise-t-il.
Et cette notion d’intégrer tous les critères implique aussi de ne pas créer des exceptions aux 11 principes établis par Scrum ainsi qu’aux rôles définis également par la méthode. En oublier une partie conduit tout de même à l’échec, assure encore le consultant.
Si Scrum fournit un cadre de base, la démarche agile viendra en empruntant à une autre méthode une dimension technique, sans quoi les principes agiles ne pourront pas être mis en pratique. Cette méthode, c’est l’eXtreme Programming. Elle constitue l’outillage de la méthode en apportant le pilotage par les tests, les tests en continu et automatisés, le travail en binôme, la restructuration et l’intégration continue.
La mentalité : second moteur de l’agilité
Toutefois, si les équipes qui doivent adopter la démarche agile, ne se cantonnent qu’à l’outillage, il manquera un maillon indispensable : celui de la mentalité agile, résume encore cette note. Une mentalité qui doit inclure les principes suivants : la focalisation sur les clients, la collaboration, l’ouverture au changement, un esprit d’équipe enthousiaste ou encore une forme de transparence, liste encore Gartner.
Et c’est là le hic : si l’outillage peut être déjà en place, les méthodes de définitions des spécifications peuvent encore dépendre de la très populaire méthode en cascade, qui contrairement aux itérations imposées par les méthodes agiles, définit un cahier des charges fonctionnel figé et peu évolutif dans le temps. Sans changer cette mentalité, l’agilité ne trouvera pas son rythme. « La relation contractuelle distante entre les utilisateurs et les équipes en charge du développement, qui caractérise l’approche en cascade, peut être une habitude difficile à perdre aussi bien pour les utilisateurs finaux que pour les développeurs », souligne encore Mike West.
« L’intégration d’une mentalité historique dans une équipe Scrum est un désastre assuré. Les responsables de produits, les ScrumMasters et les développeurs jouent tous un rôle dans la définition et la contribution de la mentalité agile », écrit encore le consultant.
Gartner recommande alors de commencer par éprouver Scrum pendant au moins un an, sans édulcorer les principes de la méthode ou l’adapter à ses propres processus. Puis, une fois les compétences techniques et la mentalité agile en place, des dérivés pourront être mis en place, souligne-t-il encore, s’appuyant sur l’approche japonaise « Shu Ha Ri » (Suivre et comprendre les règles avant de les contourner).
L’autre recommandation est de migrer ses processus en cascade vers l’agilité, en collaborant et intégrant les commentaires des clients et « en cultivant une mentalité agile », rappelle-t-il. De là coulera l’adoption de l’Extreme Programming. Mais pour Gartner, le point final de cette démarche agile consiste à assurer une forme de cohérence entre les différentes équipes de l’entreprise. La communauté de pratiques, de ces groupes de personnes qui partagent une même passion et interagissent (comme l’a défini Etienne Wenger, un théoricien de l’éducation) autour de ce sujet, reste la meilleure option. Un procédé déjà adopté par Spotify d’ailleurs. De là dépend l’agile « at scale ».
