Fneuch2EE

AGILE /SCRUM Fails to get to grips with Human Psychology. - Clarety Consulting - IT Strategy Made Simple

Le billet que je viens de lire (AGILE /SCRUM Fails to get to grips with Human Psychology.) ainsi que les commentaires qui le suivent, me rapelle fortement les observations que j'ai pu faire au sein de notre organisation.

Pourquosse faire...

Pourquoi qu'à chaque fois en informatique, que quelqu'un tente de changer les façons de faire, les habitudes, il y en a toujours quelques un qui s'y opposent le démollissent, ne comprennent pas.

Je suis dans une organisation gouvernemental, tout est très hiérarchisé, très waterfall! Le directeur dirige, le chargé de projet à toutes les responsabilités de management, l'analyste analise et le technisien écrit le code que l'analyste lui demande...

Ça va faier bientôt 10 ans que je suis ici. Quand je suis arrivé, il n'y avait pas vraiment de méthodologie, le développement informatique s'effectuait selon les taches que j'ai décrit ci-haut. Les projets dépassaient les couts et les échéanciers, cela ne semblait pas catastrophique puisque ça continuait ainsi.

En 2004, nous avons tenté d'instaurer une méthodologie plus agile (une méthodologie développé au gouvernement). Cette méthodologie (sans nom) était un espèce de mixte entre du waterfall et de l'agile. On se disait que ça serait parfait pour changer une organisation qui croule sous le poid administratif. Il s'en est vu plusieurs pour critiquer. La méthodologie ne décrivait pas dans les moindres détails chacune des taches que chaques personnes devaient exécuter. On demandait au gens en place de réfléchir, on tentait de forcer les techniciens de sortir de leurs rôles de secrétaire de code qu'ils étaient. On demandait aux analystes d'arreté de concevoir tout dans les moindres détails en partant... On essayait de démontrer qu'il n'est pas toujours sein d'avoir placé la configuration exacte de toute les fenêtres d'écran avant d'avoir écrire une ligne de code...

On a aussi tenté de démontrer aux analystes qu'il existait des spécialisations en informatique. Que l'analyste n'était pas le maitre d'oeuvre de tout... Qu'un web designer est meilleur qu'un analyste pour la conception d'interface. Qu'un architecte organique est en meilleur position qu'eux pour définir l'architecture du système. Que le technicien devrait être en meilleur position qu'eux pour créer l'application. Les 2 premières personnes auraient probablement mieux passé que d'admettre que les techniciens étaient aussi important que les analystes...

Mais, l'humain étant ce qu'il est, l'implantation de cette méthodologie, sans dire que c'est un échec, fut un périple incroyable.

Nous pensons passé au RUP. J'ai confiance que ça peut marcher au sein de l'organisation. Le momentum est bon. On a de nouveaux directeurs qui connaissent mieux l'informatique. L'organisation reconnait que les spécialistes en informatique sont dans notre direction et non au communication. La grosse difficulté serait la direction en tant que tel!

En lisant l'article cité ici, je me rends compte que nous ne sommes pas les seules. Le monde entier ne comprends pas que la création d'une application ne fait pas partie du fabuleux monde de l'industrialisation... On ne crée pas une application comme on conçoit une bicyclette. Il n'y a pas de chaine de montage où chacun prends le morceux précédents, lui applique un traitement, et le passe au suivant et qu'en bout de ligne, 200 000 applications seront conçues d'ici la fin de l'année.

Pour avoir un succès, une application doit répondre en tout point au besoin d'un client. Je ne veux pas dire qu'il faut faire tout ce que le client demande. Je veux simplement dire, qu'au moment où on conçoit l'application, la présence du technicien peut être utile. C'est lui qui va la coder l'application. Si ce que le client demande est irréalisable d'un point de vu technique, on peut tu le savoir au début. Si l'interface que le client demande comporte des spécifications spéciales, on peut tu le savoir au début. Si l'interface que le designer pense, comporte des choses irréalisables, on peut tu en discuter en partant... Au lieu que l'analyste prenne tout en note, pense à son affaire tout seul dans son coin et se confronte par la suite au designer et au tech, on peut tu assoir tout le monde dans la même pièce, en discuter avec le client et décider ce que nous réaliserons...

Vous n'y voyez pas là les bases d'une méthodologie appelé SCRUM?

En conclusions, comme il est si bien dit dans les commentaires de l'articles, ce n'est pas Scrum ou Agile qui échoue, mais toutes les organisations qui ne sont pas en mesure de gérer le coté humain. Toutes les organisations fermés sur elle même n'utilisant qu'une seule façon de faire et se rébutants à tout changement sont définitivement voué à l'échec. Que ce soit en informatique, en industrie ou une compagnie de service, si vous ne voulez pas vous améliorer, vous mourrerez...

No Comment