Scrum… comment cela fonctionne…. vraiment!

Lors d’un dinner hier soir, nous avons discuté méthodologie et organisation en mode projet avec Mario Moreno.

Un moment donné, je me suis rendu compte que nous ne parlions pas de la même chose et je me suis mis à raconter l’histoire suivante:

scrumprocess

Houston, nous avons un projet!

  1. Un manager rencontre son Product Owner pour lui exposer son projet.
  2. Le Product Owner demande l’objectif et la vision du projet au manager. Tant que la vision n’est pas définie rien ne commence: la vision est immuable: ex. si la vision est de concevoir une bicyclette rose à tête de poney, cette vision restera inchangée jusqu’à la fin du projet. Si entre temps, le manager décide de changer d’avis et préfère un crocodile vert, dans ce cas c’est le Product Owner qui arrête le Scrum. Le Changement est permis pour les exigences par pour la Vision.
  3. Une fois la vision définie et validée, le Product Owner demande au Manager qui sont les utilisateurs du produit.
  4. Le Product Owner recondre les utilisateurs du product. Il leur explique la vision et leur demande quelles fonctionnalités ils auraient besoin: il utilise le format des users stories pour cela.
  5. Une fois ces stories collectées, le Product Owner et les utilisateurs les regroupent en epics et thèmes. Le Product Owner demande par quel thème les utilisateurs souhaiteraient commencer: cela donne le Plan de Release Initial. A cela, il leur demande les critères d’acceptation.
  6. Le Product Owner retourne chez le client. Il explique le Plan de Release Initial, les User Stories et les Epics qui constituent le Product Backlog Initial.
  7. Le client analyse ces données et le PO l’aide à le quantifier en fonction de la valeur business (subjective) que celle-ci représente pour lui. A cela, on priorise le Product Backlog en fonction des risques, obligations, contraintes de régulations, etc… Un point supplémentaire est abordé: quelle sera la Definition-of-Done pour le client. Voilà un Product Backlog Initial priorisé.
  8. Le Product Owner contacte  le Scrum Master avec lequel il a l’habitude de travailler. Il reexplique la vision, le Product Backlog priorisé, les Definition-of-Done, le Plan de Release initial. Pendant la discussion, ils font appel à différents experts interne: un architecte technique, un architecte fonctionnel, le QA, etc…. Scrum Master et Product Owner discutent des compétences disponibles pour démarrer le projet.
  9. Le Scrum Master constitue la Development Team. Une rétrospective de mise à niveau a été organisée avec toute la Scrum Team.
  10. Sprint Planning 1: le Product Owner explique à la Development Team la Vision, le Plan de Release Initial, le Product Backlog Initial, les Definition of Done, les options de tri du Product Backlog. L’équipe s’approprie le Product Backlog en estimant chaque story en fonction de sa complexité technique et sa faisabilité.
  11. Sprint Planning 2: la Development Team décide de sélectionner une portion du Product Backlog et la découpe en tâches: c’est le Sprint Backlog. Les 1eres esquisses techniques sont discutées. A la fin de la réunion, la Development Team s’engage à livrer le Sprint Backlog en fin de Sprint. La Definition-of-Done du Sprint ainsi que l’objectif du Sprint sont clairement énoncés, les indicateurs d’assurance qualité (level of done) sont documentés. La Scrum Team est ready pour démarrer son 1er sprint.
  12. Début de Sprint: le Sprint Backlog est affiché dans le Scrum board. La Development Team et le Scrum Master ont décidé d’utiliser Kanban pour dynamiser le développement. Une règle est fixée: une tâche ne doit pas nécessiter plus de 20 minutes pour être comprise sinon elle va au Parcking, si une tâche bloque dans le tableau elle reste en place dans le tableau.
  13. Lors du Daily Sprint suivant, la discussion se fait devant le tableau. Chacun montre les tâches sur lesquelles il travaille. On distingue clairement les tâches simples qui ont été rapidement développées: toutes « done ». Beaucoup de tâches dans le Parcking car pas suffisamment découpées, les points de blocages dans le process sont visibles également. Des solutions sont trouvées ensemble. Le Scrum Master prévoit une réunion de découpage (grooming) dans l’après-midi. La machine est mise en route.
  14. A la fin du Sprint, le Product Owner convoque le Management, le Client, les Utilisateurs et le reste de la Scrum Team dans la salle de formation pour la Revue. La Development commence par une revue rapide, le Product Owner rappelle le Product Backlog, la Definition of Done, l’objectif de Sprint. Un passage en revue de l’ensemble du travail est fait et le Product Owner accepte ou rejette les fonctionnalités/stories. Un point supplémentaire est fait avec le Scrum Master concernant l’assurance qualité et le processus. La Development Team invite les utilisateurs a s’asseoir devant les unités centrales pour tester le développement du Sprint: il s’agit de l’inspect-adapt des utilisateurs. Ces derniers donnent leur avis directement aux développeurs.
  15. Après la revue, le Scrum Master invite le reste de la Scrum Team (PO inclus) à la Rétrospective. Une revue de ce qui s’est passé en bien ou mauvais est faite. Les idées d’amélioration sont consignées et appliquées, les besoins en formation sont relevés, la capabilité de la Development Team est évaluée pour préparer le Sprint à venir.
  16. Le lendemain, un nouveau cycle s’installe avec le Sprint Planning 1.
  17. Le Product Owner reste en relation permanente avec les utilisateurs et le client pendant tout le projet. Les résultats de itérations sont consolidés pour former une Release que le Product Owner s’empresse de livrer.
  18. Scrum c’est livrer plus rapidement pour avoir un retour d’information réel du marché, pour maximiser l’investissement du client.

