Bye Bye Scrum

R.I.P. ScrumJ'arrête Scrum.

Ce n'est pas un billet de premier avril qui aurait un peu de retard : j'arrête volontairement et définitivement l'utilisation de Scrum.

Il y a 4 ans, j'annonçais que, après quelques années de bricolages méthodologiques agiles, j'avais pris une approche relativement formelle pour passer à Scrum. Compte-tenu de mon contexte d'alors, je pense que c'était la bonne chose à faire.

Au fil du temps, l'équipe a gagné en compétence sur les pratiques agiles. De début 2007 à mi 2010, cinq releases de notre principal produit se sont succédées et, dans les derniers temps, les sprints se suivaient sans le moindre souci à gérer. En juin 2010, nous avons démarré une nouvelle ligne de produit avec un changement technologique assez conséquent.
D'un point de vue gestion de projet, le premier impact visible (et attendu) fut le changement de vélocité. Sur le produit précédent, le graphe de vélocité ressemblait à une mer d'huile. Sur les premiers mois du nouveau produit, il donnait plutôt dans la coupe d'une étape pyrénéenne du tour de France. Cela n'avait rien d'affolant : le contexte avait changé et il fallait quelques mois pour stabiliser la pertinence des estimations.
Ce n'est devenu plus problématique qu'en novembre lors de l'approche de la première release. La dernière itération avant la date butoir fut vécue comme une sorte de fin de projet où il fallait absolument livrer toutes les fonctionnalités prévues.

Je ne sais si j'ai été influencé par mes lectures d'alors[1] ou par quelques présentations intéressantes sur Kanban lors de l'agile tour mais j'ai pris -sans en parler à quiconque- une décision.
Puisque les fins d'itérations sont si mal vécues, c'est qu'elles n'ont pas que du bon. J'allais donc désormais m'abstenir d'envoyer des invitations pour la moindre réunion relative à une itération. Si un backlog ou une revue de sprint venait à manquer à quelqu'un, il ou elle le ferait probablement savoir...

Depuis quatre mois, nous n'avons plus formalisé la moindre itération.

A-t-on des problèmes pour définir le travail à réaliser ? Non. Il y a en permanence 2 ou 3 éléments du backlog de produit qui sont en cours de réalisation. Dès qu'un est terminé, celui qui suit par ordre de priorité prend sa place et est immédiatement découpé en taches.
A-t-on des problèmes pour rendre visible l'avancement du travail ? Non. Dès qu'un élément du backlog est terminé, il est présent dans le build du produit, lequel est immédiatement disponible pour qui voudrait l'essayer.

Progressivement, notre mode de fonctionnement passe d'un cadencement par les itérations à un flux qui s'écoule de manière plus régulière. La métaphore du "sprint" était en fait très bien choisie. On avait juste oublié qu'il est plus facile de gérer son effort dans une course de fond que dans une succession de sprints.

Bien sûr, tout cela n'est pas aussi simple. La disparition des itérations entraine des contraintes plus importantes sur certains aspects du processus.
L'intégration continue est un de ces aspects : la nécessité d'un build à jour et en état livrable est quasi-permanente. Heureusement, les efforts consentis sur la mise en oeuvre sans concession d'un développement piloté par les tests commencent à porter leurs fruits.
La planification des estimations doit, elle aussi, s'adapter au flux. Il n'y a plus de "début de sprint" où on peut estimer tout ce qui aurait pu entrer dans le backlog de produit pendant le déroulement du sprint précédent.

La définition de la vélocité et, plus généralement, du plan de release est probablement le changement le plus significatif.
Pour la vélocité, on a pour l'instant fait très simple. Quand on a des itérations de 4 semaines, la vélocité, mesurée en fin d'itération, c'est la somme des points des éléments du backlog terminés au cours des 4 dernières semaines. Et quand on n'a plus d'itérations ? Et bien, rien ne nous empêche de continuer à prendre la même mesure !!! On a une vélocité calculée sur une fenêtre glissante qui change chaque jour. Si le flux des éléments de backlog s'écoule régulièrement à travers l'équipe de développement, cela ne change rien par rapport à une mesure de vélocité par itérations.
D'ailleurs, il faut bien comprendre que la vélocité ne sert, au final, qu'à une seule chose : proposer une date de release la plus réaliste possible. Quand on a des itérations, la taille du backlog de release divisée par la vélocité nous donne le nombre d'itérations restant à effectuer pour terminer la release. Quand on n'a plus d'itérations, on divise toujours la taille du backlog de release par la vélocité, puis on multiplie par la taille, en jours, de la fenêtre de calcul de la vélocité et on obtient une approximation guère moins exacte du nombre de jours restant avant la release...

