La division du temps en phases successives de la gestion de projet moderne est source de problèmes. L'agilité apporte une réponse différente avec les boucles (ou itérations).
Voyons comment les boucles de feedback (saisons, sprints) abordent la notion de temps.
La division du travail selon le modèle tayloriste entraîne de nombreux problèmes. L'agilité propose d'en finir avec ce principe.
Voyons comment les principes, concepts et pratiques de l’auto-organisation peuvent se substituer à ceux de la division du travail pour éliminer ces problèmes.
Ajoutée à la division du travail, la division du temps rallonge le délai avant mise en service et met la pression sur les gens.
Adam Smith a inventé la division du travail. Frederick Taylor l’a complétée en divisant le temps de production en une suite de tâches élémentaires, répétées et chronométrées. Le taylorisme désigne cette forme d’organisation du travail pour la production de masse.
Le taylorisme a eu une influence considérable sur l’organisation du travail dans l’industrie. On en retrouve des traces, voire plus, dans des types de travaux pour lesquels il n’a pourtant pas été conçu, comme ceux de la connaissance et des services.
Le résultat du sprint est ce que l’équipe donne aux parties prenantes à la fin de chaque sprint, pour solliciter leur feedback.
Le résultat est produit par le travail de l’équipe, à partir du backlog, dans la boucle du sprint. À un backlog unique vont correspondre plusieurs résultats, un par sprint.
Laurent dit que le canal du Midi est agile.
Malheureusement le canal est au chômage[1] depuis une semaine, ce qui fait que, si j’ai bien vu deux écluses, je n’ai pas vu de bateau. Pas pu vérifier les dires de Laurent.
Si je dis que le canal du Midi est bien agile, c’est pour sa construction : Pierre-Paul Riquet a fait preuve d’agilité (à croire qu’il connaissait Scrum). Dans l’excellent article de Wikipedia consacré au canal du Midi, on trouve une description des principes appliqués pour ce projet, réalisé sous Louis XIV !
La technique des “user stories” est très efficace couplée à un développement par itérations. Les stories alimentent le backlog de produit et sont développées pendant l’itération. La tendance est à avoir des stories très petites, ce qui présente des avantages en terme de gestion et de suivi. Mais cela a l’inconvénient de rendre les choses plus difficiles à comprendre. Une story est à replacer dans un contexte plus large pour qu’on voit à quoi elle sert.
La pratique Scrum d'une équipe autonome et responsabilisée rend caducs les aller-retours entre le chef de projet, les membres de l'équipe et le management
Bien avant de passer à Scrum, je faisais du processus itératif. J’ai encadré de nombreux projets qui appliquaient un processus itératif, genre RUP. Comme dans Scrum, il y avait une planification à 2 niveaux : plan grosses mailles pour le projet et plan détaillé pour l’itération. Le concept est le même, mais la façon de préparer le plan diffère, essentiellement sur 2 aspects :
le timing la responsabilité
C’était la semaine dernière, au cours du scrum quotidien. Le premier scrum du premier sprint. J’étais le ScrumMaster.
Chacun prit la parole à tour de rôle.
Comme Scrum est à la mode, beaucoup de monde s’y intéresse et le risque est d’en faire un usage très superficiel. Une lecture rapide d’une présentation de Scrum peut amener à penser, comme je l’entends parfois, que Scrum est déjà plus ou moins appliqué dans les projets. Ceux qui disent : on fait déjà du Scrum sans le savoir. D’un autre côté, une mise en œuvre sans bases solides peut amener à une utilisation dégradée.
En principe une équipe ne devrait pas être perturbée pendant un sprint par du travail à faire suite à des évènements qui surviennent pendant le sprint. Pas toujours possible.
Quand une équipe Scrum travaille sur un projet qui a déjà produit une release, il arrive que pendant le sprint courant, une anomalie détectée sur la release en production nécessite une correction urgente. Pas possible d’attendre le sprint suivant [1]: il faut faire quelque chose (au moins corriger l’anomalie) pendant le sprint courant. C’est évidemment perturbant pour l’équipe mais inévitable dans certains environnements.
Sachant que ça peut arriver, une solution est de prendre ses précautions. C’est le cas de l’équipe pour laquelle je fais une formation actuellement. Elle prévoit un pourcentage de temps dédié[2] à ces travaux intempestifs[3] et en tient compte dans l’engagement qu’elle prend au début du sprint pour réaliser des éléments du backlog. Il est donc essentiel que le pourcentage alloué ne soit pas dépassé, sinon les engagements n’ont plus de sens et cela ne peut que démoraliser l’équipe. L’inconvénient de cette solution est qu’elle réserve du temps que l’équipe aura tendance à utiliser pour la maintenance en général et pas uniquement pour des choses urgentes. Elle oblige également à compter le temps passé sur ces travaux pour ne pas dépasser le plafond. De plus il n’est jamais sûr que ce plafond ne soit pas inadéquat dans un sprint où il y aura beaucoup d’urgences.
