Accueil Nos publications Blog Scrum et l’agence tous risques ?

Scrum et l’agence tous risques ?

le fameux van de l'agence

Et si l’agence tous risques utilisait Scrum ?

Vous ne vous êtes jamais posé la question ?
Ah vraiment ? Jamais ?

C’est en tout cas la question que je me suis récemment posée pour trouver une métaphore plutôt parlante de l’utilité de scrum pour gérer un projet sous contraintes. Le film, qui sort aujourd’hui d’ailleurs, m’a certainement inconsciemment guidé vers ce choix farfelu que j’expose régulièrement lors de formations ou de conférences. A travers cet exemple, je vous invite à découvrir comment la gestion Agile d’un projet en opposition à une approche classique et prédictive, pourrait permettre à notre cher Hannibal Smith, de voir ses plans se dérouler sans accrocs !

Vous avez dit l’agence tous risques ?

Pour exposer ce magnifique exemple, commençons par le commencement avec un peu d’histoire.

L’agence tous risques, c’est avant tout une bande de justiciers qui, à travers une série télévisée des années 80 de 97 épisodes, nous démontre que sauver son prochain est souvent synonyme de problèmes. En effet, pour une mystérieuse raison scénariste récurrente, notre équipe se retrouvait quasiment à chaque épisode, contrainte et forcée de rester cloitrée dans un endroit confiné (souvent un hangar, une mine ou quelque chose approchant) encerclé par des personnes mal intentionnées. Pour une raison variable, ces personnes mal intentionnées attendaient patiemment à l’extérieur, préférant certainement attendre du renfort pour déloger notre chère agence tous risques. L’endroit confiné comprennait le plus souvent un vieux véhicule délabré et beaucoup de matériel divers et varié. Immanquablement, notre équipe retapait le dit véhicule afin de le remettre en état, le blinder ou l’outiller pour ensuite sortir en maximisant leur chances de survie.

Je résume vulgairement, mais je suppose que certaines bribes d’épisodes similaires vous reviennent maintenant en tête.

[/caption]

Le rapport avec Scrum ?

Oui, le rapport avec Scrum, j’allais y venir.
Si nous prenons le scénario classique d’un épisode, nous nous retrouvons donc avec l’agence tous risques, coincée dans un hangar entouré par des méchants qui attendent des renforts. Ce hangar contient une vieille voiture à retaper et du matériel en tout genre.
Nous avons là tous les ingrédients d’une problématique projet :

  • Un but : sortir du hangar avec un maximum de chance de survie
  • Des moyens :  l’équipe va retaper la voiture et l’améliorer afin de sortir du hangar
  • Une dead-line :  l’équipe à 3 heures avant que les renforts des méchants n’arrivent

L’agence tous risques possède un scénario rêvé pour utiliser Scrum dans un environnement sous contraintes 🙂

Organisation

Les sprints vont durer une heure chacun, ce qui permettra à l’agence tous risques d’effectuer 3 sprints avant la dead line. Nous allons commencer par identifier les rôles avant de commencer nos sprints.

L’équipe

L’équipe, qui travaillera directement sur la voiture, sera composée de 3 protagonistes plus ou moins connus. Commençons par Looping. Ce talentueux mais allumé pilote, représente le coté créatif de l’équipe. Inventif mais difficile à contrôler il peut se révéler être un formidable moteur pour le projet débordant d’énergie et de volonté mais également d’une douce folie.
Enchainons avec Barracuda, le mécanicien musclé de la bande. Souvent taciturne mais très efficace, il représente l’expertise technique du projet avec une solide expérience pour peu qu’il arrive à communiquer avec Looping.
Finissons la composition de l’équipe au sens Scrum avec Amy, le coté féminin de la bande. Pour les besoins de notre exemple, Amy fera partie intégrante de l’équipe sachant qu’à l’habitude, elle représente plutôt le coté “marketing” de l’agence tous risques – elle est journaliste – et ne se retrouve que rarement coincée dans un hangar. Voila donc notre équipe au complet, il nous manque maintenant à identifier le scrum master et le product owner.

Le Scrum master

Concernant le scrum master, il y a un personnage qui semble créé pour remplir ce rôle : Futé. En effet, le scrum master doit porter 3 casquettes pour remplir pleinement son rôle :

  • Faire écran et protéger l’équipe de perturbations extérieures
  • Apporter les outils et informations dont l’équipe pourrait avoir besoin
  • S’assurer que les pratiques Scrum soient bien respectées

