L’année 2009 marque le début d’une grande histoire d’amour/haine entre l’équipe de développement web de DuProprio.com et la méthode Scrum dîte “agile“.
Nous entamons actuellement le 5ième sprint de l’année et l’instauration de la méthode se déroule relativement bien, mais certes pas sans générer certaines frustrations au sein de l’équipe et des gens qui gravitent autour.
Après 4 sprints, je me suis dis qu’il était temps de faire une rétrospective et d’essayer de comprendre ma propre opinion sur le sujet. À savoir : est-ce que j’aime ou je n’aime pas la méthode Scrum?
Les bons points :
Le matériel. Ça peut paraître niaiseux, mais c’est plaisant. Les cartes de planning poker, les grands tableaux blancs, les petits aimants en forme de post it, je dois dire que Sam nous a bien équipé dès le départ.
Pouvoir prendre son temps. Pour bien faire les choses. Pour se consulter. Pour être au courant de ce que tout le monde fait et des implications sur son propre travail. Pour bien penser les features en équipe plutôt que chacun de son côté enterré par ses propres urgences.
La carapace. Les développeurs dédiés au sprint sont quasi imperméables aux urgences pas si urgentes que ça qui ne manquent jamais de survenir normalement et qui empêchent d’avancer leurs dossiers principaux. Une fois la structure installée, c’est le/les développeurs responsables de la garde qui écopent.
La planification et l’ordre des priorités. À partir du moment ou les semaines sont gelées en blocs, le rôle et la responsabilité du Product Owner est multipliée par 10. Les demandes sont accumulées par sujets, et il n’y a plus de place pour les projets pas si importants que ça. Le travail devient automatiquement plus planifié (un peu) à l’avance et réfléchi.
Aide à comprendre. En se rencontrant à tous les jours et en voyant au tableau la progression des projets, il est beaucoup plus facile de voir les dérapages et de comprendre ce qui les cause. Ça aide à comprendre pourquoi un projet n’est pas encore fini après X semaines alors que d’habitude on a juste l’impression de tourner en rond et d’avoir des développeurs qui se pognent le steak…
Intègre l’équipe et mets en relation. Les démos avec les gens de la compagnie permettent une interaction particulièrement intéressante et du feedback qui n’était pas aussi présent lors des autres projets. L’équipe s’en trouve mieux intégrée à l’entreprise.
Les mauvais points :
Le mot Scrum. Ça sonne comme Scrotum. Bon… Ça a l’air de rien, mais ça n’aide pas à faire aimer la structure à ton boss quand il veut te balancer une urgence et qu’il ne peut pas à causes des méthodologies agiles…
Le livre dit de faire ça. Comme dans toute structure, il arrive des moments ou tout le monde a l’impression qu’on fait quelque chose qui sert à rien mais que la structure dit de le faire. Ceci dit, on est pas plus fou que d’autres et on sait très bien qu’il ne s’agit pas d’appliquer une recette exacte sans l’adapter à notre réalité. Il arrive quand même que certains intervenants ne voient pas la pertinence de chacune des étapes… Surtout dans les premiers sprints.
Un solide coup de pied dans les couilles de l’innovation. Le fait de savoir 6 mois d’avance les projets qui s’en viennent permet certes de mieux les planifier, mais ça élimine également presque complètement la place pour les dérapages et les bons flash. Ces concepts innovateurs qui mènent plus souvent qu’autrement sur une fausse piste, mais qui permettent aussi parfois de tirer dans le mille et de garder sa compagnie en avant des compétiteurs.
Ce qui est bien, c’est que DuProprio alloue du temps aux développeurs à chaque semaine durant lequel ils peuvent travailler sur ce qu’ils veulent. C’est ce qui nous a permis de créer la section Twitter il y a quelques semaines d’ailleurs…
Agile? Je crois que je ne comprends pas la signification du mot agile. Je veux dire… 3/4 des irritants qui ont été ressentis durant l’implantation de cette structure étaient liés au fait que l’on devenait moins agile… Moins apte à se revirer sur un dix cennes au gré des idées et des brainstorming.
On a jamais planifié autant que cette année (même si de l’avis de plusieurs nous ne le faisons toujours vraiiiiiiiiiiiment pas assez!). DuProprio a toujours été une compagnie excessivement agile, qui agit d’instinct, qui se trompe, qui se relève et qui score. Ça a toujours été notre point fort, mais aussi notre point faible… Alors bon, les choses changent, on vieillit et on devient plus sage j’imagine…
Chez DuProprio, Scrum n’est pas une méthodologie agile. C’est une méthodologie de développement réfléchi…
Qu’est qui vous à pousser à utiliser la méthodologie SCRUM plutôt que XP (eXtreme Programming) par exemple ?
Honnêtement, je ne connais pas vraiment le XP… Peut-être aurait-ce été plus adapté?
Je crois qu’à l’origine, l’idée du Scrum est venue de Sam qui avait eu des discussions avec des connaissances qui travaillaient avec la méthode. Et comme on était pas du genre à se poser des questions trop longtemps et qu’on sortait d’un projet qui avait été particulièrement dur à “closer”, on a décidé de se lancer et de voir ce que ça donnait.
Comment tu me résumerais ce qu’est le XP versus Scrum?
Merci de partager ça avec nous. J’avais aussi lu le post de Sam avec intérêt. C’est fascinant de voir comment vous fonctionnez chez DP «de l’intérieur», parce que «de l’extérieur» ça a l’air de bien marcher!
Ceci dit, les mauvais points que tu soulèves ne font pas trop peur, ça semble pouvoir se gérer. Par contre, en lisant entre les lignes, j’ai l’impression que ce qui est plus difficile à gérer, ce sont les perceptions des gens qui ne participent pas directement au Scrum, qui n’aiment pas le formalisme que ça implique et/ou qui croient plus ou moins à la nouvelle approche… je me trompe?? Si c’est le cas, comment vous gérez ça?
mmmmm, c’est encore drôle… Je suis même forcé d’avouer que les gens “hors Scrum” se sont bien adaptés à cette structure.
Le plus difficile je crois ce situe au niveau des développeurs qui sont partagés entre le sprint et d’autres responsabilités. Surtout ceux qui comme moi étaient habitués à plus de liberté de mouvement et qui, trop souvent, faisaient pencher la balance des priorités d’un projet vers un autre…
Bonjour Frédéric,
J’aime ta citation :”Chez DuProprio, Scrum n’est pas une méthodologie agile. C’est une méthodologie de développement réfléchi…”
Quand on se lance en méthodologie Agile, il faut réfléchir comment on va le faire. Il y a beaucoup de livres, de sites de références et même des experts (comme moi). Mais, la meilleure des solutions, c’est la solution que l’équipe a besoin.. !
Comme je dis souvent ..! Il faut trouver la recette qui nous (l’organisation, l’équipe) pour faire des méthodologies Agiles.
Il faut avoir la sagesse, de prendre ou non, ce qui est recommandé.
Je suis heureux de voir, et ce même si ce je ne vous ai pas conseillé directement, que ce je préconise depuis si longtemps porte afin ces fruits quelque part.
Quelqu’un m’a déjà dit, si tu crois fermement à une idée, sème-là au vent. Si elle est bonne, elle poussera sans ton aide quelque part.. !
Donc, mon idée.. N’était pas si folle que ca ..! car, tu m’a démontré.. quelle a données des fruits.. Même si je n’ai rien fait pour cela ..!
Bravo, et surtout continuez d’avoir une méthode agile intelligente.. et surtout bien pensée ..!
Bruno
J’aime beaucoup la perspective de l’article.
En ce qui concerne « Le livre dit de faire ca », lors de mes formations j’utilise plutôt le terme « approche » plutôt que méthodologie pour justement éviter l’encapsulation des idées. Mon conseil, serait définitivement de ne pas faire ce que vous trouvez inutile. Le premier principe du Lean est « Eliminate Waste ». Si une activité n’a pas de valeur ajoutée, éliminez-là . Si lors des rencontres, certaines personnes sont aliénées et marginalisées peut-être qu’ils ne devraient pas être à cette rencontre. Restez critiques…
Pour ce qui est de l’innovation, le principe des SPIKE et celui des CHORE existe justement pour ces raisons là . Lors de vos sprint, planifier des activités d’innovation, de découverte et de recherche, il n’y a aucune limitation pour ca…
Bonne continuité et afin de rester au faits de la communauté Agile à Québec, la communauté Agile de Québec (www.agilequebec.ca) offre de belle conférence mensuellement. Au plaisir de s’y rencontrer…
Georges Saad
[focusintelligence.ca]
[blog.focusintelligence.ca]
>Pour ce qui est de l’innovation, le principe des SPIKE et celui des CHORE >existe justement pour ces raisons là . Lors de vos sprint, planifier des >activités d’innovation, de découverte et de recherche, il n’y a aucune >limitation pour ca…
Le problème avec ces SPIKES et CHORE est qu’ils doivent être planifiés d’avance et être vendus à l’équipe et au PO lors du planning. Hors, lorsque l’on a un éclair de génie, en général on veut l’attaquer rapidement et surtout on ne connait souvent pas le résultat que ça va donner donc c’est pas toujours facile de vendre la tâche au planning surtout au PO. Faire le lien entre toutes nos tâches et leurs valeurs, ça peut être épuisant!!
Une solution simple à ce problème est de laisser un peu de temps libre entre les sprints aux développeurs pour qu’ils puissent travailler sur une idée qui leur tient à coeur. Ensuite, une fois que le concept a été un peu approfondi, c’est généralement plus facile de voir si l’idée vaut la peine d’être poursuivie et si elle vaut la peine d’être “prise” lors du prochain plannng.
C’est peut-être pas scrum mais tant que ça marche, moi ça me va
L’important c’est que ca marche, totallement d’accord.
Le danger que je vois c’est que la notion de SPRINT ne sert plus à rien étant donnée que le délai entre les sprint pour la R&D deviens imprévisible. Sinon on peut le planifier sans problème, on ajoute le délai qu’il faut à l’interieur du sprint. L’idée est justement de mesurer à intervalle régulier fixe, une même équipe pour un même projet (les trois paramètres d’un projet : temps, équipe et contenu).
En réalité, si c’est des éclairs de génies
et que ce n’est pas prévisible ni planifiable. Alors dans ce cas là ca deviens un coût fixe intrinsèque au projet qui va uniquement affecter la vélocité en la diminuant. Ce qui est super correct, en réalité ca va représenter la vitesse d’avancement réelle de l’équipe qui se donne à des activités d’R&D lors de la réalisation des User stories. Ca fait partie de l’effort de réalisation réelle de chaque tâche.
Pas besoin de trouver une valeur aux SPIKES et aux CHORES ils n’en n’ont effectivement pas aux yeux du « client » c’est un travail jugé nécessaire par l’équipe sans aucune valeur ajoutée fonctionnelle au produit. Ca fait partie du coût fixe d’un développement logiciel et ca affecte directement la vélocité.
Finalement, je n’ai pas besoin de dire qu’il faut rester critique, vous le faites déjà très bien
Au plaisir, Georges Saad
[focusintelligence.ca]
[blog.focusintelligence.ca]
Sérieusement, grand merci à tous pour vos réponses, c’est très agréable d’avoir votre opinion et votre participation!
Je me rends compte qu’il y a vraiment un “hype” que je ne voyais pas autour des méthodes agiles!
Pingback: Ma définition d’innovation « LABLOGATOIRE
Je suis tombé sur ce post via un fil twitter. C’est intéressant d’avoir le point de vue d’une autre équipe de développement.
Ici, je pense que cela dépend des projets. Certains projets n’ont pas le scope nécessaire pour justifier de “scrumer” alors que d’autres sont tellement imposants qu’on ne sait pas trop comment les prendre. Je suppose qu’on manque encore un peu de pratique…
“Agile? Je crois que je ne comprends pas la signification du mot agile. Je veux dire… 3/4 des irritants qui ont été ressentis durant l’implantation de cette structure étaient liés au fait que l’on devenait moins agile… Moins apte à se revirer sur un dix cennes au gré des idées et des brainstorming.”
Agile fait référence aux méthodes dites Water fall où tout était planifié longtemps d’avance. Avec une méthode agile, tu peux revoir tes priorités à chaque sprint et t’adapter aux changements dans les besoins. C’est certain que si vous passez d’un processus ad hoc vers scrum, tu auras l’impression de perdre en flexibilité, mais tu gagneras en productivité.
Pingback: DuProgrammeur » Pourquoi le Kanban?