Blog

Série : Comment bien démarrer Scrum

Playlist bien démarrer Scrum
Complément aux vidéos

Série : Comment bien démarrer Scrum

Une série de 10 vidéos

Scrum Life propose une série de 10 vidéos incontournables sur Scrum : « Comment bien démarrer Scrum ? » Retrouvez de manière détaillée, des éléments clés et plein d’astuces pratiques : quel jour commencer ses sprints ? À quoi sert une charte d’équipe ? Comment décider de la durée du sprint ?… Constantin et Jean-Pierre vous éclairent comme d’habitude sans tabou et avec humour.

Les vidéos de la série

Des sprints plus performants en commençant le bon jour

Photo Constantin Guay

Je vois beaucoup d'équipes qui commencent le lundi. Pourquoi lundi ? En vrai, souvent, on ne s'est juste pas posé la question, tout simplement. Posez-vous la question du jour de démarrage dès le commencement du projet. Et s’il est déjà commencé, faites-le maintenant. C'est toujours utile de se demander pourquoi nous faisons quelque chose et de changer si nécessaire. Peut-être que vous vous rendrez compte que vous n'avez pas choisi le bon jour. Est-ce grave ? Non bien sûr, l'important, c'est de s'en rendre compte grâce à l'impact que ce choix a sur l'équipe et sa capacité à livrer un bon produit de façon durable.

Charte d'équipe : poser le cadre d'équipe Scrum, propice à la performance via l'auto-organisation

Photo Jean-Pierre Lambert

L’auto-organisation ne se décrète pas ! Je vous propose de regarder ce qu’on appelle une charte d’équipe. Il s’agit de poser clairement les attentes vis-à-vis de l’équipe et vis-à-vis du reste de l’environnement. Une charte d’équipe (working agreements) c’est se mettre d’accord : « Comment on travaille entre nous. » La charte peut porter sur des choses très concrètes comme le Definition Of Done et le Definition Of Ready ; ou sur des choses plus comportementales : sur l’attitude et sur les aspects humains. La force de cette approche c’est d’une part de bien signifier les attentes auprès de l’équipe et d’autre part d’attirer son attention sur les moyens à mettre en œuvre pour que cela fonctionne. Quand et avec qui réaliser cette charte d’équipe ? La création d’une nouvelle équipe est vraiment le moment idéal pour sa mise en place afin éviter le phénomène de résistance au changement. Et ce qui serait encore mieux c’est que cette charte soit rédigée de manière participative par l’équipe elle-même. N’oubliez pas qu’il est fondamental de faire signer toutes les parties prenantes : l’équipe, le manager, le directeur…

3 choses à savoir pour choisir la durée du sprint

Photo Constantin Guay

Comment bien choisir la durée de vos sprints ? Beaucoup vont faire par défaut des sprints de 2 semaines. Pourtant la durée ne doit pas se choisir au hasard. La durée doit dépendre de plusieurs éléments : elle doit réduire la boucle de feedback afin de réagir au changement du contexte et prendre en compte les contraintes techniques. Ceci implique de se poser les questions suivantes : techniquement à quelle fréquence l’équipe peut-elle livrer quelque chose aux utilisateurs ? A quel rythme l’utilisateur et les autres parties prenantes peuvent-ils être disponibles pour donner ce feedback. La bonne durée d’itération est finalement un équilibre entre votre capacité à livrer et la capacité des parties prenantes à vous fournir des feedbacks vous permettant d’adapter le plan. Ne négligez surtout pas la durée de vos itérations et si nécessaire ajustez-la !

Qui fait quoi ? ATELIER Rôles & Responsabilités pour BIEN DEMARRER SCRUM

Photo Jean-Pierre Lambert

Lorsque vous travaillez en équipe, quel est le rôle de chacun ? Et est-ce que chacun est au clair sur le rôle des autres ? Je vous présente un outil qui promet de remettre à plat les dynamiques d’équipes en expliquant les rôles et responsabilités de chacun. Les premières phases de l’atelier consistent à : lister les responsabilités que l’on pense avoir, lister celles que l’on attribue aux autres et isoler celles sur lesquelles l’équipe ne s’est pas mis d’accord. À l’issu de ces phases, nous arrivons enfin au moment vraiment intéressant : l’échange et les négociations sur les points de désaccord. En principe à la fin des discussions il ne vous reste plus qu’à faire une mise au net des rôles et responsabilités.Pourquoi ça marche ? Quand est-ce utile ? La création d’une nouvelle équipe est le moment le plus propice à initier un déclic collectif à clarifier le rôle de chacun. Lorsque qu’une équipe est déjà en place c’est rarement utile, en revanche l’atelier peut être extrêmement puissant pour faire ressortir les non-dits. L’atelier pose un cadre permettant d’aborder les vrais sujets de tension, de verbaliser les choses qui ne vont pas dans l’équipe.

Product Backlog : les OUTILS que VOUS DEVEZ CONNAÎTRE pour faire un BON PRODUIT

Photo Constantin Guay

Vous êtes habitué à préparer le backlog du projet en amont, parfois pendant 2 ou 3 mois afin de recueillir toutes les informations ? Mais vous attendez aussi d'une équipe agile qu’elle planifie "juste à temps" et prône l'empirisme… Le backlog n’a pas besoin d’un grand niveau de détail ni d’être parfait. Des itérations courtes permettront de préciser ce qu’il manque sans pénaliser l’équipe trop longtemps. L’idéal est de monter l’équipe et de la faire participer à la création du backlog. Vous êtes sceptique ? Pourtant cela coûte souvent bien moins cher que de faire quelque chose d’inutile ou d’inadapté.

