5 questions sur l'introduction de Scrum

Les organisations ne deviennent pas agiles du jour au lendemain par magie. C'est un processus de transformation significatif où chaque personne doit examiner et adapter son rôle. Et tout commence par le fait que la direction doit répondre à quelques questions plutôt complexes.

Face aux défis auxquels les organisations modernes doivent faire face, l'Agile est extrêmement attrayant. Qui ne voudrait pas avoir des releases plus fréquentes ? Qui ne voudrait pas mieux s'adapter à un environnement commercial en constante évolution ? Cependant, trop de dirigeants envisagent Scrum et entament une transformation agile sans comprendre les implications que Scrum peut avoir sur leur organisation, leur carrière et leurs objectifs.

Scrum n'est pas quelque chose qui devrait être introduit à la légère dans une organisation, et les dirigeants devraient se poser quelques questions complexes. Scrum n'est pas uniquement l'affaire des équipes de développement. Il ne peut pas être limité à une seule équipe. L'introduction de Scrum représente un changement systémique dans une organisation et est régulièrement décrite comme difficile et perturbatrice. Mais qu'est-ce que cela signifie vraiment ? Quels sont les impacts possibles de Scrum ?

Voici cinq questions auxquelles tu devrais répondre pour te préparer à une introduction de Scrum réussie et productive.

1) Comment réagir face aux changements qui affectent mon rôle ?

Cette question doit être posée par toutes les personnes d'une organisation, pas seulement par les équipes qui travaillent avec Scrum. Scrum a l'impact le plus direct sur les équipes, mais cela ne s'arrête pas là. Qu'en est-il des responsables ? Et comment réagirez-vous si votre rôle de leadership est affecté ?

Exemple : Scrum et le management intermédiaire

J'étais en train de prendre le petit-déjeuner avec mon ami John (nom modifié). John était responsable du développement dans une grande entreprise de services financiers où Scrum avait été introduit ces dernières années.

Il s'inquiétait de la façon dont son rôle était désormais perçu dans l'entreprise. Je lui ai demandé pourquoi il était inquiet, et il m'a répondu : « Au début, tout allait bien. Les équipes progressaient rapidement et un environnement de travail basé sur les équipes convient mieux aux gens qu'un modèle de services partagés. Mais maintenant, nous avons des équipes qui résolvent la plupart de leurs problèmes elles-mêmes et qui surveillent leur propre performance. »

Il voulait savoir quel était son rôle dans ce nouvel environnement auto-organisé.

La fonction des managers intermédiaires dans les entreprises inspirées du modèle du « Scientific Management » (taylorisme) tourne principalement autour de la performance et de l'efficacité des employés. On attribue au taylorisme une grande partie des gains de productivité du 20ème siècle. Cependant, il est moins adapté à la création de produits modernes basés sur la connaissance.

Comment le rôle du management intermédiaire évolue-t-il donc lors de l'introduction de Scrum ?

Après une brève discussion, John a décidé qu'il pouvait contribuer en servant de mentor et de communicateur pour ses équipes, en leur montrant ce dont l'entreprise a besoin, et en montrant à l'entreprise que ses équipes peuvent répondre à ces besoins.

2) Comment gérer vos meilleurs collaborateurs s'ils ne veulent pas participer à ce voyage ?

Tout le monde ne souhaite pas travailler avec Scrum. Beaucoup de gens apprécient Scrum parce qu'il leur permet de créer un produit sur lequel ils ont une influence directe, et cela peut être très gratifiant. Mais ce ne sera pas le cas pour tout le monde.

Exemple : La star mécontente

Jack était la star de son équipe et il s'assurait que tout le monde le sache. Quand l'équipe approchait d'une deadline, Jack travaillait souvent 80 heures par semaine pour que l'équipe atteigne son objectif. Il était souvent encore au bureau à 22h00 et envoyait même des e-mails à la direction le week-end. Le management l'adorait !

La qualité de son travail était cependant discutable. Il produisait beaucoup de code qui ne fonctionnait pas et nécessitait des retouches considérables. Après une autre nuit blanche au bureau, les autres membres de l'équipe passaient des jours à corriger les bugs de son code et à l'intégrer.

Ils ont essayé d'expliquer à Jack que son comportement affectait toute l'équipe – mais il n'a pas voulu écouter et a dit : « Réglez ça avec le management. »

