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.
Pour un usage des OKR avec l'agilité radicale, au rythme des saisons
KARMA POLICE est une variante dans l’usage de KARMA, l’outil d’amélioration radicale de la maitrise agile.
Basée sur les fameux OKR, elle est inspirée par le livre choisi pour le klub de lecture de mars 2021 :
Succeeding wtih OKRs in Agile d’Allan Kelly
Pour l’édition 4 de mon livre, j’ai revu complètement le chapitre qui porte sur la planification à moyen terme. J’ai fait un gros effort sur le pourquoi. J’ai commencé le comment par un exemple simple, sans estimation. J’ai introduit des variantes à l’estimation et au planning poker. J’ai essayé d’illustrer les notions présentées.
Je l’ai également déplacé, car cette notion ne fait pas partie du cœur de Scrum. C’est maintenant le chapitre 16, il s’appelle Planifier la release.
Le dessin illustre l'orientation flux du sprint, avec le plan mis à jour au fil de l'eau. Et le clin d'oeil au canal du Midi.
La planification du sprint (en anglais Sprint Planning) est un rite Scrum qui se déroule à chaque début de sprint.
Ce rite au tout début du sprint sert à déterminer l’objectif et à produire le plan de sprint.
Pourquoi prévoir à un horizon plus lointain que le sprint ?
Dans l’édition 4 de mon livre Scrum, la présentation de la planification de release a été repoussée. Planifier la release constitue maintenant le chapitre 16. Dans les éditions précédentes, elle était présentée avant la planification de sprint. Cette décision de déplacer ce sujet m’a demandé beaucoup d’efforts, d’autant plus que j’en ai profité pour revoir une grande partie du contenu de l’édition 3, en intégrant des notions nouvelles inspirées du courant #noEstimates.
Ça va être plus roll que rock, le rolling wave planning
Suite à mon billet d’hier sur Plan de release et incertitudes, j’ai reçu un commentaire qui m’amène plusieurs réflexions.
Mon lecteur commence à parler du schéma :
Le schéma est facile est 3 colonnes. L’incertitude cumulée sur 6-7 sprints (ex. release de 3 mois avec des sprints de 2 semaines) risque d’être très forte.
Dans une situation où il est nécessaire d’avoir un plan à moyen terme voilà comment se servir du bac d’affinage. Ce plan que j’appelais plan de release (release plan) je le nomme maintenant plan de saison.
Ken Schwaber et Jeff Sutherland, les fondateurs de Scrum, ont mis à jour le Scrum Guide. Pablo en a fait son décodage
Pablo Pernot vient de publier un billet Scrum2013, le canevas, dans lequel il compare ses pratiques avec ce que propose ce nouveau guide. Par un tweet, Pablo m’a demandé ce que j’en pensais. Comme les commentaires de son billet sont fermés, je vais donner ma position ici.
La question était la suivante :
La vélocité des 2 sprints passés est 13 puis 11. A la fin de la planification de sprint, l’équipe est prête à mettre 20 points dans le sprint. Vous êtes Product Owner, quelle est votre réaction ?
La nouvelle édition du guide Scrum présente la planification de release comme une pratique en dehors de Scrum :
La planification de release est intéressante lorsqu’on pratique Scrum, mais n’est pas exigée par Scrum lui-même.
C’est une évolution car dans la version précédente, même si ce n’était pas toujours bien cohérent, la planification de release était présentée comme une pratique Scrum.
Faire un plan de release, c’est effectivement souvent utile, notamment quand on a besoin de se synchroniser avec d’autres équipes ou d’autres services de l’organisation.
Même si on pense avoir tout prévu, des événements inattendus viennent toujours freiner l’avancement du sprint, en bloquant ou ralentissant une ou plusieurs tâches en cours.
Pour empêcher ces événements de remettre en cause l’engagement de l’équipe sur un objectif de sprint, il faut garder du mou lorsqu’on planifie le sprint.
Associer une couleur de post-it aux 3 types de tâches
Cet après-midi, une idée remontée de la rétrospective portait sur l’identification de types de tâches avec des codes de couleur.
Pendant le sprint, l’équipe a eu du mal à s’y retrouver dans le tableau des tâches affiché au mur[1] de la salle commune et en particulier pour savoir facilement quelles tâches de développement restaient à faire.
La proposition, qui a été retenue pour le sprint suivant, consiste à associer une couleur de post-it aux 3 types de tâches suivants :
J’avais entendu parler une première fois de coefficient de focalisation en interviewant une équipe il y a quelques mois, sans y prêter une attention particulière. Mais récemment, quand 2 autres équipes Scrum ont évoqué devant moi ce coefficient, je me suis dit que ça venait d’une source unique.
Ce billet est l’œuvre d’un blogueur invité, Bruno Sbille.
Bruno écrit régulièrement sur Scrum, les méthodes agiles et le management de projets ; il publie sur son blog Scrum and Agile in Belgium, en français et en anglais.
Lors de la dernière release de notre projet j’ai eu à travailler avec une équipe de 7 personnes. Or parmi les membres de l’équipe, personne n’était staffé à 100 % sur le projet.
Un plan de release présente les itérations à venir et le contenu prévu de ces itérations. Ce contenu consiste en des éléments du backlog de produit.
Présenté sous forme de tableau, un plan de release est facile à comprendre. Il constitue un outil de communication important avec tous les intervenants du projet.
Voici un exemple du plan de release du projet IceScrum.
C'est le sujet de ma présentation de vendredi au SigmaT8
Ceux qui ne connaissent pas trop l’agilité pensent parfois, à tort, qu’on ne peut pas planifier sur les projets agiles, parce que ça change tout le temps. Ils ont bien compris que le client pouvait faire des changements. Ils doivent en déduire :
À quoi ça sert de faire des plans s’ils sont remis en question ?