Là où Futé sera un parfait scrum master, c’est surtout concernant l’apport des outils dont l’équipe pourrait avoir besoin car, je ne sais pas si vous vous souvenez mais Futé avait une particularité dans la série. Il trouve tout, n’importe où. Si par exemple, vous lui demandiez, en plein désert, de trouver un moteur V6, il revenait 10 minutes plus tard avec le dit moteur et un sourire jusqu’aux oreilles. En plus d’être débrouillard, il est très diplomate et donc complètement indiqué pour ce role de scrum master.

Le product owner

Vous vous en doutez, Hannibal Smith sera notre product owner. Avec son expérience du terrain, ce stratège hors pair saura exprimer les besoins projets avec exactitude. Il va gérer un product backlog, priorisant les actions à mettre en place pour attendre le but commun.

Le product backlog

Hannibal va donc gérer un product backlog. Il propose et explique rapidement chaque “user story” qu’il veut effectuer sur la voiture. En vrac, les idées qui lui viennent sont les suivantes :

  • Ajouter une mitraillette (utile pour se frayer un chemin)
  • Mettre des pneus anti crevaison (Hannibal soupçonne que les alentours du hangar sont piégés)
  • Ajouter un GPS (utile pour savoir ou s’enfuir)
  • Faire fonctionner la voiture (indispensable évidemment … surtout que le moteur manque)
  • Réparer l’auto radio (Un peu de musique pour sortir avec panache ?)
  • Blinder la voiture (Au cas ou ceux qui encerclent le hangar soient munis de battes de baseball)

Le Sprint 1

Tout le monde se réuni pour faire un mini spring planning de quelques minutes. L’idée est ici qu’Hannibal expose ses user stories à l’équipe qui va les chiffrer en points. Suite à cette estimation, il va pouvoir prioriser son product backlog. L’équipe ne tarde pas à vite se mettre d’accord sur le chiffrage suivant :

  • Ajouter une mitraillette 2 pts
  • Mettre des pneus anti crevaison 2 pts
  • Ajouter un GPS 5 pts (pas facile, le GPS est cassé)
  • Faire fonctionner la voiture 5 pts (le moteur manque et plusieurs choses sont à vérifier)
  • Réparer l’auto radio 3 pts
  • Blinder la voiture 2 pts

Hannibal priorise la product backlog, ce qui nous donne ceci :

  1. Faire fonctionner la voiture 5 pts (le moteur manque et plusieurs choses sont à vérifier)
  2. Ajouter une mitraillette 2 pts
  3. Mettre des pneus anti crevaison 2 pts
  4. Blinder la voiture2 pts
  5. Ajouter un GPS 5 pts (pas facile, le GPS est cassé)
  6. Réparer l’auto radio 3 pts

De part son expérience, l’agence tous risques s’engage sur un total de 7 pts qu’elle arrivera à tenir au cours du prochain sprint soit une heure. L’équipe s’engage donc à réaliser :

  1. Faire fonctionner la voiture 5 pts
  2. Ajouter une mitraillette 2 pts

On commence !

Pour ce premier sprint, l’équipe travaille sur la voiture, futé fournit et protège l’équipe d’évènements perturbateurs extérieurs et Hannibal part surveiller l’extérieur à l’affut d’un moindre changement de situation :

Le sprint se déroule pour le moment sans accrocs mais tout à coup, Hannibal qui observe l’extérieur comme il peut,  décourve une élément important :
Ceux qui encerlent le hangar sont munis de pistolets automatiques !
Hannibal veut à tout prix blinder la voiture au plus vite et s’empresse d’aller parler à l’équipe. Mais une personne va s’interposer : futé le scrum master bien sur.

Futé explique qu’avec Scrum, on attend la fin d’un sprint pour modifier ce qui a été planifié. L’équipe s’est engagée à réaliser un certain nombre de user stories, laissons la faire surtout que c’est important et qu’on ne peut pas se contenter d’une voiture qui marche à moitié. En attendant, Hannibal doit modifier son product backlog afin de changer sa notion de blindage de voiture.

La démo / rétro

A la fin du sprint, l’équipe montre l’avancement. Pour notre exemple, il s’agit ici d’une démonstration du bon état de marche de la voiture accompagné de quelques tirs de mitraillette, installée sur le toit de la voiture.
Tout est impeccable, d’ailleurs la voiture ressemble presque à quelque chose (je ne suis pas graphiste, désolé pour le montage approximatif) :
Barracuda et Looping en profite pour essayer d’améliorer leur rapport toujours conflictuels, en séparant au maximum leur différentes tâches.

