S’adapter et évoluer vers Scrum

English version available on scrum.org website.

L’être humain, à travers les siècles, a réussi à s’adapter à beaucoup de situations et évoluer pour devenir ce que nous sommes aujourd’hui. L’histoire montre que nous avons une capacité innée de s’adapter et évoluer.

Scrum

Cela reste valable dans le cadre d’un changement en entreprise, comme l’adoption de Scrum.

Par le passé, j’ai pu remarquer que les changements réussis concernant l’adoption de Scrum ont suivi les trois principes suivants. Cela ne veut pas dire que ces principes sont universellement applicables.

Donner un sens au changement

Pourquoi faut-il changer ? Aujourd’hui je suis souvent appelé par des organisations qui n’arrivent plus à concurrencer les start-ups et perdent des parts de marché. Pour la plupart de mes clients, la mise sur le marché de nouveaux produits prend souvent des mois ou des années. Ils doivent évoluer pour rester compétitifs dans ce monde complexe et changeant. Adopter Scrum est un bon moyen de réduire les délais de mise sur le marché.

Connaître les règles du jeu (le cadre Scrum)

Comment travailler différemment ? Une fois convaincus et motivés par le changement, ou plus souvent pour s’en convaincre, il est nécessaire d’apprendre les règles du jeu. Pour cela, Scrum a des règles très simples et une formation est une excellente opportunité pour consolider son expérience ou apprendre à mettre en pratique Scrum. Mon expérience en formation, me permet aujourd’hui d’affirmer que nous devons réapprendre à collaborer (à tous les niveaux) et que la différence entre un changement rapide et un plus lent réside dans notre capacité à ne plus contrôler les personnes mais les résultats fournis par une équipe.

Jouer !

A ce stade il ne reste plus qu’a pratiquer, en gardant l’esprit ouvert, en étant conscients qu’il est peu probable (impossible ?) d’être parfaits du premier coup et que, parfois, il faudra aller relire la notice du jeu, ou demander l’aide de quelqu’un qui a déjà joué par le Scrumpassé. Finalement, pensez à la première fois que vous avez joué à votre jeu de société préféré, c’est la même chose ! Jouer à Scrum, surtout les premières fois, n’est pas facile : engagement, courage, ouverture, attention et respect sont les Valeurs Scrum qui vous permettrons d’inspecter votre manière de jouer et l’adapter pour jouer toujours mieux, comme des pro !

Conclusions

J’ai pu constater que ces trois principes ont permis, dans certains contextes, de réussir la transition vers une utilisation de Scrum. J’ai aussi observé le contraire, ce qui n’a pas fonctionné et fait revenir les équipes aux anciens reflexes.

Je suis convaincu que, dans un premier temps, il faut se forcer à s’adapter au changement en appliquant les règles du jeu. Avec le temps, grâce à la répétition des mêmes « gestes » vous évoluerez vers une adoption de Scrum qui ne sera que la première étape d’un parcours qui vous permettra de délivrer des produits de qualité dans un contexte complexe, tel qu’il est notre monde aujourd’hui !

J’adore jouer à Scrum en respectant les règles du Scrum Guide et vous ?

Transformation Agile à l’aide de Scrum

Transformation Agile à l'aide de Scrum
Le Papillon Monarque sort de sa chrysalide

La productivité de mon département informatique décrois chaque année. Plus de la moitié du budget est consacré à la maintenance et il devient de plus en plus difficile de démarrer de nouveaux projets. Nos concurrents peuvent livrer beaucoup plus rapidement que nous leurs applications en production. La motivation et le moral de mon personnel sont bas. Mon évaluation de performance de l’année dernière n’était pas très bonne …

J’ai entendu parler et lu Scrum, un framework per sur Scrum, un cadre pour développer et maintenir des produits complexes et comment il peut augmenter la productivité d’un facteur 10.

Même si je suis un peu sceptique quant à ces chiffres, j’ai décidé de transformer le département informatique et d’adopter Scrum comme cadre pour le développement de produits. Après tout, les risques identifiés sont acceptables et les gains potentiels énormes.

Je comprends que la complexité des projets informatiques augmente au cours des années et le prédictif n’est plus une approche efficace de créer des logiciels.

Je suis convaincu que l’empirisme (prenant des décisions basées sur l’expérience passée) et un cadre simple comme Scrum libèrent les capacités mentales des personnes et permettent de profiter des nouvelles opportunités.

