Qui n’a pas encore entendu parler du cadre de travail scrum? Ce framework qui répond aux préconisations du manifeste agile. Où l’on se focalise itérativement  sur un livrable.

Son estimation, sa planification opérationnelle et sa réalisation sont cadrés et définis dans une durée très limitée dans le temps, à savoir une durée maximale de 4 semaines (qu’on appelle Sprint).

Ce SPRINT garantit une mesure réelle et concrète de ce qui a été réalisé jusque là  et permet aussi de limiter les écarts par rapport au besoin initial et éviter ainsi l’effet tunnel responsable de nombreux échecs de projets.

Mais concrètement que se passe-t-il si un incident de production est remonté durant un sprint?

Imaginez que votre équipe Scrum a estimé et  a planifié un ensemble de tâches pour le sprint suivant, la capacité est correctement définie de façon à ce que la charge actuelle soit supportée.

Vous êtes au beau milieu d’un sprint, votre équipe vient d’achever un daily meeting dans lequel ils viennent de se fixer les objectifs du jour dans la joie et la bonne humeur, mais là !…. Un incident est remonté par la production sur le système que l’équipe vient de livrer il y a quelques semaines.

D’un coup c’est la panique à bord! La hiérarchie de votre organisation ou de votre client y est associée comme c’est souvent le cas, plusieurs intervenants externes à votre équipe vous sollicitent, les uns veulent comprendre, d’autres veulent monter des réunions d’urgence, certains vous demandent même de rendre des comptes ! Bref ceci risque de déstabiliser considérablement votre équipe et corrompre le bon déroulement des travaux de correction et de gestion de l’incident.

Que faire dans ce cas pour résoudre l’incident sans pour autant bafouer les règles de SCRUM, ses événements et ses artefacts?

Ma règle d’or est la suivante: votre équipe de réalisation doit toujours laisser une petite enveloppe pour analyser d’éventuels incidents, notamment ceux de la production, servez-vous en pour voir si vous pouvez répondre à cette demande imprévue sans compromettre vos engagements existants, si vous pouvez le faire, faites le sans délais !

Si cette demande imprévue ou cet incident met en péril vos engagements existants (Sprint Courant), vous devez alors passer par une série d’étapes:

Etape numéro 1:

Demandez si le travail imprévu doit avoir lieu immédiatement. S’il peut attendre, laissez-le passer au sprint suivant.

S’il ne peut vraiment pas attendre, demandez à vos référents métier (stakeholders) où est ce que cet incident imprévu se situe en termes de priorité par rapport aux autres éléments planifiés dans le SPRINT courant.

Par expérience pour les incidents de production, la réponse est assez souvent «TOP PRIORITY», mais elle descend parfois un peu plus bas pour les cas triviaux.

Etape numéro 2:

Une fois l’incident priorisé, évaluez en interne l’impact de la prise en charge de ce nouveau travail. Pouvez-vous toujours faire tout le travail en faisant une version allégée d’un autre élément existant? Devez-vous pousser un élément hors du sprint backlog ?

Etape numéro 3:

Une fois que vous avez décidé de l’impact (par exemple, “Nous pouvons répondre à cette demande urgente X, mais cela signifie que nous devons pousser cette autre demande Y au prochain sprint”), assurez-vous que toutes les parties prenantes auront accepté.

Etape numéro 4:

Gérer un changement en cours de sprint n’est jamais simple et peut créer une certaine résistance au changement et une certaine lourdeur de mise en place, En équipe, réengagez-vous dans le nouveau sprint et faites le nécessaire pour que les changements apportés soient collectivement associés à un but.

Etape N° 5 :

Si vous voyez que cela se produit régulièrement, utilisez vos rétrospectives pour explorer pourquoi. S’agit-il d’incidents vraiment imprévisibles, ou pourriez-vous les prévoir ? Les problèmes proviennent-ils d’une dette technologique connue?  S’agit-il d’un choix d’architecture mal négocié?

La rétrospective représente une réelle opportunité pour limiter les incidents, lever le voile sur les points faibles et les rectifier rapidement.

La méthodologie Agile en général et le Framework SCRUM en particulier possèdent  leurs avantages et  inconvénients mais leurs pratiques dans le respect strict des rituels, artefacts et règles  constituent une garantie considérable pour maîtriser le cadrage du projet et limiter significativement sa dérive et son échec.

Mohamed Ali Haddad