Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Démystifier les rôles Scrum

Publié par David Beaumier le lundi 7 septembre 2015 à 15:48

L’équipe de l’Alliance Scrum a publié au début de l’été un article de référence intitulé Scrum Roles Demystified. J’ai trouvé que cet article présentait fort bien l’essence des trois principaux rôles que l’on retrouve dans le cadre de travail Scrum. Avec l’accord de l’Alliance, je vous propose un résumé de cet article afin d'en faire profiter l’ensemble de la communauté Agile francophone.

Pour les organisations et les équipes qui sont peu familières avec Scrum il est parfois difficile de bien saisir les responsabilités associées aux rôles Scrum. Les trois rôles n’ont pas nécessairement d’équivalents directs dans les approches traditionnelles. Il peut aussi arriver que l’on associe, à tort, certains des rôles avec ceux que l’on retrouve habituellement dans les projets. L'article de Scrum Alliance, et le présent résumé, se veulent donc une façon de clarifier l’essence de chacun de ces rôles.

Scrumroles Infographic FR

Le Product Owner

Le Product Owner (nommé tel quel dans la version française du guide Scrum) est la pierre angulaire du succès d’un projet ou d’un produit. Non seulement est-il responsable de déterminer ce qui doit être fait, mais il se doit de pouvoir démontrer pourquoi ces éléments sont importants et prioritaires. Sa responsabilité va donc bien au-delà d’une simple gestion du carnet de produit.

Dans le cadre Scrum le Product Owner demeure activement impliqué pour la durée complète des travaux. Il s’assure de la cohérence du travail réalisé par rapport aux objectifs d’affaires recherchés. Il est à l’écoute des rétroactions provenant du secteur affaires autant que de celles provenant de l’équipe de développement et apporte les ajustements nécessaires au carnet.

Notez que j'ai choisi le terme fiduciaire car souvent le Product Owner n'est pas réellement le propriétaire du produit à proprement parler. Les parties prenantes (ou fiduciants) lui délègue l'autorité requise pour bâtir le produit, mais ceux-ci demeurent les propriétaires et peuvent prendre action en conséquence.

L’équipe de développement

Une équipe de développement Scrum est habituellement composée de 5 à 9 personnes. Ce groupe possède collectivement les compétences requises pour mener à bien les travaux, avec le soutien du ScrumMaster. Comme Scrum permet le développement de produits de nature très variée, l’expertise de chacun des équipiers peut varier grandement d’une équipe à l’autre.

L’équipe de développement possède un haut degré d’autonomie afin de déterminer comment doivent être réalisés les travaux priorisés par le Product Owner. Cette autonomie vise à créer un solide esprit d’équipe, à développer le travail collaboratif et l’atteinte d’objectifs communs.

Le ScrumMaster

Le ScrumMaster agit sur deux axes principaux. Premièrement, il veille à ce que tous les membres de l’équipe, spécialement ceux de l’équipe de développement, puissent se concentrer sur les travaux. Il aide l’équipe à résoudre les éléments bloquants qu’elle rencontre et la protège des distractions qui pourraient surgir en cours de route.

De par sa connaissance approfondie de Scrum il veille également à l’application du cadre de travail dans l’équipe. Il guide l’équipe à travers les défis associés à l’application de Scrum. Il appui la personne exerçant le rôle de Product Owner afin de l’aider à tirer le maximum de Scrum.

La synergie

C’est la complémentarité qui existe entre les rôles du Product Owner, de l’équipe de développement et du Scrum Master qui permet d’atteindre les résultats exceptionnels que produisent les équipes Scrum. Il est essentiel de soutenir chacun de ces rôles lorsqu’une organisation met en oeuvre Scrum.

Conclusion

Je vous invite à lire l'article orginalement publié en anglais car il contient plusieurs précisions additionnelles qui, je crois, pourront vous aider à bien cerner les subtilités de chacun des rôles.

