Episode 7 : Service Level Expectation

Effective PSK — Episode 7

Au cours de l’épisode sur la Loi de Little, nous discutions sur l’intérêt de limiter le travail en cours avec l’utilisation des WIP Limit. L’optimisation du flux de travail ne consiste pas uniquement à la mise en place de limite. La Loi de Little doit respecter des hypothèses pour qu’elle puisse fonctionner (cf. Loi de Little — Scrum.org)

Pratique : Gestion active du travail en cours

Nous pouvons utiliser les hypothèses de la Loi de Little comme base pour certaines politiques simples. Ces politiques nous accompagnent pour la gestion active des éléments de travail en cours afin de faire fonctionner notre processus :

• Inclure de nouveaux éléments au même rythme qu’ils en sortent
• Les éléments de travail sont terminés et ne stagnent pas dans le système
• Ne pas laisser d’éléments de travail bloqués
• Respecter des cycle de temps prévu par l’équipe (SLE)

Le niveau de Service Attendu — SLE

La méthode Kanban définit des Service Level Agreement (SLA). Un SLA fait référence à un accord, ou un engagement, qui se traduit par un contrat avec le client. Il convient d’une durée de cycle sur un objectif. Ce contrat peut inclure des pénalités dans le cas où ce dernier n’est pas respecté. Par exemple, nous pourrions avoir un SLA de 3 jours pour la résolution d’un bug en production, sous peine d’une pénalité.

A la place du SLA, le guide Kanban pour les équipes Scrum introduit la notion de Service Level Expectation.

La notion d’attente au lieu d’accord tend à supprimer la négociation du contrat, sous entendant une punition (financière ou autre), bien loin de la philosophie de l’empirisme. A la place de cela, un objectif manqué devrait être une occasion d’amélioration, d’apprentissage et d’adaptation pour les équipes Scrum.

Définition

Temps qu’il faudrait à un élément donné pour transiter du début à la fin du flux de travail de l’équipe Scrum — Guide

• Composé d’une plage de temps en jours accompagné d’un certain niveau de confiance sur la réalisation, c’est-à-dire une probabilité.
• Sert les parties prenantes pour définir avec eux un temps de livraison attendu.
• N’est pas un “indicateur de flux”.

Pour l’équipe Scrum, il est un indicateur en interne. Son but est de fixer des objectifs sur le temps de cycle et de travailler en collaboration pour les atteindre afin de maximiser et d’optimiser le flux de valeur livré. Ainsi, au cours du Sprint, cela permet d’avoir un focus sur le flux de travail et d’anticiper d’éventuels problèmes. C’est un mécanisme de transparence, d’inspection et d’adaptation.

Si nous reprenons l’exemple précédent, nous pourrions dire à notre client que : “nous nous attendons à ce que notre élément parcourt notre processus sur une durée de 10 jours ou moins avec une probabilité de réussite de 85%”.

Utilisation

Il peut être utilisé au cours des événements de la manière suivante :

• Sprint Planning : pour fournir aux Product Owner une prévision du moment où le service peut être attendu (ce qui n’inclut pas de date précise)
• Daily Scrum : l’équipe peut inspecter ces éléments et comparer entre l’âge réel (Work Item Age) et le SLE, afin de s’adapter rapidement et modifier le focus pour l’achèvement d’un élément.

Reprenons l’exemple du SLE précédent : 85% des éléments terminés en 10 jours ou moins. Si nous possédons un élément A actif depuis 7 jours, et un élément B actif depuis 4 jours, alors, sans plus d’informations sur ces éléments, nous pouvons dire que l’élément A a un risque plus important de ne pas être terminé.

• Sprint Review : lorsque l’équipe travaille avec les Stakeholders qui se soucient du temps de cycle de l’équipe.
• Sprint Retrospective : pour inspecter et analyser le workflow. Il peut être déclencheur de réflexion et de discussion sur un SLE qui n’a pas été respecté : “Pourquoi avons-nous raté le SLE de l’élément A ?” — “Que pouvons-nous envisager pour empêcher que cela se produise à l’avenir ?”

Comment et Qui est responsable de définir les niveaux du SLE ?

L’ équipe Scrum devrait se baser sur l’historique du temps de cycle (Cycle Time). S’il n’existe aucun historique de temps de cycle alors l’équipe devrait l’estimer.

La responsabilité de la définition des niveaux du SLE dépend de la portée et des limites des éléments au sein du flux de travail. Par exemple, au sein du Sprint Backlog, il est de la responsabilité des développeurs. Si cela inclut des activités liées à la préparation des éléments du Backlog, alors le Product Owner est aussi responsable. Certains flux de travail peuvent même s’étendre en dehors de l’équipe Scrum.

Points clés :

• Niveau prévu entre le début et la fin d’un élément dans le workflow
• Définir des objectifs de réalisation pour l’équipe
• Composé d’une période de temps en jours et d’une probabilité
• Ce n’est pas une métrique de flux mais un niveau
• Le Cycle Time peut aider à construire le SLE
• Utilisation de l’historique du temps de cycle pour définir le SLE
• La responsabilité dépend de la limite du périmètre de l’élément