Voici donc le niveau a minima de Scrum. Les variantes de Scrum respectent cette architecture. Les nuances viennent :

  • des techniques d’ingénierie: charge de la Development Team
  • des protocoles de sécurité et/ou de compliance
  • de la taille de l’équipe
  • de la distribution de(s) équipe(s)
  • d’une configuration Scrum-of-scrums, Meta Scrum, Program Management à plusieurs niveaux d’entrée
  • de la Gestion du Produit et l’intégration de plusieurs niveaux de personae
  • etc…
Pour conclure,
  1. si vous utilisez Scrum pour développer avec un changement permanent de la vision, c'est peu être agile mais pas du Scrum.
  2. si le Scrum Master fait office de chef de projet, c'est pas du Scrum
  3. si le Product Owner ne travaille pas avec la Scrum Team, c'est pas du Scrum
Ces changements n'étaient pas dans la version initiale de Scrum en 1993, mais ils sont présents depuis 2004, soit il y a 9 ans.
scrumguide11FRNO

2 commentaires Ajoutez le vôtre

  1. J’aime bien l’exemple pour expliquer l’interdiction de changement de la vision !

    A propos du passage « La Development Team invite les utilisateurs a s’asseoir devant les unités centrales pour tester le développement du Sprint: il s’agit de l’inspect-adapt des utilisateurs. Ces derniers donnent leur avis directement aux développeurs. » :
    Il est effectivement très intéressant de pouvoir donner la main directement aux utilisateurs finaux même si je n’ai jamais eu l’occasion de le faire…
    Par contre cela n’engendre-t-il pas de la confusion que les utilisateurs finaux s’adressent directement à la Development Team plutôt qu’au PO ?
    Car même s’il y a échange lors de la rétro, il peut y avoir mélange des rôles, non ?

    1. PierreENeis dit :

      Merci beaucoup pour cette question Cécile à laquelle je vais me permettre de répondre sur plusieurs niveaux:
      1. Confusion entre Development Team et PO dans les yeux des utilisateurs:
      – en fait non, il s’agit de la partie « agile »où les développeurs se confrontent à la réalité du développement: des personnes en chair et en os, pour résoudre un problème donné et concret. Lors de la partie développement du Sprint (entre Sprint Planning 2 et Revue), les développeurs sont protégés et ne peuvent être atteints par les utilisateurs. Ici donc, le PO protège l’équipe et gère de façon permanente la relation « Scrum Team – User ».

      2. J’ai volontairement mis l’accent sur la « REVUE » et non sur la « DEMO ». La démo n’a que peu de valeur. Le point fort c’est l’inspect-and-adapt des utilisateurs.

      3. Lors de la revue, le PO reste le maître du jeu, mais il y a aucun jeu d’ego. Il pilote le produit pour le compte de la Scrum Team dont il fait partie.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s