La situation a changé quand Scrum a été introduit dans cette équipe. Les progrès et la transparence de l'équipe étaient discutés chaque jour pendant le Daily Scrum – les progrès quotidiens étaient donc mesurés en permanence par l'équipe. Comme l'équipe pouvait décider elle-même de la quantité de travail qu'elle accomplirait dans une itération, elle pouvait travailler à un rythme plus soutenable tout au long du projet.

Lors d'une rétrospective, l'équipe a remis en question la création de code non entièrement testé, qui faisait perdre du temps à toute l'équipe.

Jack n'a pas bien accueilli l'introduction de Scrum. La bonne transparence du Daily Scrum a clairement montré que Jack ne livrait pas de code régulièrement, mais repoussait le travail jusqu'au dernier jour du sprint. Quand l'équipe proposait des solutions aux problèmes, Jack se plaignait de micromanagement.

Il ne parvenait pas à travailler à un rythme constant et soutenable, et au lieu de se concentrer sur la plus grande valeur pour le client, il se plaignait que son travail était « ennuyeux » ou « pas stimulant ».

Quand l'équipe s'est engagée lors d'une Rétrospective à améliorer la qualité du code par des tests réguliers, Jack a menacé de quitter l'équipe et même l'entreprise. Cinq sprints après l'introduction de Scrum, Jack a quitté volontairement l'entreprise. La performance de l'équipe s'est régulièrement améliorée et trois ans plus tard, elle produisait toujours un produit de haute qualité.

Lors de l'introduction de l'Agile, les entreprises doivent réfléchir à ce qui doit se passer si leurs meilleurs collaborateurs ne veulent pas travailler dans une équipe Scrum. Les laisseriez-vous partir ? Ou devraient-ils rester dans l'entreprise et potentiellement perturber d'autres équipes Scrum ? Si vous êtes prêt à les laisser partir, comment justifiez-vous cette décision ?

3) Quels mécanismes utiliserez-vous pour provoquer des changements de comportement ?

Scrum nécessite des changements de comportement ; cela inclut l'auto-organisation, une collaboration accrue et la transparence. Changer les comportements est extrêmement difficile, surtout pour les collaborateurs de longue date qui ont été formés à se comporter d'une certaine manière. Maintenant qu'un changement est nécessaire, comment vous assurez-vous qu'il se produise vraiment ?

La formation continue joue un rôle majeur ici.

En tant que leader dans le management, on peut soutenir les collaborateurs avec des formations, du coaching et des conférences, et les aider à comprendre et à appliquer les méthodes modernes de développement logiciel. Et en montrant de l'engagement envers les collaborateurs, le moral et la satisfaction des employés ainsi que de l'entreprise peuvent s'améliorer.

Une partie essentielle de ce changement de comportement concerne la confiance au sein de l'équipe. Si je travaille avec quelqu'un et que cette personne comprend mon travail, est-ce un risque pour mon évaluation de performance ? Est-ce un risque pour mon emploi ? Comment construire la confiance si l'on peut répondre « oui » à l'une de ces questions ?

Une approche courante consiste à modifier les responsabilités et les indicateurs sur lesquels les collaborateurs sont évalués. Pour encourager un comportement coopératif, le travail d'équipe est davantage valorisé que la performance individuelle. Cela peut se faire avec un feedback basé sur l'équipe ou à 360°.

Accorder moins d'importance à la performance individuelle remet en question les responsabilités individuelles. Personne ne veut être responsable d'un domaine particulier s'il est jugé sur la performance de toute l'équipe. Par conséquent, les membres des équipes Scrum devraient naturellement se voir confier la responsabilité de différents domaines. Cela signifie qu'ils devraient livrer une partie d'un produit potentiellement livrable à chaque sprint.

Cela peut sembler insignifiant, mais cela a un impact majeur sur le fonctionnement d'une entreprise. Comment cela affecte-t-il votre structure organisationnelle si les équipes sont responsables du travail dans plusieurs domaines différents ?

4) Que pensera le département support des changements provoqués par Scrum ?

Scrum est généralement introduit dans une organisation par les équipes de développement logiciel. On pense rarement aux équipes de support et d'architecture en amont. C'est parce que beaucoup d'organisations supposent que « Scrum est quelque chose que font les développeurs ».