Gestion des PARTIES PRENANTES : solution À LA DEMANDE ou véritable APPROCHE PRODUIT ?

Photo Jean-Pierre Lambert

Dans votre équipe, qui décide de la prochaine fonctionnalité à implanter ? Est-ce l’équipe ou les autres parties prenantes ? Si la réponse à cette question n’est pas claire vous risquez la catastrophe… Pour y répondre il suffit de savoir si vous êtes en train de construire un logiciel à la demande ou si vous suivez une approche produit. Dans le premier cas c’est le client qui décide de la voie à donner au produit. L’équipe n’a que très peu d’autonomie et exécute les décisions du client qui se place souvent en porte-parole des utilisateurs. Scrum n’est que partiellement adapté à cet environnement. Dans le second cas l’entreprise ou l’organisation, souvent par l’intermédiaire du Product Owner, définit la vision du produit et laisse l’équipe décider des fonctionnalités à implanter pour y répondre. L’équipe à donc une grande autonomie et Scrum pourra alors donner tout son potentiel !

Approche empirique dès le sprint 1 : on commence l'agile !

Photo Constantin Guay

Et si je vous disais que votre sprint 1 risque de façonner l'échec ou la réussite de votre produit ? Scrum ne parle pas du sprint 1 il n’est donc pas différent des autres. Il n'y a pas de prérequis. Vous pouvez arriver en sprint planning avec l'équipe, définir ensemble un objectif de sprint, en déduire des options, estimer si les fonctionnalités sont faisables dans le sprint, puis faire le découpage technique pour les premiers jours du sprint. Et c’est parti !Bien se préparer c’est quoi ? Souvent, j'entends qu’être agile c'est pouvoir pivoter. Mais c'est aussi le faire en réduisant le gâchis. Par exemple, toutes les maquettes que vous avez fait avant le sprint 1 seront perdues si vous devez pivoter immédiatement. Bref... le sprint 1 est finalement vraiment comme tous les autres sprints : soutenable, apportant de la valeur et empirique.

Team Building UTILE et EFFICACE : faites plutôt le SPRINT D'UN JOUR ! - Cohésion d'équipe accélérée

Photo Jean-Pierre Lambert

Comment définir les process de l’équipe ? Créer une dynamique d’équipe ? Souder ses membres en leur faisant rapidement partager des "faits d'armes" ?Soyons clair, le Team Building a ses limites : il est par définition artificiel, et l’activité choisie peut dans certains cas virer au règlement de comptes entre collègues. Il n’est pas nécessaire de forcer les choses. Nous pouvons être très productifs avec des personnes avec qui nous ne sommes pas amis et à l’inverse, il y a plein d’amis avec lesquels nous ne serons pas à l’aise pour travailler.Je préfère de loin accélérer la cohésion de l’équipe avec le sprint d’un jour. Il apporte une collaboration immédiate autour de l’élément choisi pour ce sprint, une appropriation des process grâce à un feedback immédiat, et des faits d’armes communs au terme de la journée. La contrainte forte du sujet unique à terminer le jour même pose un cadre qui amène l’équipe à naturellement collaborer.

Scrum bidon : apprenez à FORMER votre équipe pour connaître le VRAI SCRUM

Photo Constantin Guay

Comment vous assurer que l'équipe soit bien alignée et garde le cap de Scrum et de l'agilité ? Voilà un outil pour arriver à vos fins : la lecture du Scrum Guide en équipe. Avoir cette base de connaissances communes est un très bon point de départ. Vous ne perdrez pas votre temps bien au contraire, vous en gagnerez beaucoup. Au cours de la lecture, questionnez l’équipe pour la confronter à la réalité, faire apparaitre les différences entre le Scrum Guide et la vraie vie. N’hésitez pas non plus à faire remarquer, dans le feu de l’action, ce que Scrum a permis de mettre en lumière. Cela permet de se construire et de construire son équipe de façon empirique. Utiliser Scrum est un voyage vers sa compréhension…

Scrum à l'échelle - Comment bien démarrer Scrum alors qu'on dépend d'autres équipes ?

Photo Jean-Pierre Lambert

Comment intégrer la contrainte liée à la multiplicité d’équipes pour un bon démarrage de votre équipe Scrum ? Si l’on considère la vision canonique de Scrum : cela fonctionne à condition que le backlog soit commun à toutes les équipes travaillant sur le même produit et que ses éléments soient indépendants. La bonne pratique consiste, entre autres, à créer des User Stories indépendantes. Ainsi, les équipes peuvent rester indépendantes ou du moins limiter leurs dépendances.Pourtant on voit souvent autre chose : des équipes qui dépendent les unes des autres. Comment faire dans ce cas ? La bonne organisation vise à réduire les dépendances et non pas à les gérer même s’il en reste toujours. Leur gestion passera souvent par un framwork de passage à l’echelle comme SAFe, LeSS, Nexus... Fondamentalement dans ces frameworks il est toujours question de gestion des dépendances.Dans tous les cas elles sont traduites par des contrats d’interface qui devront être intégrés dans les Definition Of Done et Definition Of Ready. Attention néanmoins à ne pas glisser vers le Water-Scrum-Fall ! Prenez du recul sur les dépendances et posez vous la question de comment vous pourriez les faire disparaitre.

Vous avez aimé cette série ?

Alors vous allez adorer

Le guide du Scrum Master compétent

Entrez votre adresse mail pour rejoindre la liste d'attente :