J’ai participé il y a quelques jours a un séminaire d’équipe « au vert ». L’idée était comme toujours de récompenser les participants pour leur super travail tout au long de l’année, mais aussi de renforcer encore et toujours la coordination d’équipe.
L’un des exercices consistait au sein d’une équipe de 8 à faire dessiner sur un Paperboard par un membre de l’équipe désigné une figure remise par les organisateurs. Bien sur, le dessinateur était le seul à ne pas avoir vu la figure. Les autres ayant tous la figure sous les yeux devaient donner des indications au dessinateur pour arriver à obtenir la figure globale. Le tout devait se faire en 10 min.
Dans mon équipe, nous partagions visiblement un sens aigu du détail, à tel point que nous sommes restés au moins 3 min à essayer de faire dessiner « un Z un peu penché avec des angles entre les barres compris entre 80 et 90 degrés qui s’étirent quand même pas mal… »
Au bout de 10 min devant initialement servir à faire dessiner un chat assis, nous avions de super yeux de chats, un super Z, mais pas de queue, pas de tête, bref pas un chat. Mais ce Z, une réussite !
Au-delà du fun de cet exercice qui nous a valu d’être bons derniers, nous avons partagé un même constat : dans un contexte où le temps est limité, qu’importent les détails si l’objectif premier du projet n’est pas atteint, en l’occurrence faire deviner et reproduire une figure !
Il en est de même pour tout projet. Il faut se demander avant de démarrer quel est l’objectif principal du projet, compte-tenu des contraintes de temps qui pèsent sur le projet.
Le but du jeu est alors de remplir cet objectif dans le temps imparti. Si d’aventure il reste du temps, on peut alors s’attaquer au deuxième objectif, et ainsi de suite.
Mais à quoi bon concevoir le plan parfait si l’on dépasse la « date limite » pour l’exécuter ? Mieux vaut bien exécuter 80% de ce plan parfait dans le bon timing. D’où l’expression : Timing is everything !
Vous ne me croyez pas ? Vous n’avez qu’à passer une heure devant « Top chef » pour être convaincu ;).
Alors, prêts à revoir vos priorités ?
Effectivement, à notre époque où tout va de plus en plus vite, le timing prend une importance prépondérante.
D’où l’intérêt croissant des méthodologies de projets Agiles (XP, Scrum) qui consistent à réaliser le maximum de fonctionnalités d’une liste priorisée dans un temps limité (et répéter ce processus en séquences).
En plus d’éviter le fameux « effet tunnel », cette méthode plus souple incite le client à identifier clairement les priorités et les éléments à forte valeur.
Aussi, elle permet au client de changer d’avis en cours de projet s’il perçoit qu’il n’est pas en phase avec son business.
Ainsi, l’agilité permet de respecter le timing.
Merci Franck !
Est-ce que cela s’applique d’après toi à tout type de projet ?
L’un de nos développeurs affectionne effectivement beaucoup cette méthode qui semble donner de très bons résultats. Je lui laisserai peut-être un post pour qu’il nous fasse un petit retour d’expérience (@Jul : prépare-toi ;).
A+.
Alex
Chaque projet est unique : acteurs, processus opérationnels, outils informatiques…
Cependant, oui les méthodes Agiles paraissent adaptées à la majorité des projets dans nos métiers du développement et de l’intégration informatiques, notamment mobile ou SaaS et même ERP (!!), où les timings sont serrés et où la solution doit immédiatement coller au plus près du business.
Je ne voudrais pas faire de la philosophie mais le temps est quand même une dimension subie et non pas maîtrisée… :-/ …désolé.
Il est donc normal de prendre pour échelle cette dimension (entre autres) quand on veut gérer un projet. C’est pour cela qu’on utilise le timeboxing. D’ailleurs ça, Alex, tu connais! Eh bien ça provient d’une méthode Agile :o)
J’en profite donc pour glisser vers une autre question, car si les méthodes Agile ont été conçues pour l’informatique, là où les méthodes « prédictives » échouaient, elles restent adaptables à de nombreux types de projets…
Il faut aussi savoir que le Lean, dans sa version « méthode Agile appliquée à l’informatique », provient de l’automobile. Alors que les méthodes originelles du genre cascade ou V donnent plutôt de mauvais résultats dans les projets info… On peut y voir que les méthodes Agile couvriraient des domaines assez larges, et en tout cas plus larges que les méthodes « classiques » citées, mieux adaptées à des process réguliers.
A confirmer donc! Car les méthodes Agile ont aussi des travers bien connus…
Je pense qu’il faut surtout choisir sa méthodologie en fonction de chaque projet, et ne pas chercher à adapter chaque projet à sa méthodologie.
Promis! j’ai essayé de pas faire trop long ! 😉
Julien
Merci Julien pour ces enrichissantes précisions ;). Tu viens définitivement de gagner un post sur 2011 !
A+.
Alex