Aussi, il n’est pas toujours facile d’adapter du contenu anglophone vers une autre langue tout en en préservant le sens original. Surtout lorsqu’on souhaite que les termes utilisés soient appropriés pour les lecteurs des deux côtés de l’Atlantique (et ailleurs aussi). N’hésitez-pas à laisser un commentaire ci-dessous si vous avez des suggestions linguistiques à faire.

* Le matériel original est une propriété de Scrum Alliance et adapté avec permission.

Lecture estivale pour Scrum Masters

Publié par Jean-Francois Gilbert le lundi 1 juin 2015 à 00:00

On dit souvent que les développeurs devraient s'évertuer à améliorer leurs techniques et approfondir leurs connaissances. C'est vrai, mais  ça l'est tout autant pour les Scrum Masters. Lire le guide Scrum ou recevoir une formation est un excellent point de départ, mais il faut comprendre que ce n'est qu'une base et qu'il reste beaucoup à apprendre. L'expérience sur le terrain comme Scrum Master vaut de l'or. Par contre, si elle n'est pas appuyée sur une solide fondation, le Scrum Master risque de ne pas exploiter au maximum les avantages que la méthode Scrum peut apporter à son équipe de développement.

Scrum, en tant que cadre de travail est relativement simple. L'agilité à l'origine de Scrum, mais qui également en découle, est un état d'esprit que les équipes ou même les Scrum Masters ne possèdent pas toujours. La méthode Scrum appliquée machinalement sans en comprendre le sens n'a que peu de chance de donner de véritables résultats.

Il existe heureusement une panoplie de ressources disponibles pour quiconque veut approfondir sa maîtrise de Scrum. L'été s'en vient et bien qu'il soit important de décrocher du boulot et de se changer les idées, c'est aussi un temps propice à l'apprentissage. Pourquoi ne pas profiter de la période estivale pour faire un peu de lecture et vous améliorer dans votre rôle de Scrum Master ?

Je me lance à moi-même ce petit défi. Pour ma part, j'ai décidé de relire un excellent bouquin paru en 2013 : Exploring Scrum : the Fundamentals. Bien qu'on retrouve le mot « fundamentals » dans le titre, les auteurs vont en profondeur et se basent sur des expériences concrètes. Le livre explore trois éléments fondamentaux du développement agile : les gens, le produit et les pratiques.

Si vous voulez des suggestions de livres sur le rôle de Scrum Master, sur Scrum ou l'agilité en générale, voici des listes qui vous inspireront peut-être :

Références agiles pour les coachs et Scrum Masters

5 books every Scrum Master should read

Top 100 agile books de Jurgen Appelo 

 

The Professional ScrumMaster's Handbook

Publié par Jean-Francois Gilbert le lundi 6 janvier 2014 à 00:00

Tout d'abord bonne année 2014! Je vous souhaite à tous et à toutes de beaux projets personnels et professionnels.

Livre Pro Scrum Master HandbookMon collègue Philippe proposait récemment une liste de références pour les coachs et Scrum Masters. J'ajouterais à cette belle liste le livre suivant : The Professional ScrumMaster's Handbook. Je crois que ce livre devrait être mis entre les mains de tout nouveau Scrum Master. L'ouvrage couvre un vaste éventail de sujets, mais les traite tout de même avec un niveau de détail étonnant. Je reproche souvent aux publications sur Scrum de rester à un niveau abstrait et quelque peu académique. Ce livre apporte de nombreux exemples concrets et utilisables au quotidien et le style d'écriture est assez détendu.

En plus de traiter de Scrum au niveau du produit, il aborde également l'aspect programme et porte-folio d'une équipe de développement, le changement organisationnel, les défis qui attendent les Scrum Masters (PO absent, équipe distribuée etc) et de bonnes pistes de solutions pour relever ces défis.

Bref, c'est à lire !

Références Agile pour les coachs et Scrum Masters

Publié par Philippe Tremblay le mardi 3 décembre 2013 à 12:15

