Lorsque je délivre une formation Professional Scrum Master ou que j’aide mes clients à créer des produits géniaux avec Scrum, on me demande comment adapter (rétrograder) Scrum pour le faire fonctionner dans leurs entreprises.
Ma réponse est toujours la même: Scrum change l’entreprise ! Laissez-moi vous expliquer pourquoi ce n’est pas le contraire.
1 – Les hiérarchies ont été prouvées utiles pour le travail répétitif. Le Génie Collectif est nécessaire pour résoudre des problèmes complexes et apporter de la valeur; il est obtenu grâce à des réseaux intelligents d’équipes auto-organisées et pluridisciplinaires, reliées entre elles par des valeurs et des responsabilités.
Arrêtez de contrôler les personnes, commencez à contrôler la valeur délivrée!
2 – Les cadres intermédiaires, ou d’autres postes de management peuvent grandement contribuer au changement. Toutes ces personnes ont l’opportunité de faire la transition vers l’un des trois rôles proposés par Scrum : Product Owner pour ceux qui aiment le développement de produits, rejoindre l’Equipe de Développement pour les plus « techniques » (développement, marketing, vente, sécurité, qualité, etc. .) et enfin Scrum Master pour ceux qui aiment former, enseigner et aider les individus à comprendre et à mettre en œuvre le cadre Scrum tel que décrit dans le Guide Scrum.
3 – Passer du temps à trouver comment réduire les risques, prédire les résultats futurs, comment contrôler les gens ne crée pas de la valeur. Au lieu de faire des plans, commencez à crée votre premier incrément, à inspecter et à adapter pour améliorer la prévisibilité et réduire les risques. Scrum c’est de l’action utile… pour délivrer de la valeur.
Scrum est un cadre simple pour livrer des produits complexes. Il aide les organisations dans leur transformation, pas le contraire.
Photo by Ross Findon on Unsplash
Changer Scrum ne vous aidera pas à : réagir rapidement aux changements du marché, réduire votre temps de mise sur le marché, augmenter l’efficacité de votre entreprise, avoir des employés plus sains et plus heureux et, en fin de compte, gagner des parts de marché !
Nous avons tous un rôle à jouer, oublions les hiérarchies et pensons que vous pouvez contribuer à la création de valeur pour vos clients grâce à vos produits.
Comme le co-créateur de Scrum, Ken Schwaber, a écrit sur son blog: « Scrum est comme les échecs. Vous pouvez jouer selon les règles, ou pas. Scrum et les échecs n’échouent pas et ne réussissent pas. Ils sont joués ou non. «
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 …
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
Scrum n’est pas automatiquement applicable à tous les projets
Une formation de deux jours c’est un bon point de départ. Pour maîtriser Scrum il faut beaucoup de pratique et discipline
Scrum est le véhicule, la destination et la route à faire pour créer le produit est décidée par l’équipe Scrum
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
Le daily meeting n’est pas optionnel, ou hebdomadaire, il est vraiment à faire tous les jours 🙂
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
Le rôle du chef de projet traditionnel disparaît, remplacé par les rôles du Product Owner et Scrum Master
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
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
Le Scrum Master n’est pas le responsable de l’équipe
Le Product Owner n’est pas le responsable de l’équipe
La DevTeam doit être dédiée au projet et polyvalente, il n’y a pas un chef d’équipe
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é.
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
La “Sprint Review” (date et durée) ne s’adapte pas à la disponibilité du management
La durée d’un Sprint ne change pas pour arranger les contraintes du Sponsor, du Management ou du Client
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
Les définitions de “Ready” et/ou “Done” doivent prendre en compte les contraintes organisationnelles
Dans un projet Scrum, coûts et délais sont fixés, la variable d’ajustement sont les fonctionnalités à développer
En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de Cookies. OK pour savoir comment supprimer les cookies En savoir plus
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.