Finalement, la suppression des itérations et le passage à un processus de flux n'a rien de bien compliqué. Le point à surveiller le plus crucial est le maintien du flux. On doit en permanence garder à l'esprit qu'il vaut toujours mieux achever ce qui est déjà commencé que de commencer autre chose. Concrètement, cela veut dire que si un développeur termine quelque chose, il devrait, avant de prendre une nouvelle tache, toujours se demander s'il ne peut pas aider un collègue à terminer une tache en cours.
Ce n'est pas grand chose mais je crois que c'est une notion fondamentale. Quand on fonctionne par sprints, on a tendance à remplir un backlog de sprint avec des taches et à ne plus trop se préoccuper de la valeur de chacune de ces taches. Pourtant, à un instant donné, une tache qui permet de terminer la réalisation d'une histoire utilisateur a énormément plus de valeur qu'une autre tache qui ne fait que démarrer la réalisation d'une autre histoire.
Le but d'une méthode agile n'est-il pas de fournir, dans un délai le plus court possible, de la valeur pour les utilisateurs tout en conservant un rythme viable sur une longue durée ?

Il y a là, je pense, matière à réflexion pour toute équipe pratiquant le développement itératif.
En ce qui me concerne, le pas est franchi. Scrum, c'est fini. Désormais, tout se passera dans le flux.

Notes

[1] Je ne lis pas souvent mai, en novembre dernier, j'ai notamment apprécié "Lean Management" de Pierre Pezziardi et "Who Moved My Cheese ?" de Spencer Johnson

claude

Ca paraît logique. En te lisant, une seule chose me turlupine, c'est l'emploi du je. On a l'impression que c'est ta décision alors qu'on s'attend à ce que ce soit celle d'une équipe.

Oaz

Salut Claude,

Je comprends tout à fait ta remarque et, à l'origine, c'est effectivement une décision personnelle. Je n'ai à aucun moment démandé aux autres "Est-ce que vous voudriez essayer de ne plus faire d'itérations ?"
En tant que scrummaster, c'est moi qui lançait les invitations pour les réunions de planification de sprint et les demos de fins de sprint. Il se trouve qu'à un moment j'ai décidé unilatéralement de ne plus le faire.

A partir de là, il pouvait y avoir de nombreuses possibilités. Citons en quelques unes :

  • l'équipe décide que les itérations sont indispensables à son bon fonctionnement et continue à en faire en se les planifiant elle même, justifiant par là une partie de l'inutilité de ma fonction
  • l'équipe considère que je ne fais pas mon boulot et me demande de reprendre les invitations qui cadencent les sprints
Ce qui s'est réellement passé, c'est que, pendant 3 mois le boulot a continué d'avancer sans que personne ne se soucie une seule seconde de la présence ou l'absence d'itérations. Ce n'était donc peut être pas une décision consciente et fortement affirmée de la part de l'équipe mais c'était une décision quand même. Ce n'est que tout récemment que j'ai commencé à proposer quelque chose de plus organisé pour travailler en mode flux.

Ceci étant dit, le "je" de la première phrase ne signifie pas que j'imposerai à quiconque de ne plus faire de scrum. Il signifie surtout que je n'ai plus envie de travailler dans une équipe qui utilise scrum.
Oaz 5 avril 2011 - 10:04
pierre

Salut,

Feedback intéressant, je note que le passage d'une approche itérative à une méthode de flux est plutôt favorable dans une structure disposant d'une certaine maturité, ou les mécanismes d'agilité sont bien compris.