La présence d’un coach ou d’un Scrum Master peut accélérer grandement l’obtention des bénéfices agiles dans une organisation et ses équipes.  Cependant, comme c’est le cas pour tous les rôles, un « titre » (ou un diplôme) n’est pas une formule magique donnant instantanément les connaissances, les habiletés et l’attitude requises pour accomplir de façon performante ce rôle.  Pour pouvoir aider efficacement les organisations et leurs équipes un coach / Scrum Master doit détenir un bagage allant bien au-delà de la connaissance du Guide Scrum et du manifeste agile (qui restent tout de même incontournables).

Nous vous proposons donc une série de références qui permettront de bonifier vos diverses expériences d’accompagnement.  Également, la plupart des références suggérées pour les leaders le sont également pour les coachs.  Surtout lorsque vous agissez à titre de coach organisationnel pour une transition.  Cet article sera mis à jour afin de refléter l’évolution de nos suggestions.

Articles

Livres

Une anomalie devrait-elle donner des points à l'équipe?

Publié par David Beaumier le mercredi 27 novembre 2013 à 21:07

Dernièrement, on me posait la question suivante : « J’aimerais une confirmation sur le fait que les bogues ne devraient pas être pointés et comptabilisés dans le calcul de la vélocité de l’équipe ». C’est une excellente question et une qui revient assez souvent, particulièrement lorsqu’une équipe débute avec Scrum.

La réponse que je donne généralement est assez simple : non, on n’attribue pas de points aux anomalies. La raison principale est que Scrum se veut un cadre de travail qui valorise la livraison de valeur ajoutée (appelée value-driven en anglais). Lorsqu’on ajoute un élément au carnet d’un sprint c’est dans l’objectif de livrer une fonctionnalité qui a de la valeur pour le client. À l’opposé, un bogue représente une somme de travail de correction à quelque chose qui a déjà été livré. En corrigeant un bogue, l’équipe n’apporte, malheureusement, pas de valeur au client. En anglais, on parle de failure-driven.

L’objectif d’un cadre de travail empirique comme Scrum c’est d’amener l’équipe à réfléchir sur sa façon de travailler et d’en venir à identifier des façons de livrer plus de valeur au client durant un Sprint. Si l’équipe reçoit des points pour corriger des bogues elle n’aura alors aucun incitatif à être créative et à trouver des façons d’éviter ces bogues à la source. À mon avis, ça reviendrait en quelque sorte à offrir un biscuit à un chien alors qu’il vient de désobéir. En fait, en éducation on suggère d’encourager les bons comportements et d’ignorer les mauvais. C’est exactement l’approche préconisée par Scrum puisque l’équipe n’est pas pénalisée. Elle ne perd pas de points, mais elle n’en gagne pas non plus et sa vélocité n’augmentera pas.

Une équipe qui doit corriger un nombre significatif de bogues au cours d’un sprint va probablement en souffrir puisque sa vélocité risque de « prendre une débarque ». C’est un peu le but en fait... Si l’équipe est sérieuse, on devrait voir émerger des suggestions pour corriger la situation et éviter que la situation se répète. Cela peut parfois prendre plus d’un sprint pour que l’équipe réalise qu’elle est sur une mauvaise pente. Scrum Master, soyez vigilants!

Toutefois il est important pour les équipes de distinguer un bogue (un vrai) d’un changement au comportement d’une application. Je prends un exemple qui m’a été présenté récemment : lorsqu’un utilisateur imprime un rapport en sélectionnant un client qui n’a pas de facture impayée, le rapport "plante" car ce cas n’avait pas été prévu par le PO, ni testé dans ces conditions  (le rapport sert en principe pour les clients qui ont des comptes en souffrance). J’ai alors suggéré à l’équipe de créer un élément dans son carnet de produit afin d’ajouter le support pour ce besoin qui venait d’émerger. Par contre, si le rapport avait affiché la liste des factures dans le mauvais ordre, là j'aurais plutôt penché pour le bogue.

Qu’en pensez-vous? Est-ce que vous suivez cette règle dans votre équipe?

Archive