Pourquoi le Sprint ne permet pas de finir plus tôt
21-11-2019
  • Blog

Lors de nos missions, nous avons eu l’opportunité de travailler avec une société informatique qui utilisait les approches dites "Agile".

 

Il ne s’agit pas ici de parler des limites de l’Agile ou de contribuer à l’ambiance générale qui consiste à dire que l’Agile ne marche plus, etc. Il s’agit plutôt de montrer comment l’Agile traite le FLUX de son système.

Dans les approches Agile, il est fait mention d’une pratique s’appelant le Sprint. Sans rentrer dans le détail méthodologique du sprint, il s’agit de concentrer les équipes durant une période donnée sur un certain nombre de tâches. Cette période pouvant être reconduite un certain nombre de fois. Néanmoins, donner à une équipe un certain nombre de tâches à réaliser durant une somme de petites périodes peut générer de nombreux biais.

 

L’équipe projet part avec un certain nombre de caractéristiques de développement à réaliser durant une certaine période.

 

Comme d’habitude, une âpre négociation se fait pour savoir ce qui est réalisable ou pas durant cette période. Comme toute négociation, à la fin, personne n’est vraiment satisfait : d’un côté vous avez ceux affirmant que l’équipe pourrait en faire plus et l’équipe qui affirme que c’est beaucoup trop en si peu de temps …

Lorsqu’on prend le Fever Chart, ci-dessous, vous avez la représentation du comportement. Dans un premier temps, l’équipe qui a la main mise sur son planning explique que c’est beaucoup trop et annonce donc qu’avant même d’avoir démarré le Sprint, le projet est déjà en train de consommer sa protection.

Ce sentiment est d’autant plus confirmé que lors du pointage suivant, le projet s’enfonce encore plus dans la crise. Là où on perçoit le travail en équipe (Agile ou pas), est que cette dernière se réunit pour trouver une solution…sans sacrifier les caractéristiques initiales. Cette solution, construite en équipe, apporte une vraie bouffée d’oxygène dans son projet puisqu’il permet de remettre les caractéristiques en ordre et de récupérer une partie de la protection.

 

C’est là que ceux qui affirmaient que l’équipe pourrait en faire plus reviennent dans la partie !

 

"Ah vous voyez que vous pouvez aller plus vite" (sous-entendu "quand vous voulez"). La seconde partie de la phrase n’a pas été citée mais a bel et bien été entendue par l’équipe !

Mécaniquement, pour justifier que l’équipe ne s’était pas trompée sur son estimation, que se passe-t-il ? Le projet recommence à consommer du buffer doucement, sûrement, pour finir « pile » à l’heure.

Le temps a été « pleinement » exploité pour satisfaire les caractéristiques intiales, le temps imparti a été consommé mais tout le monde ne peut s’empêcher de se dire qu’on aurait peut-être pu finir plus tôt…

 

 

Dans notre approche de Management par le FLUX, le mot sexy est FLUX. Le mot-clé est MANAGEMENT.

  • Quel est l’intérêt de remplir la phase de Sprint de caractéristiques que l’équipe ne sent pas prêtes à assumer ?
  • Quel est l’intérêt de faire des constats/jugements intermédiaires dans un projet quand « seul le résultat final compte » ?
  • Quel aurait été le bénéfice pour le projet et l’équipe de terminer plus tôt le contenu du Sprint ?

 

Ce sont ces 3 questions qui nous amènent à penser que le Sprint possède un certain nombre de limites. Ce sont ces 3 questions qui nous amènent à dire que l’équipe ferait mieux de se réunir au fur et à mesure de ses caractéristiques pour les mettre en regard du projet dans son ensemble plutôt que dans le cadre du sprint. Ce sont ces 3 questions qui nous font penser que Sprinter ne sert à rien...

Identifiez votre séquence de tâches critiques, assumez le fait que ces tâches vont subir une variabilité qui va impacter le projet et non la tâche (ou le sprint), protégez le projet (et non le sprint) de cette variabilité, et concentrez votre équipe autour de ces tâches critiques pour les récompenser lorsqu’elle trouve une solution, une amélioration ou pire... qu’elle termine plus tôt !

 

Recevez notre newsletter