Retour sur la soirée Scrum User Group
03 Apr 2010Mardi soir j’ai participé à la soirée anniversaire du French Scrum User Group.
Direction Microsoft à Issy Les Moulineaux.
A propos si vous recherchez des locaux, il y a de la place ! :)
Accueil
J’entre donc dans l’amphi Grand bleu pour l’ouverture de la soirée. Salle très impressionnante que l’on remplit à moitié au début. On commence par une vidéo de Ken Schwaber en personne buvant une flûte de champagne pour fêter cet anniversaire, clin d’oeil plutôt sympa :)
Ensuite Luc Legardeur, président du Scrum User Group et de Xebia, fait le bilan de la première année. Il remarque que le public se diversifie et qu’il n’y a pas que des SSII dans la salle. Quelques chiffres, le SUG en France c’est 400 membres et 11 rencontres sur l’année pour un budget autour de 13 000 Euros. Un petit scoop pour la fin, le Scrum Gathering d’automne pourrait être organisé en France.
Roman Pichler
On enchaîne par une excellente présentation de Roman Pichler à propos du rôle de Product Owner. Il nous présente plusieurs types de Product Owner à éviter.
Le proxy Product Owner
C’est le cas typique que je retrouve dans ma société. Avec Scrum nos chefs de projet ont un peu de mal à trouver leur place. Comme nos MOE n’ont jamais le temps de jouer le rôle de Product Owner, c’est le chef de projet qui s’y colle. Il gère très bien “l’administratif” mais ce n’est pas lui qui est maître de la “vision produit” c’est la MOE ! Dans ce cas on parle de proxy product Owner. Ca ne fait donc que ralentir les décisions. Roman parle même d’anti Pattern.
Le Product Owner faible
Si le Product Owner doit faire valider toutes ses décisions par son responsable, c’est dur d’avancer sereinement. Le Product Owner doit avoir le pouvoir de réaliser sa vision du produit.
Le Product Owner surchargé
Un Product Owner peut gérer au maximum trois projets en même temps (en fonction de leur importance). Il ne doit pas non plus tout gérer seul, il a surtout un rôle de leader.
Le Product Owner passif
Roman dit qu’il rencontre ce type de Product Owner avec des personnes habituées aux livraisons “Big ban” (j’écris 3 lignes de spec et je reviens 3 mois plus tard pour constater que je n’ai pas ce que je voulais). En Scrum le Product Owner doit s’investir tout au long du projet.
Le Product Owner Distant
Là aussi on rencontre souvent ce cas pendant une prestation où le client n’est pas dans les bureaux de la SSII. Ca ralentit clairement la productivité de l’équipe. Roman préconise que le Product Owner soit au minimum présent avec l’équipe les deux premiers et les deux derniers jours du sprint.
Le Product Owner sans vision
Le Product Owner doit présenter et partager la vision du produit à l’équipe. Il doit savoir ce que la prochaine release va contenir.
Roman est un très bon orateur et ses différentes expériences enrichissent son discours.
Les Ateliers
Après cette présentation très dynamique, plusieurs ateliers dans 4 salles différentes sont organisés. J’en ai suivi trois.
Collaborer avec Scrum grâce à Visual Studio
Xavier Warzee de Microsoft nous présente la nouvelle version de Visual Studio qui intègre la gestion d’un product Backlog. Ca ressemble quand même beaucoup à un MS Project “Scrumisé”. Alors oui ça va plaire à nos managers grâce à tous les chiffres et les graphs que ça génère, mais j’ai quand même la désagréable impression qu’on essaie de nous revendre un Excel en plus cher.
Julien Corioland d’Access it présente son application de gestion d’affectation de tâche sur la table surface. C’est bien-sûr relié à une base Visual Studio. Alors oui c’est beau, amusant mais est-ce que c’est exploitable ? J’en suis moins sûr. Sans oublier qu’une table surface c’est 12 000 $, soit à peu près 1 million de post-it.
Pour finir c’est Mathieu Szablowski de Pyxis qui nous montre une extension qu’il a réalisée pour Visual Studio. Déjà ce qui me choque c’est qu’il fait une démo de Visual Studio depuis son Mac Book Pro. C’est quand même un peu tordu d’utiliser un Mac pour utiliser Visual Studio 😉 Sinon pour le fond j’ai toujours du mal à comprendre l’intérêt de ces extensions par rapport à une bonne vieille feuille Excel. Bon si, j’avoue, le seul intérêt que j’y vois c’est le travail collaboratif.
Bref une première session assez décevante. On a beaucoup parlé de Microsoft et très peu de Scrum au final. L’agilité en ce moment c’est à la mode et on a vraiment l’impression que les éditeurs ajoutent le mot Scrum un peu partout pour vendre leur produit. La session d’après n’a fait que confirmer cela.
Modélisation pour SCRUM avec RSA
C’est le titre qui m’a attiré. J’étais curieux de voir comment IBM (les rois du RUP) allait nous parler de Scrum. Et bien j’ai pas été déçu. Dès le premier slide j’ai failli m’étouffer. Regardez sur l’image la phrase “Adoption de Scrum avec un phasage RUP”. En fait ce n’est pas Adoption qu’il fallait noter mais plutôt Adaptation à mon avis. Alors oui RUP intègre la notion d’itération, mais c’est bien le seul point commun avec Scrum.
Par contre je suis toujours fan de modélisation et reste convaincu que cela peut tout à fait s’intégrer dans une démarche agile. On peut même faire du MDA ! :)Sur ces points j’étais en phase avec IBM. Mais si on regarde de plus près RUP, comment gérer la douzaine de rôles différents définis par RUP en Scrum ? C’est juste impossible. Et quand IBM nous a dit que l’architecture de l’application présentée était gérée par des personnes ne faisant pas partie de l’équipe de dev, on sent bien que la notion de Team est encore loin.
Avec tout ça je ne vous ai même pas parlé de Team Concert et de RSA, mais franchement là encore c’est vraiment intégrer Scrum dans un outil pour des raisons marketing. Comme si RSA n’était pas déjà assez lourd et lent, ils ont ajouté un mini Excel. Ca m’a un peu énervé, je n’insiste pas.
IceScrum
La dernière présentation va-t-elle sauver ma soirée ? Et bien oui ! Vincent Barrier va enfin faire une présentation “Scrum centrique”. La grosse différence c’est que Ice Scrum a été créé pour faire du Scrum contrairement aux deux autres ou Scrum a été intégré au chausse pied.
Donc IceScrum permet de faire du suivi de projet Agile en respectant toutes les phases et tous les rôles définis par Scrum. C’est un outil Open Source (GPL) disponible sous la forme d’un WAR. Je compte bien l’essayer rapidement pour l’utiliser sur nos projets.
Avant IceScrum était géré par des étudiants encadrés par Claude Aubry, mais maintenant une société a été montée pour prendre en charge le développement. IceScrum Technologies va donc vendre support et évolutions spécifiques. Claude Aubry reste sur le projet en assurant le rôle de Product Owner du produit.
Bilan
Ouf enfin à manger et à boire ! 😉
Comme vous l’avez compris je n’ai pas été emballé par toutes les présentations. Il ne faut pas oublier que ce n’est pas grâce aux outils qu’un projet agile va réussir ou non. Vous pouvez avoir la plus belle table interactive connectée à un serveur qui génère des rapports dans tous les sens, ça vous fait une belle jambe si votre Product Owner n’est pas sérieux, que votre Scrum Master est un charlot ou que les membres de votre équipe n’arrivent pas à communiquer entre eux. Car c’est bien l’humain la clé de la réussite d’un projet agile.
C’est moi ou tout le monde a oublié le manifeste agile ?
- Personnes et interaction plutôt que processus et outils
- Logiciel fonctionnel plutôt que documentation complète
- Collaboration avec le client plutôt que négociation de contrat
- Réagir au changement plutôt que suivre un plan
Je répète : Personnes et interaction plutôt que processus et outils. Alors oui c’est dur à entendre pour des éditeurs mais il va falloir s’y faire. Donc essayons déjà de construire des équipes agiles, de former nos Product Owner et nos Scrum Master et seulement après cela on pourra se poser la question des outils à utiliser.
Après j’ai peut être simplement fait une erreur dans mes choix d’atelier. Sur les 12 disponibles j’ai participé aux trois qui parlaient d’outillage, ce n’était pas forcément très malin de ma part :)
Liens :