Le type C de Scrum expliqué
Auteur : Serge Beaumont
Source : Type C Scrum explained
Date : 25/04/2007
Traducteur : Fabrice Aimetti
Date : 25/07/2011
Traduction :
Ce billet est issu d'une discussion avec Jeff Sutherland lorsqu'il était notre hôte chez Xebia.
Un bon schéma vaut mieux qu'un long discours, mais un schéma peut aussi compliquer les choses. Justement, l'une des choses que je n'avais pas saisi était le type C de Scrum, et tout ce dont je disposais était un article de Jeff et une image qui est généralement utilisée pour visualiser les types A, B et C. Je réalise maintenant que c'est cette image qui est à l'origine de ma mauvaise compréhension du type C...
C'est censé être la forme la plus avancée et difficile de Scrum, et Jeff nous a expliqué comment le type C fonctionnait chez PatientKeeper[1] . Le type C est en fait un Scrum dans un Scrum dans un Scrum, ou comme Jeff l'a schématisé, des roues à l'intérieur de roues.
L'image que l'on connaît bien se trouve ci-dessous : notez que le type C est représenté comme un chevauchement d'ovales de la même taille. Alors, est-ce que ce sont simplement des sprints qui se chevauchent ?
En réalité... pas du tout. Le type C est quelque chose de complètement différent.
Il y a un parallèle avec l'image qui est généralement utilisée pour présenter la mêlée quotidienne, où la mêlée quotidienne est un petit engrenage, qui tourne une fois par jour, en prise avec un engrenage plus grand, qui lui tourne une fois par mois. Désormais, je dessine le type C comme un empilement de ces engrenages : la mêlée quotidienne, le cycle hebdomadaire, le cycle mensuel et le cycle trimestriel (du moins, c'était l'ensemble des cycles utilisés chez PatientKeeper).
Les items du backlog sont assignés à l'un de ces cycles en fonction de leur priorité et de leur urgence. Il y a la priorité critique[3], où tout le travail concerne la résolution d'un problème critique. Puis il y a des éléments du backlog de haute priorité qui doivent être livrés cette semaine, puis des éléments "ordinaires" pour le cycle mensuel, des changements et des améliorations plus stratégiques pour le cycle trimestriel.
Un membre de l'équipe travaillera sur les items du backlog dans cet ordre : le travail critique d'abord, puis les items hebdomadaires, puis les items mensuels, et enfin les items stratégiques. Jeff explique qu'il s'agit d'une subtile incitation pour les membres de l'équipe : s'ils terminent les éléments de haute priorité, ils leur restent du temps pour, comme Jeff l'a dit, "les choses vraiment intéressantes" : s'asseoir, faire une pause et réfléchir à comment améliorer le produit, pour qu'il soit encore meilleur techniquement et fonctionnellement.
Donc, l'image pour le type C devrait en réalité être celle-là :
Je n'ai jamais pratiqué le type C, mais je suppose que le plus gros défi est de s'assurer que les choses à court terme ne compressent pas le temps restant pour traiter les items à long terme. Je ne pense pas qu'attribuer un item à l'un des cycles devrait être trop compliqué.
J'espère que vous avez maintenant moins de difficulté à comprendre le type C. En tout cas, cette nouvelle façon de le visualiser me convient tout à fait...