Quid du PO ? peut-on en déduire que votre P.O ne s'est pas inquiété de la disparition des Review et Planning ?

"Ce qui s'est réellement passé, c'est que, pendant 3 mois le boulot a continué d'avancer sans que personne ne se soucie une seule seconde de la présence ou l'absence d'."

Perso je trouve cela un peu trop arbitraire et cela aurait pu être relativement dangereux pour l'équipe. Mais cette reussite est sans doute liée à la maturité de la votre.

Le fait de provoquer réguliérement un meeting pour faire un constat demeure pour moi indispensable, car même avec la meilleure volonté des co-équipiers, il risque d'y avoir une perte de reflexion et d'auto-analyse, inconsciente, et qui auparavant était suggérée et stimulée par un cérémonial.

++

Oaz

Bonjour Pierre,

Je me rends compte que j'ai passé peut être un peu trop vite sous silence certains aspects. La fin des itérations à travers la fin formelle des débuts et fin de celles-ci n'a pas signifié (heureusement !) la rupture de tous les canaux de communication :

  • Le daily standup a toujours continué
  • Le P.O. a toujours vu les choses progresser et n'a pas eu moins de livrables qu'attendu entre les mains. Il n'y a pas eu moins de dialogue entre le P.O. et le reste de l'équipe
  • L'équipe a toujours pris 2 heures par semaine pour travailler l'amélioration de pratiques de développement (façon "dojo") ou pour discuter de toute chose relative au produit (architecture, pratiques de test utilisées, intégration continue...) En général, on alterne d'une semaine sur l'autre les 2 types de rassemblement (dojo/produit)
La seule chose qui a vraiment changé dans les relations entre les parties, c'est la notion d'engagement pour un contenu sur une durée fixée et la vérification de cet engagement à la fin de cette durée. D'ailleurs, en exprimant les choses comme cela, je me rends compte que si une équipe considère un sprint de 3 semaines comme un "projet au forfait" de 3 semaines, c'est qu'il y a probablement un problème quelque part.
Oaz 5 avril 2011 - 12:54
sfui

Hello,

je trouve cela très intéressant car je suis un peu dans la même réflexion. Cependant, j'ai encore quelques réticences à passer le pas et je crois que c'est lié aux mêmes questions que Pierre…

Je trouve qu'effectivement il est fait peu état du P.O. Soit, il est parfaitement intégré à l'équipe, il suit l'avancé du projet et peut en faire part à l'équipe commerciale et donc tout va bien…
Soit ce n'est pas le cas alors ?!
De notre côté, la revue de sprint est un moment assez privilégié pendant laquelle toute la société se cale sur les développements et voit vers où l'on va. Au passage, ne pas finir une storie avant une revue n'est pas considéré comme un drame et du coup, pas de fin de sprint "à l'arrache", l'effort est plutôt réparti.

Je suis également un peu étonné de la méthode qui semble démontrer une certaine "passivité" de l'équipe. Je pense qu'il y en aurait plus d'un qui me serait rentré dedans si j'oubliais quelque chose d'aussi important ;-) (même si ce n'est pas toujours trop justifié d'ailleurs).

D'ailleurs, le fait de devoir "lancer les invitations pour les réunions de planification de sprint et les demos de fins de sprint" montre là aussi, me semble-t-il une passivité latente… Que se passait-il quand tu étais en congés ? Le rythme de scrum fait que les choses se font "naturellement" sans devoir inviter les gens, ils savent non ?
Ce qui, de mon côté, me fait poser la question du besoin du scrum master… mais c'est une autre histoire.

sfui 5 avril 2011 - 13:11
Antoine

Fins d' mal vécues, signes d'un management un poil command & control, modification majeure unilatérale du mode de gestion de projet qui ne suscite aucune réaction de l'équipe, équipe qui vit une comme un mini forfait... à te lire on a l'impression d'une implantation de scrum assez louche.
Rien que pour ça, ça valait le coup de changer :)

Antoine 5 avril 2011 - 13:48
Aurélien Pelletier