Je suis prêt à être un acteur majeur de la transformation de mon département informatique, et j’ai pris des notes pour faire face aux obstacles futurs et aller de l’avant, je voulais les partager:

  • Déléguer une partie de mon travail quotidien à l’un de mes collègues de confiance
  • M’assigner le rôle de Product Owner du projet de transformation. Je serai responsable de maximiser la valeur fournie par ce projet et le travail de l’équipe de développement. Je suis bien placé car j’ai le pouvoir de prendre des décisions concernant les priorités
  • Recruter un coach agile avec une expérience Scrum éprouvée. Il / elle sera le Scrum Master et aidera à promouvoir et à adopter le cadre à la fois au sein de l’équipe et au niveau de l’organisation (aussi en dehors du département informatique)
  • Sélectionner entre trois et neuf personnes (volontaires) dans l’organisation susceptible d’aider à mettre en œuvre le changement. Ces personnes doivent avoir une mentalité d’amélioration continue et de leadership de service, ils sont les Scrum Masters qui promulgueront la transformation

Avec l’équipe nouvellement formée, je veux:

  • définir la vision et l’objectif du produit à fournir (changement organisationnel). Ce devrait être un objectif de très haut niveau, que je souhaite partager largement au sein de l’organisation
  • faciliter un atelier afin de définir le backlog initial pour le changement organisationnel (j’aurai probablement besoin de l’aide du Scrum Master)
  • mettre en place certains indicateurs clés pour suivre l’efficacité du changement (par exemple, le délai de mise sur le marché de toutes les applications que nous livrons)
  • commencer à « sprinter« , chaque mois, l’équipe montrera et communiquera les résultats du changement aux parties prenantes du projet (employés de la DSI et toutes les entité de la Société qui demandent des outils au service informatique)

Je sais que notre discipline et notre travail seront la clé d’un changement efficace, aucun consultant ou outil ne pourra remplacer mon implication sur ce changement, au moins à court terme.

Avec tout cela à l’esprit, je prends le téléphone pour rencontrer Christophe et commence à lui déléguer un peu de mon travail quotidien. Le voyage a commencé, je suis impatient de mettre en place l’équipe !

PS. Après avoir écrit cet article, j’ai commencé à chercher des références sur le Web. Je découvre que Scrum.org a publié le Agility Guide to Evidence-Based Change. Vous pouvez l’examiner pour un cadre plus formel sur le changement organisationnel. En outre, une vidéo explicative est disponible sur le web.

Agile: 20 leçons apprises avec Scrum

Learning AgilePendant les deux dernières années j’ai voulu apprendre Agile, particulièrement Scrum. Pratique intense, étude et certifications ont été un excellent moyen pour améliorer ma connaissance

  1. Scrum n’est pas automatiquement applicable à tous les projets
  2. Une formation de deux jours c’est un bon point de départ. Pour maîtriser Scrum il faut beaucoup de pratique et discipline
  3. Scrum est le véhicule, la destination et la route à faire pour créer le produit est décidée par l’équipe Scrum
  4. Pour appliquer Scrum, le management doit permettre (et même célébrer) les échecs, car ils constituent une chance d’apprendre et améliorer
  5. Le daily meeting n’est pas optionnel, ou hebdomadaire, il est vraiment à faire tous les jours 🙂
  6. Le management est un acteur important pour la mise en œuvre de Scrum, une bonne compréhension des principes agiles est fondamentale. Un manager agile agit en servant leader et élimine les obstacles qui empêchent l’équipe d’être performante
  7. Le rôle du chef de projet traditionnel disparaît, remplacé par les rôles du Product Owner et Scrum Master
  8. L’attitude “command & control” est abandonné en faveur de l’empirisme et de l’auto organisation. Le chef de projet devient “servant leader”, au service de l’équipe à qui il apprends le cadre et pour qui il élimine les barrières qui empêchent le travail
  9. Les 5 valeurs Scrum (Courage, Focus, Commitment, Respect, Openness) sont adoptés par l’équipe Scrum et, idéalement, par le management et l’organisation
  10. Un Scrum master expérimenté certifié ou un coach agile doivent être employés dans des équipes en transition depuis les approches traditionnelles waterfall vers Scrum
  11. Le Scrum Master n’est pas le responsable de l’équipe
  12. Le Product Owner n’est pas le responsable de l’équipe
  13. La DevTeam doit être dédiée au projet et polyvalente, il n’y a pas un chef d’équipe
  14. Les objectifs annuels des employés doivent être alignés avec les principes Scrum, pour favoriser la performance des équipes et la cohérence globale. Idéalement les objectifs individuels sont abandonnés en faveur d’objectifs d’équipe et de valeur délivré.
  15. Le sponsor du projet et le Product Owner doivent avoir une vision claire du produit à développer, sans cette vision la valeur produite par l’équipe sera moindre
  16. La “Sprint Review” (date et durée) ne s’adapte pas à la disponibilité du management
  17. La durée d’un Sprint ne change pas pour arranger les contraintes du Sponsor, du Management ou du Client
  18. Si des contraintes administratives ou organisationnelles doivent être respectées par le projet, elles seront incluse dans le Sprint, la vitesse de l’équipe en sera affectée
  19. Les définitions de “Ready” et/ou “Done” doivent prendre en compte les contraintes organisationnelles
  20. Dans un projet Scrum, coûts et délais sont fixés, la variable d’ajustement sont les fonctionnalités à développer