Article tagué SCRUM

L’introduction des méthodes agiles dans une organisation cause souvent des problèmes d’adaptation à cause de la différence culturelle qu’elles amènent. La manière de fonctionner la plus répandu est que les séniors prennent les décisions et que les moins expérimenté les exécutent. Pour que les méthodes agiles fonctionnent il faut donner plus d’autonomie aux exécutants.

Ce problème peut être encore amplifié en Asie, du fait que la culture asiatique renforce le respect du supérieur.

InfoQ qui possède une structure en Chine a récemment réalisé une étude sur l’adoption de SCRUM en chine.

Une traduction libre de cette étude est présentée ci-dessous.

Les personnes interrogées et leurs entreprises sont présentées ci-dessous. Pour le respect des sociétés leurs vrais noms n’ont pas été utilisés.

• Julie – Une célèbre entreprise de l’internet – Réussit
• Kaverjody – Un célèbre éditeur de logiciel – Réussit
• David – Une célèbre entreprise de l’internet – Echec
• Alex – Nibirutech, une start-up – Réussit
• Fiona – Une start-up – Echec

Les cinq questions suivantes ont été posées à ces cinq entreprises installées en Chine utilisant SCRUM.

Pourquoi avez-vous utilisé SCRUM sur votre projet ?

Julie :

Les exigences changeaient trop rapidement, la feuille de route n’était pas claire, nous devions améliorer l’efficacité et la communication, et le service commercial devait pouvoir obtenir des résultats le plus tôt possible.

Kaverjody :

En raison des défauts dans le modèle de développement en cascade nous ne pouvions pas apporter des améliorations sans modifier la méthode de développement. Les top-managers ont pris la décision d’utiliser SCRUM pour résoudre les problèmes, par exemple le coût de maintenance très élevé, la livraison de nouvelle version nous prenais beaucoup de temps, etc

Alex :

La première fois que j’ai entendu parler de la notion d’agilité c’est lorsque j’ai rejoint NibiruTech en octobre 2007. À cette époque, la pratique agile que nous utilisions le plus était la réunion quotidienne. Je n’avais aucune idée quant à l’effet d’une telle réunion. J’ai essayé de comprendre et j’ai ainsi découvert SCRUM.

Comme beaucoup de start-up, nous n’avions pas beaucoup d’expérience dans les méthodes de gestion. Nous avons écrit notre propre méthode de gestion et l’avons utilisé conjointement avec TRAC. SCRUM m’a vraiment impressionné, j’ai donc décidé de populariser SCRUM au sein de notre entreprise.

Comment avez-vous adopter SCRUM, et pourquoi ?

Julie :

Nous n’utilisons pas du pur SCRUM. Au lieu de cela nous l’avons mélanger avec de nombreuses pratiques agiles, comme des pratiques d’XP et en partant de la rétrospectives SCRUM que nous avons adapté à nos exigences, pour finalement trouver notre propre modèle. Par exemple, si dans une rétrospective, nous constatons que nous devons améliorer la revue de code, alors lors du sprint suivant de nouveaux mécanismes de revue sont introduits.

Nous somme partie du bas pour aller vers le haut. Tout d’abord, nous n’avons fait des expériences locales, avec une petite portée, et ensuite nous l’avons étendu de plus en plus largement.

Nous avons également fait des améliorations au processus lors de l’adoption:

• Mars à Juin 2006 – utilisé dans une équipe d’environ 8 personnes.
• Juin 2006 à Décembre 2007 – utilisé dans trois équipes, environ de 25 personnes.
• Décembre 2007 à Janvier 2008 – Utilisé dans un département, 6 équipes, environ 50 personnes.
• Janvier 2008 à maintenant – Utilisé dans toutes les équipes.

Kaverjody :

Les top-managers ont pris la décision d’utiliser SCRUM dans l’entreprise.

Alex :

Je n’ai pas réfléchir à la manière d’adopter SCRUM à ce moment-là, je partageait uniquement les informations entre le CEO et mes coéquipiers.

A la question : « Comment avez-vous décider des mesures à prendre au cours de l’expérience ? Est-ce que vous vous êtes concentré sur les problèmes existants et choisis des pratiques agiles appropriées pour les résoudre ? Ou une autre manière de procéder ?

Julie :

En fait, nous n’utilisions pas le mot « SCRUM » au début. Nous avons discuté avec les commerciaux sur la date de livraison, nous sommes tombés d’accord sur une livraison tous les mois. La gestion du projet se faisait pendant la réunion quotidienne du matin et les améliorations étaient décidées pendant la réunion de conclusion du d’une itération. La rétrospective de la production et celle de l’équipe étaient incluses dans cette réunion de conclusion. Le chef de produit expliquait la situation actuelle, et tous les membres de l’équipe discutaient de nos réalisations, des défis et de nos lacunes. Pour la réunion de planification, nous avons suivi SCRUM depuis le début. MS Project n’étant pas approprié pour un petit projet, nous avons d’abord utilisé une feuille de calcul Excel SCRUM, puis ensuite nous somme passé à Xplanner.