Intéressant, on a pris la même décision dans mon équipe. L'influence de la monté en puissance de sans aucun doute. On a fait du scrum pendant 8 mois, maintenant que ça tourne correctement, c'est vrai que les sont plus un frein qu'une aide. Par contre ça me semble délicat de démarrer directement un projet en flux. Les de scrum aident l'équipe à trouver un rythme au départ.

Oaz

Bonjour Sylvain,

Il y a peut être une passivité latente sur certaines pratiques, mais, au bout du compte, je me dis que c'est parce que la valeur fournie par les pratiques en question n'est pas si évidente que ça. Si les développeurs prennent naturellement les stories dans le backlog et font avancer le produit, la nécessité d'un démarrage formel de sprint n'a finalement que très peu de valeur.

Sur l'aspect "invitations", c'est avant tout une question pratique de synchronisation (d'autant plus que le PO n'est pas sur le même site). Que je sois en vacances ou pas importe peu. Je ne parle pas d'une invitation à 2 ou 3 jours : il m'arrivait régulièrement d'envoyer des invitations outlook pour les 4 ou 5 mois à venir. D'ailleurs, moi le premier, si la date de fin de sprint n'est pas dans mon calendrier outlook, je suis à peu près certain de l'oublier. C'est en fait peut être de là que vient le "problème" : on n'a jamais été obnubilé par les dates... ;-)

Je te rejoins sur la question du besoin du scrummaster mais je pense qu'on peut l'aborder sous plusieurs angles. Les choses peuvent effectivement se faire "naturellement" et le boulot du scrummaster devenir un rôle collectif. Mais des changements radicaux tel la suppression des itérations ou tout ce qui diminue le cérémonial peuvent être encore plus efficaces : ils suppriment des activités devenues obsolètes.

Oaz 5 avril 2011 - 14:23
pierre

Hello,

"Le P.O. a toujours vu les choses progresser et n'a pas eu moins de livrables qu'attendu entre les mains. Il n'y a pas eu moins de dialogue entre le P.O. et le reste de l'équipe"

En fait, si j'ai l'air un poil réticent c'est que:
- j'ai l'impression que la maturité est indispensable pour entreprendre un swich /flux, chose que je ne vois pas trés souvent.
- Les objectifs pratiques (surtout communication) de Scrum risquent de fondre aprés plusieurs projets. De nouvelles personnes vont arriver, d'autres vont partir, le P.O ne sera pas le même, etc. Est-ce que cette approche sera aussi efficace avec une nouvelle équipe de 8 personnes ?. J'ai l'impression que si tu ne conserves pas un cérémonial cadré avec le P.O, c'est "la porte ouverte à toutes les fenêtres".

++

pierre

Concernant les invitations, idéalement on devrait s'en passer. Mais dans la (ma ?) réalité c'est indispensable.

Ludovic

Bonjour il y a des choses intéressantes dans cet article je suis d'accord avec une transitIon de scrum vers Kanban quand l'équipe est mature. Il faut voir en fait les différentes méthodologies comme une boite a outil pour un coach agile afin d'étudier la meilleure methodo en fonction des projets et pour moi chaque methodo a sa place.

Cordialement,

Ludovic

Ludovic 5 avril 2011 - 22:19
Jonathan Scher

Bonjour,

Une question tout de même : comment gérez vous l'amélioration continue ? Scrum suggère une d', mais vous ?

mde

Vécu similaire sur mon projet en cours. On a démarré en scrum de scrum (pic à +80 personnes au plus fort du projet), et au bout de qqs mois de fonctionnement stabilisé, on a glissé vers Kanban.
On garde toutefois des démos tous les 15j pour que personne ne perde de vue l'avancée des autres équipes sur le plan fonctionnel. A l'issue des démos, on a également les retrospectives qui restent utiles.
Le rituel de daily stand-up est conservé, également celui qui réunit les chefs d'équipes (comme scrum de scrum)

Pour la vélocité, on a laissé tomber les points de complexité pour des grandes catégories (s,m,l,xl...) et on cherche à mesurer le lead-time sur ces catégories (on a une distinction également concernant les bugs).

Ca marche plutôt pas mal, car l'équipe est rodée.

mde 5 avril 2011 - 23:36
Oaz

