Étiquette : Agile

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.

Pendant 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