background preloader

Scrum

Facebook Twitter

Scrum pour les nuls. Scrum (méthode) Un article de Wikipédia, l'encyclopédie libre. Pour les articles homonymes, voir Scrum. Cet article ou cette section peut contenir un travail inédit ou des déclarations non vérifiées(indiquez la date de pose grâce au paramètre date). Scrum est un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible »[1]. Scrum est considéré comme une méthode agile. La méthode s'appuie sur le découpage d'un projet en boîtes de temps, nommées « sprints ».

La création de méthode de développement logiciel hybride couplant Scrum et d'autres méthodes est commune puisque Scrum ne couvre pas le cycle de développement de produit. En 2001, Ken Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre Agile Software Development With Scrum. Parmi ses attributions : Durant un sprint : Contextualiser Scrum. Pour utiliser le cadre Scrum, il faut d’abord y insérer des pratiques complémentaires, variables selon le domaine, et adapter le tout au contexte.

Contextualiser Scrum est le chapitre 13 dans la 4e édition de mon livre. Voilà ce que j'ai écrit en introduction du chapitre : Ce chapitre n’est pas à cette place par hasard. Il vient après la présentation de ce qui constitue le cadre Scrum. Un cadre, ce n’est pas une méthode, encore moins une méthodologie ou un processus complet qu’on pourrait « instancier » pour l’appliquer directement. Pour les compléments, il est naturel d’aller voir des pratiques issues d’autres disciplines, comme la définition de produit, la gestion de projet et l’ingénierie du domaine concerné. Pratiques agiles La notion de pratique est centrale pour l’adaptation de Scrum : à côté des valeurs et des principes agiles, qui sont universels, les pratiques varient avec chaque situation.

Exemple : la revue de sprint, avec sa démonstration. Pratiques Scrum. Qu'est ce qu'un (bon) ScrumMaster? Vous êtes de plus en plus nombreux à vous intéresser à l’agilité, à travailler dans un cadre de Scrum voire même à endosser le costume de ScrumMaster. Voici donc quelques éléments qui vont permettront d’y voir plus clair sur ce nouveau rôle. ScrumMaster c’est un des 3 rôles proposés dans Scrum (avec l’Equipe et le Product Owner) Animateur d’une équipe qui applique la méthode Agile Scrum, le ScrumMaster aide l’équipe à travailler de manière autonome et à s’améliorer constamment.

Il est le garant de Scrum sur le projet. Dans les grandes lignes, le ScrumMaster va principalement agir en facilitateur, va protéger l’équipe et lever les obstacles empêchant l’équipe d’avancer. Plus précisément… Vous me demandez régulièrement quels sont les qualités d’un bon ScrumMaster.. Voici déjà ce qu’il n’est pas: et pour le reste, voici ce que j’en pense: Le ScrumMaster non plus ! Jean Claude GROSJEAN - COACH d’Organisation. Follow Me: Secrets de ScrumMaster. Si vous êtes ScrumMaster, lisez ceci… nous gagnerons du temps dans nos accompagnements!

Voici le TOP 10 des articles à LIRE pour vous aider à démarrer dans de bonnes conditions. Ils peuvent également permettre à vos interlocuteurs de mieux comprendre les contours de votre rôle, ce qu’ils peuvent attendre de vous et ce que vous pourriez attendre de leur part! Désormais c’est aussi un PREREQUIS côté ScrumMaster pour démarrer un coaching agile avec moi.

Article # 1: LA description du rôle, ce qu’est Un BON ScrumMaster ce qu’il n’est pas.. Article # 2 La différence entre ETRE AGILE et FAIRE de l’agile. Article # 3: DÉMARRER UN PROJET AGILE: les ateliers à mener juste avant de démarrer votre premier sprint. Article # 4: Puisque votre boulot est aussi d’accompagner le travail du Product Owner. Article # 5 L’espace de travail est essentiel…. le MANAGEMENT VISUEL aussi. Article # 6 Réussir l’animation d’un SPRINT PLANNING - 1er RDV de votre Sprint: objectifs, agenda, conseils Follow Me: Secrets de Product Owner. … vous êtes Product Owner, lisez ceci, nous gagnerons du temps dans nos accompagnements. Voici le TOP 10 des articles à LIRE pour vous aider à démarrer dans de bonnes conditions. Ils peuvent également permettre à vos interlocuteurs de mieux comprendre les contours de votre rôle, ce qu’ils peuvent attendre de vous et ce que vous pourriez attendre de leur part!

