Coaching de Chefs de projets
Actualités
- 13/02/12 : Marchons ensemble : Le 13 février à 12h45 - Pont Pasteur
Le blog du chef de projet
- Marchons ensemble & Coaching
- Les chefs de projets sont-ils des managers ?
- Projets en perdition : comment les...
- Redressement de projet : avec ou sans le...
- Management de projet : la profession clé...
S'abonner à la newsletter
Chaque mois, le meilleur du management de projet (Articles, news...)
Les éditions Coopil
Recherche par mots clés
Accueil > Le blog du chef de projet > Méthode SCRUM - Kesaco ?
Méthode SCRUM - Kesaco ?
Publié le 08 janvier 2010
Comme quoi les informaticiens sont créatifs et pousse le management de projet à évoluer !
A propos de Coopil : Formation & coaching chef de projet. - Téléchargement livres blancs Projets stratégiques & Gouvernance de projet - Profitez aussi d'un Essai gratuit compagnonnage
Un de mes clients, en marge d'une autre réunion, me dit employer la méthode SCRUM pour mener son projet et précise réunir son équipe pour des stand-up meetings quotidiens. Comme seuls les ânes connaissent tout, j'avoue mon ignorance sur sa méthode mais je suis bluffé par ces réunions quotidiennes. Après m'avoir précisé qu'ill s'agit d'une méthode agile, je vois mieux mais je me dois de creuser le sujet.
Je ne vais pas copier/coller les définitions des méthodes agiles de développement logiciel et de la méthode Scrum sur Wikipédia en dehors de cet extrait : "Scrum est un processus itératif : les itérations sont appelées des sprints et durent en théorie 30 jours calendaires. En pratique, les itérations durent généralement entre 2 et 4 semaines. Chaque sprint possède un but et on lui associe une liste d'items de backlog de produit (fonctionnalités) à réaliser. Ces items sont décomposés par l'équipe en tâches élémentaires de quelques heures, les items de backlog de sprint."
A noter que Scrum veut dire Mélée en rubgy, tout un programme. Quelques remarques prélables sur cette méthode de développement agile :
* Tout d'abord la vitesse d'exécution, on parle de Sprint toutes les mois, avec des réunions de coordination quotidiennes, sous la forme de réunion débout (stand-up) de 30'.
* Ensuite le niveau de détail du contenu puisque chaque sprint est décomposé en éléments de 1 à 2 j de travail.
* Enfin, la volonté affichée de protéger l'équipe Scrum des perturbations extérieures, rôle du ScrumMaster.Il y a même des certifications ScumMaster ! (Pas de doute, on en apprend tous les jours !)
Mon questionnement de fond est le suivant : est-ce encore de la gestion de projet ou de la gestion de production. On retrouve en effet plusieurs caractéristiques de la gestion de production :
* La fréquence qui correspond à la fréquence d'un cycle de production (le mois ou la semaine selon les domaines mais c'est l'ordre de grandeur) par opposition au cycle projet qui lui dure plusieurs mois en général,
* Le niveau de détail des tâches, qui nous rapproche plus de l'ordonnancement que des organigrammes de tâches de projet,
* La volonté d'isoler les équipiers, n'est-ce pas pour qu'ils produisent mieux ?
Peut-on encore parler de projet, en tous cas au niiveau de l'équipe de développement, quand on se retrouve à un rôle de production aussi strict. Pour autant, l'exemple est à retenir. Il existe chez les SI un savoir-faire à l'interface de la gestion de production et de la gestion de projet qui est intéressant. Mais pas de tout repos pour l'équipe (et un peu appauvrissant peut-être, au fond de la mine ?)...
La semaine prochaine sur le blog du chef de projet : Coaching / Compagnonnage : où est la limite ?
6 commentaires à cet article
Tannguy
Merci Claude de ce Feed-back sur le blog du chef de projet, éclairé puisque je vois que vous publiez chez Dunod un livre tout simple "Scrum". Bonne chance à votre ouvrage, je crois savoir que c'est du boulot à écrire ! :->
Coté Scrum, je ne porte aucun jugement sur la méthode, qui me semble répondre à un besoin. Comme à celui de mon client par exemple. Si l'environnement est mouvant, cela doit proposer une réponse adaptée. A condition de ne pas perdre de vue que la stabilité des besoins d'entrée est quand même à rechercher dans la mesure du possible
Tannguy
Posté le 26-01-2010
Claude Aubry
Un des objectifs des méthodes agiles est de donner plus de satisfaction aux membres de l'équipe. Le contraire de ce que vous dites. Et il se trouve que ça marche sur le terrain, selon mon expérience et aussi au vu des résultats des enquêtes : http://www.aubryconseil.com/post/Les-b%C3%A9n%C3%A9fices-du-d%C3%A9veloppement-agile
Probablement que les personnes que vous avez rencontrées appliquaient très mal Scrum et n'avaient pas compris les principes. Oui, c'est du changement et cela demande des efforts.
En revanche, il n'y a vraiment pas de quoi être impressionné par la certification Scrum.
Si vous voulez en savoir plus sur Scrum, je vous invite à lire mon blog ou le livre qui va sortir.
Posté le 24-01-2010
Tannguy
On se connait de loin effectivement mais on va y remédier
Ravi de voir ici un témoignage vécu de ces méthodes. Cela confirme un risque de stress important pour les équipes. Ce sont donc des méthodes à manier avec précaution et à réserver à quelques situations particulières. Merci de ce retour d'expérience. Tannguy
Posté le 21-01-2010
Emmanuel REGIS
Bonjour,
Je suis "tombé" sur votre site suite à votre visiste sur mon profil Viadéo. De plus, je vous connais de loin pas SP, PB en 2003 m'avait parlé de vous. J'avais essayé de vous contacter, sans succès. J'ai remarqué que l'ona des pts communs sur la vue de la gestion de projets, j'en suis ravi.
Sinon, ces méthodes Agiles existent depuis quelques années (Origine Cannada/US). Elles sont héritées de projets informatiques. Comme je travaille avec les loisirs numériques (Cf. Jeu video, etc.), ces méthodes sont prisées par certains car le client change très souvent les fonctionnalités... De plus, ce secteur n'aime pas trop manager les équipes. D'où un intérêt pour ces méthodes... Ces méthodes sont souvent revues, personnalisées dans les entreprises car elles ne sont pas trop adaptées à certains business. Par exemple, ce qui est retenu est surtout le tableau avec post it des tâches, avec un code couleur pour leur avancement. Je me méfie bcp de ces méthodes agiles car il y a déjà 20 ans en arrière on faisait ce genre de chose, soit conscient, soit inconscient. Par exemple, le système à itérations, on le fait déjà, comme le principe du PDCA. Ou encore l'indicateur IPP et ou IPC qui est en qq sorte l'indicateur vélocité des méthodes Agiles. Pour finir, oui, c'est entre de la gestion de projets en crise, de la gestion en prod. En tout cas ces méthodes agiles usent bcp les équipes qui sont sous le stress régulier... Amicalement. Emmanuel.
Posté le 20-01-2010
Tannguy
Merci de ce commentaire Olivier. Effectivement la réunionnite est un travers fréquent de projet.
Dans ce cas particulier de méthode Scrum, cela répond peut-être à un besoin de coordination pointu ? Ou plus largement à un besoin propre aux projets SI ? Dans tous les cas, cela ne semble pas être un epiphénomène puisque des certifications ScrumMaster existent.
N'étant pas SI moi-même, je me garderai bien de trancher, même si je reconnais que des réunions aussi fréquentes ne doivent pas être épanouissantes pour les concernés. Mais, après tout, si c'est de la prod, c'est de la prod !
Posté le 13-01-2010
Olivier
Conduire un projet, n'est pas à mon sens et selon une longue experience de 30 ans synonyme de réunionite. J'ai rencontré des chefs de projet qui ne concevaient pas leur action sans provoquer des réunions à tout bout de champ. Pour moi conduire un projet déjà, cest reconnaitre l'expertise des membres du projet et c'est déléguer à chacun une mission en rapport avec son expertise. A partir de là, il faut laisser le temps à chacun de réaliser sa mission. En conséquence, il ne faut pas l'absorber par des réunions trop fréquentes. Le chef de projet doit être à l'écoute des problèmes rencontrés par chacun des membres du projet et doit, c'est son métier tenter les règler. Des réunions hebdomadaires pour faire le point me semble la cadence maximum à respecter, sinon c'est que le projet est dans une période de crise. Mais cette période si elle perdure démontre une incapacité du chef de projet à manager son projet. La méthode qui est décrite me semble considérer qu'un projet doit se gérer dans le stress, donc la crise. On arrive par expérience à rien de bon pendant ces périodes, on rafistole, on rassure la hérarchie, le client, mais ce n'est pas de la conduite de projet.
Posté le 12-01-2010