Après quelques mois, nous avons réunis tout le monde pour une réunion de partage de connaissances sur les méthodes agiles. Il y a été présenté toutes les pratiques que nous avions utilisées, et expliqué la philosophie de l’agilité, d’XP et de SCRUM. Puis tout le monde s’est regardé et nous nous sommes aperçu que nous avions utilisé SCRUM pendant ces derniers mois.

Notre succès a été également confirmé par les managers, et nous avons été autorisés à partager notre expérience avec d’autres équipes. Nous avons alors choisi certaines équipes comme « pilotes ». Du fait que les développeurs pouvaient passé d’une équipe à une autre, cela augmentait les coûts de gestion si une équipe utilisait MS Project et un autre XPlanner. Nous avons donc utilisé SCRUM dans toute l’entreprise.

Quel est le plus gros problème rencontré lors de l’adoption, et comment l’avez-vous résolu ?

Julie :

Tout d’abord, nous avions besoin du soutien des dirigeants. Et puis, de dire la vérité, l’adoption de SCRUM est assez facile, beaucoup plus facile que CMMI.

Le plus difficile, c’est que vous devez résoudre les problèmes révélés dans votre processus, tels que:

1. « Nous n’avions pas d’exigences claires, ce qui à un coût élevé en communication sur les dernières étapes. Nous passons trop de temps à discuter avec le chef de produit encore et encore. »
2. « Cycle de livraison est trop long : notre Sprint est de 3 ou 4 semaines, mais le chef de produit souhaite que nous livrions deux versions par semaine. »
3. « Nous ne pouvions pas maîtriser les besoins et le produit en nous basant sur les caractéristiques de SCRUM« .
4. « La date de livraison était fixé par les commerciaux, nous n’avons pas le temps de faire des tests unitaires, ni code de la revue de code. »
5. « Nous ne pouvions pas voir clairement les goulets d’étranglement entre les tâches, ou la façon de coordonner tout le monde« .
6. « Nous avions besoin d’au moins une semaine pour analyser les données après le déploiement, il est impossible de conclure sur des amélioration à faire juste après le sprint actuel.« 
7. « Le rythme de développement était trop rapide, nous n’avons pas assez de temps pour s’arrêter et faire une bonne rétrospective. L’exigence historique n’est pas pleinement utilisé. »

Kaverjody :

Pour moi, la plus grande difficulté est les malentendus autour de l’agilité rencontrés parmi mes collègues. Ils pouvaient voir les outils et les pratiques de développement utilisés, mais ne pas comprendre l’idée sous-jacente dans ces choix. Pourquoi avoir choisi ces outils? Pourquoi prendre ces pratiques? Avions-nous des standards avant ces pratiques ? Ce n’est que dans les choix effectués que nous pouvons voir la valeur de l’agilité.

Il n’y aucun moyen d’atteindre son objectif d’un seul coup, le seul moyen est de sensibiliser les collègues en permanence. De plus nous devons également analyser et résoudre les problèmes à temps et analyser ce qui s’est passé ensuite. Expliquer pourquoi nous avons résolu les problèmes de cette façon et comment traiter les mêmes problématiques dans le futur.

Alex :

Je pense qu’il y a deux grandes difficultés avant l’adoption de SCRUM :

1. Le soutien des dirigeants. Je pense que c’est un problème commun. Jeff Xiong a publié un article pour InfoQ Chine: Agile step by step: how to do agile bottom-up, qui explique que si les dirigeants ne peuvent prendre en compte SCRUM, commencer par appliquer SCRUM uniquement dans l’équipe. Dieu merci, nos CEO et CTO ont soutenu SCRUM.
2. Formation SCRUM pour les employés. Mes collègues ne comprenaient pas clairement SCRUM, j’ai alors organisé une formation SCRUM. Nous avons répondu aux interrogations ensemble. Et lors de l’adoption, tout le monde est devenu de plus en plus familier avec SCRUM. Bien sûr, les personnes qui popularisent SCRUM doivent être familier avec.

Ensuite, InfoQ a demandé à chacun de présenter leurs solutions dans le détail :

Julie :

Pour le premier problème, « manque de clarté des exigences« , nous avons fait un modèle universel pour tous les cahiers des charges, et ajouter une réunion de discussion des besoins avant la réunion de planification. Le chef de produit, les testeurs et les développeurs participent également à cette réunion.

Pour le deuxième problème – « cycle de livraison trop long« , nous avons ajouté la prise en compte quotidienne des demandes de maintenance, en plus de nos livraisons. Le chef de produit recueille les demandes d’évolutions, tels que « modifier les pages », « Ajouter / supprimer des données ». Ces exigences sont soumis aux ingénieurs dans la réunion quotidienne tous les mardis et jeudis matin, pour être livré dans l’après midi.

Alex :