@Antoine,
N'exagérons pas ! Cette fin d'itération mal négociée, c'était quasiment la première en quatre ans et c'était à l'occasion de la première release d'un produit où l'équipe avait absorbé un changement technologique majeur... L'implémentation de Scrum n'est peut être pas parfaite mais elle est loin d'être la cause des évènements.

@Aurélien,
Partir tout de suite sur du flux, c'est surement délicat mais ça me semble presque inutile. Rien de tel qu'une phase exploratoire pour initier un produit.

@Pierre,
Le besoin de cérémonial pour maintenir un cadre à l'équipe, c'est un sujet à lui tout seul.
Je comprends le point de vue mais j'ai une vision assez différente. Le manque de cadre stable, c'est le principe du fonctionnement par "projet" qui en est la cause.
Dans "Software Craftsmanship, the New Imperative", Pete McBreen explique pourquoi "Customers have long time relationships with Software Craftsmen"
Les organisations devraient parfois réfléchir à certains modes de fonctionnement qui paraissent immuables  au lieu de chercher un workaround via les méthodes agiles.
Après tout, "le propos d'XP est le changement social", non ? ;-)

@Ludovic,
100 fois oui pour la boite à outils, le "framework agile". C'était d'ailleurs le propos de mon billet précédent qui a malheureusement eu un peu moins de succès.

@Jonathan,
Le 12ème principe agile dit "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Comme je l'ai expliqué dans un commentaire précédent, l'équipe prend 2 heures chaque semaine pour discuter et s'améliorer. A mon avis, il n'y a pas de raison pour coupler ce perfectionnement au cycle de vie du produit.

@mde,
Je ne me suis jamais penché sur la question du lead-time mais ça me semble effectivement être une évolution naturelle quand on arrive à un écoulement de flux suffisamment fluide.

Oaz 6 avril 2011 - 01:38
Nicolas

@Jonathan

La décision d'arrêter les n'est-elle pas en soi de l'amélioration continue ?
(bien que la décision n'ait pas été prise lors d'une , mais de manière unilatérale...)

Oaz

Plusieurs mots ont mystérieusement disparu dans le commentaire de Nicolas ci-dessus et probablement aussi dans quelques autres.

Après investigation, c'est un effet dû à la présence sur mon blog du souligneur du référentiel agile.

Si certaines phrases apparaissent tronquées, il faut rechercher le concept ou la pratique agile qui a été mystérieusement effacé. On en ferait presque un jeu !

J'ai désactivé le souligneur en attendant de trouver une solution...

Oaz 6 avril 2011 - 21:38
Nicolas

Je la refais alors :)

@Jonathan

La décision d'arrêter les itérations n'est-elle pas en soi de l'amélioration continue ?
(bien que la décision n'ait pas été prise lors d'une rétrospective, mais de manière unilatérale...)

Ludovic

Bonjour,

Je suis assez d'accord avec ton analyse concernant les problème lié à SCRUM (effet Sprint) par contre je rejoint Claude Aubry sur la question qui me turlupine : l'équipe est-elle réellement engagée dans ce sens ?

En effet, tu utilises l'argument "je suis ScrumMaster, j'envoie les invit's donc je peux arrêter de le faire et si personne ne me relance c'est qu'elles ne servent à rien (les invit's, voire les réunion de Sprint)

Je suis tout à fait opposé à ce genre d'analyse car en tant que développeur nous sommes soumis aux mêmes engagements de qualité dans la programmation (qualité des tests, intégration continue) que le ScrumMaster dans l'application de la méthodologie.

Je m'explique : tu écris avoir les cartes en main pour décider de ne pas envoyer les invitations pour les rites de SCRUM, cependant quelle serait ta réaction si les développeurs décidaient de manière unilatérale - mais silencieuse - d'arrêter de suivre les "best practices" de développement car ils pensent qu'elles ne servent qu'à alourdir leur quotidien et attendent de voir si quelqu'un verra une différence à court-terme ?

Penses-tu vraiment pouvoir dire que SCRUM n'est plus utile à ton équipe car personne n'a d'objection lorsque vous n'appliquez plus la méthode ?

Oaz

Bonjour Ludovic,

