Adaptation de Scrum – Retour d’expérience 3/7

(English follow) 

Dans ce troisième article de cette série, nous allons expliquer les raisons pour lesquelles plusieurs membres d’une équipe de développement logiciel Scrum ont souvent une spécialisation.  

L’objectif de cette série d’article de blogue est de démystifier l’application du cadre Scrum dans un contexte réel dans lequel, au final, des compromis sur le cadre sont presque toujours nécessaires. Voici la liste des articles de cette série :

  1. Mise en contexte 
  2. Il y a une hiérarchie dans l’équipe Scrum  
  3. Plusieurs équipiers ont une spécialisation (cet article) 
  4. Les changements, en milieu de Sprint et impactant l’objectif de sprint, sont acceptés 
  5. Les projections ne sont pas basées à 100% sur l’empirisme 
  6. La décision d’annuler un Sprint n’est pas prise seulement par le PO 
  7. Des personnes externes à l’équipe Scrum peuvent influencer la planification de Sprint 

Note : Les arguments qui suivent s’appliquent principalement dans le contexte d’une équipe Scrum de développement logiciel.

Les écosystèmes de développement d’aujourd’hui sont composés de plusieurs outils, technologies, infrastructures et langages, chacun offrant plusieurs versions et, très souvent, pouvant être configuré d’une multitude de façons. Pour un développeur ou une développeuse, le simple fait de maintenir ses connaissances à jour sur une pile technologique est un défi et demande un bon investissement de temps. Il est donc très commun pour les développeuses et développeurs logiciels se spécialiser.  

« 75 % des développeurs et développeuses backend répondants ne connaissent qu’une seule pile technologique. »

Lire la suite

Adaptation de Scrum — Retour d’expérience 2/7

(English follows)

Dans le deuxième article de cette série, nous allons expliquer pourquoi une hiérarchie a été mise en place dans les équipes Scrum, pourquoi cette pratique s’applique dans plusieurs contextes et, pour finir, comment elle peut s’aligner avec le cadre Scrum.

L’objectif de cette série de blogues est de démystifier l’application du cadre Scrum dans un contexte réel où, au final, des compromis sur le cadre sont presque toujours nécessaires. Voici la liste des articles de cette série et les liens des articles déjà publiés :

  1. Mise en contexte.
  2. Il y a une hiérarchie dans l’équipe Scrum (cet article).
  3. Plusieurs équipiers ont une spécialisation.
  4. Les changements, en milieu de Sprint et impactant l’objectif de sprint, sont acceptés.
  5. Les projections ne sont pas basées à 100 % sur l’empirisme.
  6. La décision d’annuler un Sprint n’est pas prise seulement par le PO.
  7. Des personnes externes à l’équipe Scrum peuvent influencer la planification de Sprint.

Métier, organisation et leadership

Il est très rare que tous les membres d’une équipe agile soient des experts, vétérans ou séniors. La plupart du temps, on retrouve un mélange de juniors, intermédiaires et séniors qui, ensemble, cumulent « toutes les compétences nécessaires »[1] à la réalisation des items du carnet de produit. Mais qu’est-ce que ça veut vraiment dire « toutes les compétences nécessaires » pour une équipe agile? Selon mon expérience[2], les compétences nécessaires sont composées de deux parties : l’autonomie métier et l’autonomie organisationnelle.

Lire la suite

Adaptation de Scrum — Retour d’expérience 1/7

(English follows)

L’objectif de cette série d’articles de blogue est de démystifier l’application du cadre Scrum dans un contexte réel où, au final, des compromis sur le cadre sont presque toujours nécessaires.

Introduction

Même si l’on respecte un cadre (ou une approche) Lean-Agile, la simple application de certaines pratiques plutôt que d’autres crée souvent une mésentente entre praticiens et praticiennes. Cette mésentente est décuplée s’il est suggéré de sortir du cadre. Comme exemple, j’ai choisi Scrum, car c’est le cadre Agile avec lequel j’ai le plus d’expérience, bien que j’applique aussi Kanban, Lean-Flow and SAFe.

Lire la suite

Retrouvez nos experts aux Agile Tours Québec et Montréal !

Les Agile Tours de Québec et Montréal arrivent à grands pas et comme chaque année, nos experts québécois contribuent fortement à faire de ces évènements les grands rendez-vous agiles de l’année. Scrum, SAFe, l’amélioration continue, la gestion de la qualité, les flux de valeur et l’agilité organisationnelle : voici la palette très étendue des sujets que nous allons aborder avec vous, dans la salle ou derrière votre écran !

Lire la suite

Continuons d’évoluer, révisons notre utilisation des points de récits utilisateurs !

Relisez le guide Scrum. Il n’y a pas de notion de vélocité ou de points de récits utilisateurs. Ce fait, qui m’a été rappelé récemment par un collègue, m’a permis de réaliser les multiples biais injectés dans les fondamentaux Scrum et Agile pour répondre à des besoins de métriques.

Amusez-vous à lire cet article.

L’un des biais les plus flagrants est, pour ce billet, la notion de point pour un récit.

“Working software is the primary measure of progress.” – Manifeste Agile

Lire la suite

Ma critique du guide Scrum

Cette semaine, j’ai choisi le guide Scrum édition novembre 2017 de Ken Schwaber et Jeff Sutherland. Une lecture courte (22 pages) et très intéressante sur le sujet d’un « cadre de travail pour résoudre des problèmes complexes d’adaptation, tout en livrant de manière productive ». Je l’ai lu en détail et je me prête au jeu de l’analyser comme s’il avait été écrit récemment.

Un mot sur l’auteur

Mon expérience du Scrum est très limitée. J’ai lu le guide Scrum pour la première fois en diagonale cette année. Ma formation académique est technique et mon expérience professionnelle est essentiellement du côté de la gestion de projet en mode chaotique.

J’explore depuis récemment (2010) le Lean Management, le Kanban et la gestion quantitative. Je lis beaucoup sur l’Agilité depuis les débuts du manifeste, mais j’ai surtout exploré Extreme Programming du temps où je produisais encore de la valeur pour mes clients. Toute opinion comprise dans ce texte est un reflet de ce cheminement.

Lire la suite

MVP (Produit Minimum Viable), si simple et si confus à la fois !

En équipe, vous êtes en train de faire votre plan de livraison durant la phase de préparation d’un projet X. Celui-ci est basé sur vos cas d’utilisation ou encore de vos histoires, et lorsqu’est venu le temps de déterminer votre MVP, votre PO vous indique que son produit minimum viable (MVP) constitue la livraison de l’ensemble des fonctionnalités.

Vous lui faites alors remarquer que l’essence même de l’Agilité est de piloter par la valeur, et non par le plan. Ceci implique de rendre l’investissement et le temps de développement fixe, tout en laissant la latitude d’estimer la portée qui nous permettra possiblement de faire émerger le produit minimum viable.

Votre PO vous mentionne alors que le demandeur a émis des objectifs (sur lesquels la portée a été basée) et que, pour être viable, il doit tous les rencontrer, donc il doit tout livrer!

Lire la suite