Scrum exige une façon de penser différente

« J’avais des difficultés à respecter les délais et les produits étaient envahis de défauts et de bogues. Ce qui rendait d’autant plus difficile l’acceptation des modifications requises par le client, jusqu’à ce que je décide de passer à l’agile. Avec Scrum, les changements sont plus facilement acceptés car l’impact est diminué : il n’y a pas de documentation à mettre à jour. L’équipe s’auto-organise et elle se sent plus responsable, il y aura ainsi moins de défauts. Les modèles de développement traditionnels ne sont ni suffisants ni efficaces.
Après 6 mois de production de logiciels avec Scrum, nous avons compris que ce n’était que du boniment et les résultats de cette méthode s’annonçaient plus que désastreux !
»

Ce message de désespoir vous semble familier ? Oui, bien trop familier ! En tant que Directeur Technique chez Pentalog (SSII), j’ai eu l’opportunité de rencontrer des clients potentiels avec des problèmes semblables : « Nous avons fait du Scrum, mais ça ne marche pas pour nous, nous voulons continuer de manière plus traditionnelle, avec le modèle en cascade ou le cycle en V… ». Je ne réagis jamais lorsque j’entends  ces paroles. Peut-être on-t-il trouvé un environnement particulier où Scrum est inadapté. Après une enquête plus approfondie, il s’est avéré que les pratiques Agiles n’était ni bien maîtrisées ni bien appliquées. L’analyse des causes des ces échecs démontre que les responsables ne sont ni les modèles organisationnels ni les problèmes de livraisons…, mais plus probablement les convictions erronées, les voeux pieux les fausses idées concernant l’Agile et les optimisations locales.

Passer d’une méthode traditionnelle de développement vers une méthode Agile requiert un autre état d’esprit, qui nous permet de pleinement comprendre et déployer les profonds changements qui doivent prendre place ! La résistance au changement va terrasser votre enthousiasme, retarder votre ROI pour provoquer, en définitive, la  conclusion tant redoutée : « Scrum ne marche pas ! ».

Prendre en considération la méthode Agile avec le recul nécessaire est presque impossible pour le débutant. En raison du fait que le bon sens n’est pas le même pour tous, les personnes avec moins d’expérience vont interpréter « Des logiciels opérationnels plus qu’une documentation exhaustive» comme « Nous n’avons plus besoins de documents ». Et nous ne devenons pas une équipe auto-organisée en une nuit, n’est-ce pas ?

Albert Einstein a écrit « Le monde que nous avons créé est le résultat de notre niveau de réflexion, mais les problèmes qu’il engendre ne sauraient être résolus à ce même niveau. “. Ainsi, si nous tentons de résoudre nos problèmes avec la même façon de penser que celle qui les a engendrés, nous avons de grands chances d’échouer ! Une bonne approche serait de commencer à  confier l’entraînement  des équipes aux méthodes Agiles à un organisme  spécialisé externe à l’entreprise. Une formation Scrum s’étend sur une période de 2 à 3 jours, est très efficace mais elle n’est pas suffisante. Une préparation au long terme est nécessaire. C’est sur ce long terme que le rôle du Scrum Master prend tout son sens. Il est là pour vous faciliter tout ça et s’assurer que chaque personne de l’organisation respecte les valeurs établies. Soyez conscients qu’un chef de projet ne peut implicitement être nommé Scrum Master !. Il aura aussi besoin de formations et de coaching pour changer ses habitudes et ses réflexes de gestionnaire de projet  pour devenir un coach et un facilitateur. Encore une fois, il faut essayer de trouver un Scrum Master (Coach Agile) qui va vous guider sur plusieurs mois.