Nous sommes à un bon niveau de l’adoption de SCRUM. Peut-être parce que je n’ai pas compris SCRUM très bien, et que nous utilisons seulement certaines pratiques, mais j’ai une conviction: nous trouverons notre propre version de SCRUM dans les itérations à venir, dans les succès et les échecs. Nous étions habitué à des projets avec des définitions des exigences peu claires. Pendant la réunion de planification, nous listons tous les points techniques à partir des besoins fonctionnels connus, ils sont ensuite classés par priorité. Une itération est de seulement 10 jours, il est donc toujours possible de gérer le planning global. Pendant la réunion du matin, tout le monde indique sur le tableau les tâches qu’il va réaliser pendant la journée. Cela améliore la capacité d’auto gestion de l’équipe.

Quels avantages SCRUM a t’il apporté à votre projet, à votre entreprise ?

Julie :

Je pense qu’il est difficile de mesurer les bénéfices tirés de SCRUM. Nous avons fait une enquête dans les équipes et a obtenu quelques informations générales:

Kaverjody :

Il est difficile pour moi de tirer une conclusion. Les avantages que je peut voir sont : nous pouvons obtenir du feedback sur les fonctionnalités plus fréquemment, nous pouvons détecter certains problèmes plus rapidement, par exemple développement multi-sites et coopération, rétrospectives et améliorations.

Alex :

Nous utilisons SCRUM dans toute l’entreprise, du développement, aux commerciaux en passant par les ressources humaines. Nous ne présentons pas SCRUM aux nouveaux employés, ils peuvent se familiariser avec au cours des journées de travail. Je ne peux pas dire l’importance du gain, mais cela nous a aidés à travailler heureux, plein d’énergie, et nous avons terminé notre itérations avant la date butoire. Maintenant nous préparons le prochain projet.

Pourquoi n’avez-vous pas adopté Scrum avec succès? Pourriez-vous décrire le process utilisé ?

David :

Notre problème était le suivant: certains dirigeant n’ont pas compris l’agilité et SCRUM. Ils ont considéré l’agile comme une formalité. Par exemple, nous avions un Scrum Master sur un gros projet, qui s’est très bien passé. Un chef de projet a trouvé cela bien et a instauré le Daily Scrum dans plusieurs projets, sans savoir ce qu’était l’agilité, ce qu’était SCRUM. Le Daily Scrum est alors devenu grâce à lui le daily report, et les principes fondamentaux de SCRUM n’ont pas été respectés.

Tout le monde devait assister au Daily Scrum a l’heure fixé, et indiquer ses tâches de la journée au manager qui décidait si il / elle devait prendre plus de tâches ou non. C’est nul. Le «Daily Scrum » a été annulé, tout le monde a estimé qu’il était trop ennuyeux. Et par la suite plus personne n’a parlé d’agilité dans l’entreprise.

Diona:

J’étais dans l’équipe multi site et l’équipe chinoise ne connaissait que peu de chose sur l’agilité au début. Un jour, le chef de projet à l’étranger nous a envoyé plusieurs liens parlant d’un terme étrange : SCRUM. Nous avions seulement un ou deux jours pour lire des documents sur SCRUM, et puis nous avons du commencer les daily meeting. En fait, tout le monde connaissait l’importance de la communication, mais nous avions 6 à 7 heures de décalage horaire, alors quand ils arrivaient au travail le matin, nous nettoyons le bureau et on retournait à la maison. Le daily scrum n’a pas amélioré notre communication, et a été abandonné après une ou deux semaines. Nous avons essayé de faire des daily scrum dans l’équipe chinoise, mais le plus gros problème a été la différence culturelle entre les équipes et la planification du projet. Le daily meeting n’a rien apportée et est vite devenu une formalité. Finalement il a été abandonné.

Nous n’avions pas de réunions de planification. Nous avions un soi-disant product owner, mais il n’a jamais expliqué les détails de chaque user stories, il n’a pas non plus pu définir ce qui était terminé. Nous avons essayé la rétrospective par nous-mêmes, mais nous n’avons pas obtenu de réponse de l’équipe à l’étranger, et nous avons abandonné.

Lorsque nous avons utilisé pour la première fois ScrumWorks, le product ower n’a pas donné de priorité aux user stories, et nous avons fait des estimations. Mais maintenant tout le monde peut ajouter des user stories dans ScrumWorks, et personne ne fixe la priorité, c’est nous, les développeurs, qui décidons. Si il restait une centaine d’user stories à la fin du sprint, elles étaient simplement ajoutées au sprint suivant.

Pour finir

Il y a eu plein de réactions à la fin de l’écriture de cet article en version chinoise sur le Agile China Google Group qui seront rapporté plus tard.

Je me souviens d’un phrase célèbre de Shakespeare: « Il y a des milliers d’Hamlet dans les regards différents de millier de personnes. » Donc: que penser vous de SCRUM ? et comment avez vous adopter SCRUM dans votre organisation ? Pouvez-vous partager votre expérience avec nous ?

A propos de l’auteur

Jacky Li est l’un des acteurs principaux d’InfoQ Chine et de la communauté agile chinoise. Spécialisé en Java et dans le développement logiciel agile. Il s’est consacré au développement de l’agilité en Chine. Il est le traducteur de InfoQ sur le minibook: Starting Struts2..