Le Sprint 2

Le sprint 2 commence par une restimation du planning vu que Hannibal a changé le type de blindage de la voiture. Il veut désormais, un blindage au tungstène qui représente plus de travail pour l’équipe. Du coup, le blindage n’est plus estimé à 2 points mais à 5 points.
Le product backlog re-priorisé et ré-estimé ressemble donc à ceci :
  1. Faire fonctionner la voiture 5 pts (effectué)
  2. Ajouter une mitraillette 2 pts (effectué)
  3. Blinder la voiture 5 pts
  4. Mettre des pneus anti crevaison 2 pts
  5. Ajouter un GPS 5 pts (pas facile, le GPS est cassé)
  6. Réparer l’auto radio 3 pts

L’équipe, dont la vélocité est toujours de 7 points, s’engage donc logiquement à blinder la voiture et mettre des pneus anti crevaisons au cours de la prochaine heure.

Et ça continue …

L’équipe va donc continuer à améliorer la voiture jusqu’à ce que la dead line soit atteinte. L’équipe enchaine les sprints 2 et 3 selon le schéma décrit pour le sprint 1 en écoulant les user stories, alternant planning, réalisation , test, démonstrations et rétrospectives.

Au final ?

Bien sur, à la fin, tout n’a pas forcement pu être réalisé dans les temps. L’auto-radio par exemple n’a pu être réparé, ce qui finalement représente un impair minime vis à vis de l’objectif principal : rester en vie. Car oui, je vous écarte le suspense l’équipe a pu s’en tirer saine et sauve !
En exclusivité, je vous offre la vision de la voiture réalisée :

[/caption]

Arrêtons nous deux minutes sur ce qui a été réalisé et essayons de comprendre les facteurs de réussite :

  • La voiture était fonctionnelle dès le premier sprint
  • Hannibal a pu changer l’orientation de son plan en cours de réalisation (enfin à la fin d’un sprint) pour blinder au mieux sa voiture.
  • Les surprises (ou l’effet tunnel) ont été complètement écartées grâce à des démonstrations régulières et des tests successifs.
  • Le temps était également maitrisé par le biais de la construction incrémentale (par exemple, on aurait pu s’arrêter au milieu de 2ième ou 3ième sprint en minimisant les dégâts vu que la voiture était déjà opérationnelle et armée)

Et avec une méthode prédictive ?

Le résultat aurait certainement été différent. Le but d’une méthode prédictive est justement de planifier dans un premier temps, de réaliser ensuite pour au final tester et vérifier le fonctionnement. La rigidité de cette méthode n’aurait pas forcement pu permettre d’anticiper le changement de stratégie quant au blindage de la voiture par exemple. Les conséquences auraient pu être dramatiques !

Imaginez, en planifiant tout depuis le début, l’ensemble des user stories semblent tenir dans le délai imparti (y compris la réparation de l’autoradio). Selon ce plan, durant la première et deuxième heure, on planifie et on réalise pour tester et assembler le tout la troisième heure. Evidemment, quand l’imprévu arrive (avec Hannibal qui veut par exemple blinder la voiture au tungstène) le plan ne tient plus la route et les délais vont être dépassés. Au mieux, la phase finale de test et d’assemblage sont réalisés rapidement voire très rapidement, ce qui nous expose à de potentiels gros problèmes (surtout si la voiture refuse d’avancer par exemple, faute de tests et d’essais). Ici, la perspective d’une voiture qui ne marche pas parfaitement ou d’un blindage défaillant est synonyme d’un aller direct pour la morgue. La réalité concernant la vie d’un projet n’en n’est pas forcement si éloigné, surtout si les contraintes étaient également fortement explicitées au départ du projet.

Conclusion

Cet exemple, fortement tourné en faveur de scrum je l’avoue, avait pour but de montrer qu’en environnement instable et sous contraintes fortes, un projet a tout à gagner à passer à l’agilité. Le fait de pouvoir aller à l’essentiel au plus vite, de casser l’effet tunnel et de maitriser ses contraintes (temporelles ou budgétaires) sont autant d’atouts pour mener à bien un projet sans accrocs, difficiles à retrouver dans les méthodes prédictives.

Quant au film, j’irai certainement le voir, en espérant y retrouver du bon sens agile bien appliqué !

[/caption]

Liens