L'analogie avec les "best practices" de développement n'est qu'à moitié pertinente.

Il faut distinguer 2 choses :

  • ce que les gens font pour les autres
  • ce que les gens font pour eux-mêmes

L'intendance d'organisation des sprints (organiser les réunions, etc.) le scrummaster ne le fait que pour les autres. Il ne le fait pas pour lui-même. Il n'y a pas de raison pour être plus royaliste que le roi. Si le service fourni ne convient pas au reste de l'équipe, c'est à elle de se manifester !

Pour les "best practices" de dev, il faut distinguer ce que les développeurs font pour eux-mêmes, de ce qu'ils font pour les autres. S'ils veulent arrêter le pair programming, par exemple, c'est leur problème. S'ils veulent arrêter le développement incrémental, je suis prêt à parier qu'il ne faudra pas un mois pour que quelqu'un vienne demander pourquoi les fonctionnalités ne viennent sortent plus de manière régulière comme par le passé.

Penses-tu vraiment pouvoir dire que SCRUM n'est plus utile à ton équipe car personne n'a d'objection lorsque vous n'appliquez plus la méthode ?

OUI. Cent fois OUI. Définititvement OUI. C'est d'ailleurs ce que dit le 5ème prinicpe du manifeste agile :

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Cette possibilité de choix est essentielle. Scrum n'est utile que parce que les membres de l'équipe voient son utilité et ont la possibilité de l'exprimer.

Oaz 11 avril 2011 - 13:42
Ludovic

L'analogie avec les "best practices" de dev n'est certainement pas la meilleure possible pour expliquer ce que je voulais dire.
Ce que je voulais exprimer c'est plutôt la mauvaise image que le fait de taire une décision aussi (dé)structurante peut véhiculer auprès de tes co-équipiers (syndrome tour d'ivoire) mais je conçois évidemment que conserver SCRUM coûte-que-coûte peut aussi aboutir aux mêmes conséquences.