Article #1: Etre en mesure de partager une description de votre rôle (focus, responsabilités et activités majeures) Article #2: Travailler votre Roadmap de produit dans une dynamique agile Article #3: Mener votre démarrage de projet côté Product Owner autour du Backlog Refinement Initial (avec un travail sur la vision, la raodmap, les Personas, le backlog de produit high level et son estimation…) Article #4 : Initier une Story Map pour faciliter votre travail de priorisation Article #5: Comprendre enfin que ce qui va faire la différence avec vos équipes c’est votre disponibilité, votre présence Je m’appelle Jean Claude GROSJEAN.

Le rôle de partie prenante. Les trois rôles qu'on trouve dans une équipe Scrum sont maintenant bien connus. Par contre, le rôle de partie prenante l'est beaucoup moins, alors que de nombreuses difficultés dans la mise en œuvre de Scrum y sont relatives. Une partie prenante est une personne qui est intéressée par le résultat obtenu par l'équipe. Ce sont des utilisateurs, des clients mais aussi des sponsors, des représentants des utilisateurs, des gens du marketing ou du commerce, des managers, des personnes impliquées dans l’infrastructure, dans la qualité, des membres d'autres équipes, etc. Un chercheur universitaire américain, Ronald K. Le pouvoir, capacité à imposer sa volonté,l'urgence, conviction personnelle que sa demande est pressante,la légitimité reconnue, appréciation, par les autres, des compétences et de l’action.

C'est la grille de Mitchell. Un dessin de Patrice Courtiade pour l'édition 5 de mon livre Scrum Ce sont des idées que je développe dans l'édition 5. Agile à l'Echelle: les 4 éléments du dispositif de base. La présence de plusieurs équipes agiles devant travailler ensemble au sein d’un même programme par exemple induit une complexité qu’il est nécessaire d’appréhender au travers d’un dispositif à la fois adaptatif et rigoureux; juste ce qu’il faut de dispositif pour être et rester agile sur le long terme.

Je me souviens d’un des premiers principes de LeSS (Large Scale Scrum) confié par Craig Larman il y a quelques années lors d’un de ses passages à Paris Large Scale Scrum is Scrum – Craig Larman J’avoue que c’est mon point de départ quand je suis amené à travailler dans un contexte « Agile@Scale »: l’agile à l’échelle c’est avant tout et d’abord de l’Agile! Dés lors, comment procéder dans ce type de contexte? ET bien restons simple et… Tout cela nous permettra, si tout le monde joue le jeu, de : Élément 1 de ce Juste ce qu’il faut de dispositif : le Programme Planning* et oui, je l’appelle comme je veux! Quand? Alternance entre RDV le mode plénière et le mode par équipe Quand? Quand? Follow Me:

Backlog

Sprint. Release. KPI. Scrum Guide. C'est le titre du 21e chapitre de la 4e édition de mon livre Scrum. Cette dernière édition, sortie il y a un an, marche bien ; alors peut-être que quelques lecteurs sont arrivés jusqu'à ce chapitre… Je m'adresse à eux, qui ont lu ce chapitre, sur lequel j'aimerais bien avoir du feedback, car je l'ai réécrit presque entièrement, avec un positionnement de type "retour ô sources", pour reprendre le thème d'Agile tour Toulouse cette année.

Ou, pour le dire autrement, je me place clairement sur une ligne anti néocons pour reprendre un thème de ma présentation Scrum ? Mon scrotum ! Voici ce que je dis en introduction du chapitre Développer un produit avec plusieurs équipes : Le chapitre « Scrum à grande échelle » avait été ajouté lors de la deuxième édition de ce livre. De mon côté, j’ai expérimenté ce passage à l’échelle dans plusieurs situations. Pour être plus clair sur l’objectif de ce chapitre, je l’ai renommé. Voici le plan de ce chapitre 21 : Sprint zéro. Attention ce n'est pas un vrai sprint, c'est l'échauffement.

Avant de commencer le premier sprint, il y a une période de temps utilisée à préparer ce qui est nécessaire au lancement des sprints dans de bonnes conditions. Jusqu'à récemment, je désignais cette période sous le nom de phase, pour la distinguer de la phase des sprints. Je disais simplement phase de préparation et c'est que j'ai utilisé dans le plugin Scrum pour EPF. J'utilise maintenant, pour suivre la tendance, le terme sprint 0 pour désigner cette période. Les travaux spécifiquement agiles qu'on y fait, c'est élaborer le backlog initial et planifier la release. Les autres travaux à faire dépendent de l'état du projet au moment du lancement de ce sprint 0. TAPIS pour l'équipe Scrum. Scrum, Agilité et Rock'n roll.