En réalité, Scrum affecte définitivement aussi les autres équipes. Comment les équipes de support réagiront-elles, par exemple, s'il y a des points de friction avec les équipes Scrum ? Comment ces problèmes seront-ils alors résolus ?

Exemple : Désaccords entre différents départements

Sarah était une architecte senior Java Messaging Service (JMS) et responsable de la vision d'entreprise d'un Enterprise Service Bus (ESB). Elle était de plus en plus frustrée parce que les équipes Scrum « ignoraient les directives de l'entreprise, soit en contournant l'ESB, soit en ajoutant de nouvelles fonctionnalités qui n'étaient pas alignées sur la stratégie de l'entreprise ».

Quand on lui a demandé pourquoi les équipes se comportaient probablement ainsi, elle a dit que les équipes avaient besoin de plus de discipline et d'une meilleure formation sur la stratégie ESB. Et puis elle a ajouté : « Mais peut-être que nous ne répondons pas non plus à leurs exigences. »

Après une discussion plus approfondie, Sarah a décidé qu'il serait probablement préférable de rejoindre une équipe Scrum pour comprendre leurs défis et les aider à mieux comprendre les objectifs de l'entreprise.

5) Combien l'entreprise est-elle prête à investir dans cette transformation ? Et quelle valeur sera livrée pour cet effort ?

Peu d'entreprises ont une idée claire à l'avance de combien elles gagneront approximativement avec l'Agile. Il y a peu d'informations sur le chiffre d'affaires que l'on peut attendre. Cependant, il y a des preuves constantes que Scrum permet d'obtenir des releases plus fréquentes, une meilleure qualité de produit et un contact plus direct avec les clients.

Une bonne solution est un budget annuel fixe pour la formation et le coaching permanents des collaborateurs. Cela devient cependant problématique si l'introduction de Scrum avance plus vite que le budget ne le permet. C'est aussi difficile à justifier si l'on ne peut pas dire clairement combien de chiffre d'affaires cela génère.

Une meilleure solution serait de mesurer quelques indicateurs clés, tels que :

• Chiffre d'affaires par collaborateur
• Satisfaction client
• Satisfaction des collaborateurs
  Si les dirigeants observent si ces indicateurs s'améliorent grâce à Scrum, ils peuvent voir à quel point l'introduction de Scrum est efficace et s'il faut changer quelque chose.

Il y a cependant quelques points intéressants avec cette approche qui méritent d'être soulignés :

Premièrement, cette méthode est indépendante du framework utilisé et pourrait également mesurer la performance d'une entreprise qui ne travaille pas avec l'Agile. Deuxièmement, vous découvrirez peut-être que Scrum n'est pas la meilleure approche pour votre entreprise ou qu'il existe des frameworks plus efficaces que Scrum. C'est rare, mais c'est bien sûr possible.

Ken Schwaber a récemment repris cette approche de mesure dans son « Evidence-Based Management » (management basé sur les preuves). Il est encore trop tôt pour dire quel impact cette approche aura sur le développement logiciel, mais c'est une solution très intéressante et elle a le potentiel de fournir aux entreprises des preuves concrètes de leur amélioration.

La conclusion

Introduire Scrum n'est pas quelque chose qui devrait être fait à la légère. Il y a un risque tant pour l'organisation que pour les individus. En comprenant les questions que les gens posent, on pourra mieux saisir leurs motivations, leurs peurs et leurs doutes. Et avec ces connaissances, on pourra élaborer une approche beaucoup plus complète qui répond aux besoins de l'entreprise et des collaborateurs.

« La capacité de penser logiquement est l'une des choses qui nous définissent en tant qu'êtres humains. Dans un monde d'information omniprésente et d'outils d'analyse sophistiqués, la logique seule ne suffit cependant pas. Ce qui distinguera les personnes qui réussissent, c'est leur capacité à se mettre à la place de leurs semblables, à construire des relations et à prendre soin des autres. »
– Daniel H. Pink, auteur à succès de Drive

(Anmerkung: Dies ist ein Gastbeitrag von Scrum Trainer und Coach Kane Mar, dem Gründer von Scrumology.com und Scrum101.com.) Ce texte provient du blog d'Openview et a été traduit par nos soins en français.