Ce n’est pas une chose facile que d’expliquer cela au Conseil d’Administration : « Nous avons embauché les meilleurs managers et vous me dites qu’ils ne sont pas suffisamment bons ? Que vont-ils apprendre pendant cette formation ? Quels sont les bénéfices ? ».
Une formation Agile se doit d’être souple. D’après notre expérience, pour couvrir les aspects les plus importants du développement Agile et de Scrum, une équipe va avoir besoin d’environ 5 jours de formation :

  • 2 jours pour toute l’équipe (Scrum Master et Product Owner inclus)
  • 1 journée pour le Scrum Master
  • 1 journée pour le Product Owner
  • de 2 à 3 jours pour les membres de l’équipe concernant le développement Agile (Testing, développement, intégration continue…)

Pendant cette formation, les personnes doivent comprendre :

  • Les différences entre le développement traditionnel et le développement Agile. Quand doit-on utiliser Scrum ? Éviter le ScrumBut !
  • Qu’est-ce que la « business value » et la « business attitude » ?
  • Qu’est-ce qu’un vœu pieu et comment l’éliminer ? Estimations, plannings (planning poker), vélocité de l’équipe.
  • Les différentes perspectives de construction d’un environnement pour l’amélioration de la compréhension commune (auto-organisation d’équipes, bien être de l’équipe, standards de codage, définition de « fait », métaphore simple, conception simple)
  • Les équipes organisées
  • Agile contre Discipline ! Le cérémonial Scrum
  • L’agile testing (tout tester, TDD, Mocks, A-TDD, test de validation d’interface…)
  • Pair programming, refactorisation (masquage, extraction), code smells …
  • L’importance des retours (intégration continue, livraisons fréquentes)
  • Scrum est un processus continu (cycles d’apprentissage et d’amélioration continus, rétrospectives, gestion des blocages)
  • Comment améliorer continuellement les résultats afin d’apporter une valeur ajoutée au client ? Diminution du gaspillage !
  • Apprendre à éclaircir la dynamique du système, les causes principales, les modèles mentaux et les optimisations locales

En ce qui concerne la deuxième question, possiblement la plus importante « Quels sont les bénéfices ? », Scrum est souvent vu comme un moyen de réduction de coûts pour les entreprises de part l’accent mis sur la livraison de business value, l’adaptabilité du projet et le time to market. Des rapports comme ceux des « Statistiques du Groupe Standish sur l’utilisation des logiciels » confirment l’importance de l’approche du développement centré sur la valeur pour diminuer le nombre de fonctionnalités inutiles :

Scrum Agile Offshore

    Cette méthode, appelée aussi Principe de Pareto ou règle des 80/20 , ou encore loi de l’inégalité énonce que, pour de nombreux événements, environ 80 % des effets sont le produit de 20 % des causes. C’est pour cette raison qu’une équipe Agile va continuellement se demander quelle valeur incrémentielle offre un élément nouveau en comparaison avec un autre.
    Notre expérience montre qu’un gain de productivité de 25% à 50% peut être obtenu en l’espace d’un semestre si l’entreprise est déjà alignée sur des standards internationaux de normalisation de type ISO 9001 : 2008. Ce gain peut atteindre 100% à 200% en 2 à 3 ans d’amélioration continue avec Scrum.
    Il faut beaucoup de courage pour mener une équipe à ce niveau succès, mais nous en parlerons d’avantage, ainsi que des valeurs Scrum, dans de prochains articles.
Cornel FATULESCU

À propos de Cornel FATULESCU

Directeur Pentalog Institute

Quand Cornel a rejoint Pentalog, il était le plus jeune développeur de l’entreprise. Il a depuis réalisé une ascension fulgurante et fait sans doute partie aujourd’hui des plus jeunes Directeurs Techniques en Europe. Devenu un des pivots techniques du monde des systèmes d’information en Roumanie, Cornel est un spécialiste de la métamorphose d’idées en produits finis, doté d’un sens de l’abstraction hors du commun et d’un fort leadership.

Mots clés: , , , , , , , , .
Arrière

Laisser un commentaire

− 4 = 5