Imagines que l'un de tes collègue ne soit pas en mesure d'exprimer que SCRUM lui manque (pas de rétros, le mec est présta chez le client et n'ose pas,...), dans ce cas, tu lui auras retiré l'un des seuls moyen qu'il a de remonter les problèmes sans même l'avoir consulté.
Je pense bien que dans ton cas, l'expérience peut s'être passée sans aucun accroc et SCRUM n'être qu'un framework méthodologique complexifiant le boulot mais j'ai l'impression que ce cas de figure n'est pas généralisable à la majorité des SCRUMistes d'aujourd'hui.

#mode troll : on

Se référer au manifeste agile dans une discussion sur l'agilité, c'est pas un peu comme atteindre une sorte de Point Godwin agile (http://fr.wikipedia.org/wiki/Loi_de...). ?

#mode troll : off

Oaz

Ludovic,

Tu écris : "Imagines que l'un de tes collègue ne soit pas en mesure d'exprimer que SCRUM lui manque"
Alors que dans juste au dessus, j'ai écrit "Scrum n'est utile que parce que les membres de l'équipe voient son utilité et ont la possibilité de l'exprimer."

On est bien d'accord qu'il faut un minimum de liberté d'expression pour que les choses fonctionnent. Moi je dis juste que cela est non seulement nécessaire mais que c'est aussi suffisant.

Cette discussion ne fait que me conforter dans l'idée que le cérémonial de Scrum n'est trop souvent qu'un cache misère dans un contexte non agile.
L'idée du "le mec est présta chez le client et n'ose pas" est symptomatique. S'il n'ose pas c'est qu'il n'y a JAMAIS eu de Scrum dans son environnement. Il n'y a eu un simulacre de méthode agile avec quelques rôles et quelques pratiques. Personne n'a jamais donné les moyens à ce mec là de s'exprimer. Qu'on ne vienne pas alors me raconter que retirer le cérémonial Scrum serait alors dangereux. Ce qui est dangereux, c'est de faire croire que Scrum a existé dans cet environnement là.

Quant à l'invocation du manifeste agile dans la discussion, elle est au contraire, me semble-t-il, la bienvenue : entre le respect du cérémonial Scrum et le respect 5ème principe, j'ai choisi mon camp.

Oaz 11 avril 2011 - 15:01
goupils

Bonjour,

Je viens de décrouvrir ce blog à l'instant et je voulais juste profiter de ce billet pour faire part de mon experience personnale.

Je travaille sur des projets multimedia assez volumineux et comme beaucoup nous avons succombé à la méthodologie SCRUMM / AGILE.
Et je dis: Attention car un effet de mode s'est emparé de notre industrie en vendant les bienfaits d'une méthodologie dont
le nom semblait séduisant mais le retour d'expérience a été un peu cuisant pour plusieurs prestataires


- Dans le cadre d'un projet au forfait avec des paiements liés aux livrables mensuels, continuer d'imposer une phase de spécification
du projet (80%) pour garantir vos rentrées d'argent. En vendant le principe que client peut redéfinir ses besoins et les affiner à
chaque itération, il trouve cela très plaisant et c'est très constructif pour l'équipe, mais il ne le fait pas poour
les paiements en se défaussant sur le service juridique et comptable qui vous annonce que le paiement du mois ne peut pas être
fait car le contrat n'est pas respecté à la lettre. Le Procduct Owner (client) que vous impliquez dans votre méthodologie n'est pas
nécessairement le décisionnaire et cette méthodolgie peut rapidement vous étouffer financièrement

- Conservez la notion de Chef de Projet au SCRUMMMASTER pour gérer les conflits humains, éviter que chacun partent dans des délires techno
et confondent décision de R&D et développement. Dans les grosse équipes comme nous (60 personnes) il faut conserver une strucutre de
lead technique, lead artiste, lead ergonome ... avec des strates (de senior à junior). Un jour la problématique des
responsabilité individuelle viendra sur la table et la notion d'équipe unifiée explose à ce moment.
Le lead technique prend des choit techniques pour les juniors et est en responsable. Cette pyramide permet également de conserver
un système d'évaluation des individus sur le long terme. Ce n'est pas le chef de projet, mais bien les leads qui
vont évaluer les juniors ( en cas de primes ou de promotion)

- ne communiquer pas les builds intermédiaires au client mais uniquement les livrables qui sont liés à un paiement cart
le client va créer un décalage entre le temps pour lui de faire une évaluation (1 semaine pour les grosse applications comme
les notre, de formaliser un feedback et nous le communiquer) Entre temps l'équipe à avancer dans la mauvaise direction et
c'est du temps perdue. Imposer un délai contractuelles (15 jours max) pour le client formalise son feedback et
toujours le faire faire par écrit


- Ne nétgliger pas la documentation, les réunions stand-up meeting ont la facheuse tendance de ne laisser aucune
traces. Réduisez les à l'essentielle et laisser les leads origaniser des réunions métier avec un COMPTE RENDU à la
clef ... ce qui permet aux gens de s'y réferer si un problème resurgit et une décision déjà prise

goupils 26 mai 2011 - 18:27
xavier

Tout à fait d'accord avec Goupils...
Pour embrayer, je dirais qu'il ne faut jamais être un extrémiste d'une méthode. Chaque projet, chaque société a son contexte auquel il faut s'adapter...en permanence.
L'important est de formaliser à un instant t la démarche que l'on va suivre, formalisation qui peut évoluer dans le temps. Il ne faut pas laisser place à l'implicite.
Cette formalisation doit s'appuyer sur une boite à outils méthodologiques bien compris et assimilés, combinée à l'expérience.
Cette boîte à outils comprend des outils de modélisation (UML, MCD, ...) , des outils processus (cycle en V, en Y, HOOD, MERISE, Scrum; OpenUp, XP, Schlaer et Mellor, ...).
Selon les profils au sein de l'équipe, selon l'encadrement du projet, selon le type de client, selon le type de projet orienté data ou contrôles, ..., il faut faire son marché et combiner les outils pour construire une démarche homogène et bien maîtrisée. C'est surtout là la clef du succès. N'essayez pas de calquer des notions extérieures sur vos problématiques si elles ne sont pas assimilées.
Cordialement
Xavier

xavier 17 août 2011 - 15:24

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.