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.

Sortez de votre bureau !

J’ai récemment participé au Scrum Day Europe à Amsterdam, une excellente journée de conférences, de réseautage et de discussions fructueuses avec des pairs.

Je pensais écrire un rapport à propos de ce jour, je crois enfin que la meilleure retrospective que je voudrais partager est que, de façon générale, chaque fois que je participe à des conférences, je reviens avec des nouvelles idées et avec un sentiment d’accomplissement.

Je recommande souvent à mes collègues et clients de planifier une ou deux conférences par an, de rencontrer des pairs et de voir ce qui se passe «à l’extérieur» du bureau.

Pour ceux parmi vous qui hésitent, j’ai quelques suggestions pour maximiser les benefices de l’expérience:

1 – Planifiez à l’avance. De nos jours, vous devez planifier et anticiper pour vous assurer que vous pouvez libérer du temps et obtenir les autorisations (parfois) nécessaires pour participer à des événements externes à votre société. Si votre entreprise effectue des évaluations annuelles, assurez-vous de demander à ce moment-là de participer à des conférences (au moins une par an)

2 – Sélectionnez avec soin la conférence à laquelle vous souhaitez participer. Pour le management de projet, mes favoris sont ceux organisés par le PMI et ses chapitres ou Scrum.org. Souvent, vous rencontrerez d’excellents orateurs, des sujets intéressants et des personnes passionnés et disposés à partager leur expérience

3 – Préparez vos objectifs, de sorte que vous serez de retour avec un sentiment d’accomplissement et de satisfaction. Les exemples pourraient être: ajouter 5 personnes supplémentaires à mon réseau professionnel, trouver des réponses à une question ou un problème particulier pour votre entreprise ou votre client, participer à la conférence d’une personne spécifique, rencontrer les personnes qui sont votre réseau professionnel virtuel, etc. .

4 – Ne vous déplacez pas que pour assister à des conférences. Assurez-vous de parler à différentes personnes, de partager des idées, des problèmes et des cartes de visite !

5 – Préparez un rapport comme rappel pour vous-même et pour votre entreprise ou votre client, de sorte que lorsque vous retournez au travail, vous pouvez partager les sujets qui vous ont aidé à résoudre ou à mieux comprendre certains problèmes ou à confirmer les décisions prises dans votre entreprise ou votre division.

Conseils spéciaux pour votre première participation à une conférence: la partie la plus difficile pour moi était de commencer à parler avec de nouvelles personnes. Prenez ceci comme un défi personnel (peut-être l’un de vos objectifs?), ciblez une personne, souriez et dire: « salut, mon nom est …, aimez-vous la conférence? » … le reste suivra !

Soit dit en passant, trouvez ici des vidéos et des présentations du Scrum Day Europe 2017, on se voit l’année prochaine?

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