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

Mesurer l’agilité

(English follows)

Êtes-vous agile ? Que dire de votre équipe ou de votre organisation ? Une approche populaire pour répondre à cette question est de « mesurer » le niveau d’agilité par le biais d’une liste de contrôle contenant des actions et conditions agiles. Une fois cette liste complétée, on peut malheureusement être tenté de l’utiliser pour séparer les agilistes des non agilistes.

Mesurer l’agilité en se concentrant sur les actions et les conditions du contexte est semblable à mesurer les compétences d’un alpiniste selon sa position sur la montagne. Face à une nouvelle montagne, l’alpiniste d’expérience doit commencer au bas, faire son chemin vers le haut et s’adapter à l’environnement. De sa perspective, plusieurs types de terrain ne seront probablement pas rencontrés et donc plusieurs techniques de grimpe ne seront pas utilisées. Il va de soi que l’inventaire de techniques utilisées ne nous donne de l’information que sur le chemin parcouru, mais pas beaucoup sur l’ensemble de la montagne et encore moins sur l’alpiniste.

Alors… que peut-on mesurer ?

Lire la suite

Une revue de sprint n’est pas une démo

(English follows)

Faites-vous des revues de sprint, démo ou un mix des deux? Le faites-vous de la mauvaise façon? Ne pas le savoir peut être coûteux. Par exemple: sentez-vous que vous devez sacrifier des fonctionnalités pour préparer vos revues de sprint ou vos démos? Malheureusement, plusieurs équipes Agile le font. Voici comment éviter ce piège en comprenant la différence entre ces deux événements.

Lire la suite

Passer des fausses certitudes aux doutes adaptables

(English follows)

Avant de donner un GO à un nouveau projet ou lors du suivis d’un projet en cours, les parties prenantes et organisations exigeront toujours d’avoir un minimum de confiance dans la planification. En méthodes traditionnelles (e.g. en cascade), ceci se reflète souvent par un besoin de savoir exactement ce qui va être fait, quand ce sera fait et à quel prix. Comme nous le savons maintenant, peu importe la précision de ces prédictions initiales, la réalité en constant changement du projet a tendance à rendre le plan inapproprié. Dans de telles cultures de développement, minimiser les écarts face au plan est plus important que de maximiser la valeur du projet.

Lire la suite

Planifiez-vous pour gagner ou pour ne pas perdre?

low-bar

(English follows)

Imaginez que, en tant que membre d’une équipe Agile, vous tentez quelque chose de nouveau afin d’augmenter la qualité de votre produit et que ça ne fonctionne pas. Qu’est-ce qui fait le plus mal? Devoir re-planifier et essayer de nouveau ou devoir rendre des compte sur cet échec?

Imaginez maintenant que vous, toujours en tant que membre d’une équipe Agile, devez faire des choix difficiles dans la gestion de votre temps suite à des imprévues ayant décuplé la grosseur de l’une de vos tâches. Qu’est-ce que vous regretteriez le plus? Ne pas pouvoir augmenter la qualité du produit ou avoir manqué votre estimation?

Voyez-vous où nous allons avec ceci?

Lire la suite

Les 7 flexibilités du backlog Agile

(English follows)

Comment un backlog Agile peut-il survivre à la tempête d’un projet tout en livrant une solution cohésive? En grande partie, ceci vient de ses multiples niveaux de flexibilité. La vision d’un projet, décrite dans un tel backlog, devient adaptable à plusieurs, ou même à la majeure partie, des changements auxquels un projet fait face. Regardons ces options de flexibilité par ordre d’impact croissant sur la portée et la qualité.

Lire la suite

C’est mieux de fonctionner

(English follows)

Le développement logiciel est déjà difficile et, pourtant, face à un choix entre une solution technologique difficile ou une sécuritaire, nous choisissons souvent l’option risquée, souvent accompagnées de bénéfices supérieurs.  Les raisons d’affaires derrière ce choix sont claires, mais que se passe-t-il avec l’engagement de l’équipe face à ce défis supplémentaire?  Regardons de plus près comment, en tant que membre d’une équipe ou en tant qu’équipe dans une organisation, notre engagement change radicalement dépendamment si nous partageons cette charge avec nos gestionnaires.  Ici, l’attitude du leader Agile est clé.

Lire la suite

Attention au glissement du risque

(english follows)

En gestion de projet, atteindre la prédictibilité est un élément clé du succès et son bloquant majeur est le risque. Pour contenir ce dernier lors de la préparation d’un projet, nous prenons grand soin de gérer la quantité de risque inclue dans la portée. En ne voulant rien laisser au hasard, nous augmentons ainsi nos chances de succès en travaillant sur ce risque en début de projet. Lorsque que le risque est résolu ou sous contrôle, nous pouvons enfin tourner notre attention vers la prédictibilité.

N’est-ce pas bizarre alors de voir des ajouts volontaires de risques supplémentaires pendant le projet?

Ceci peut s’expliquer via un comportement de compensation du risque poussant les gens à faire moins attention lorsqu’ils se sentent en sécurité. Cet effet, combiné avec la pression de livrer un maximum de fonctionnalités de qualités, peut nous pousser à prendre des risques supplémentaires en remplacement de ceux qui sont résolus. J’appelle ceci “remplir sa dette de risque”, étant donné que les membres de l’équipe agissant de cette façon sont similaires aux gens qui utilisent leur crédit de façon impulsive. Au même moment, pour certains membres du projet, une baisse de pression sur le risque peut être interprétée comme un signe de perte d’opportunité. Pour résoudre ceci, on doit se concentrer à maintenir un effort constant et soutenable, alors qu’au même moment, on doit accepter une oscillation dans le niveau de risque alors que le focus fait des allers-retours entre le développement et le déploiement.

Le risque est sournois, car il fait toujours partie du développement logiciel, nous désensibilisant ainsi de sa présence et de son importance et aussi parce qu’il prend deux formes : le risque connu, qui peut faire partie de la planification, et les risques inconnus, qui nous surprendront sur le chemin. Plusieurs de ces risques inconnus seront bloquants, nous forçant ainsi à investir un temps précieux pour les résoudre alors que, et nous devrions prendre avantage de ce fait, nous avons le choix d’accepter, gérer ou, plus particulièrement, rejeter les risques connus.

Livrer la vision en résolvant les risques engagés devrait donc toujours surpasser l’ajout de risque additionnel.

Phillipe Cantin

Beware of Risk Creep

When managing a project, achieving predictability is a key element of success and one of its major impediments is risk. To curb this problem while preparing for a project, we take great care, managing the amount of risk accepted in the scope. Not willing to leave anything to chance, we further improve our odds by tackling this risk early in the project which, once removed or under control, clears the way for predictability.

How funny then, to see new risks being purposefully added during a project production.

One reason explaining this is the Risk Compensation behavior, when people tend to be “less careful if they feel more protected”. This effect, combined with the pressure to deliver a maximum of quality features, can drive us to take on new risks as the existing risk is removed. I call this “Maxing out the risk” since team members acting this way are similar to people feeling compelled to max out their credit. At the same moment, for some people, a drop of pressure on risk can be interpreted as a sign of lost opportunity. To resolve all this, we must concentrate on maintaining a constant and sustainable effort level while, at the same time, accepting an oscillation in the risk level as the focus goes back and forth between development and release.

Risk is a sneaky thing as it is always a part of software development, desensitising us to its presence and importance. It is also sneaky as it comes in two shapes: the known risks, which can be part of the planning, and the unknown risks, which will surprise us along the way. We don’t have a choice but to deal with the unknowns [risks] as they pop up here and there during the project, and we should take advantage of this fact. We have a choice to either accept, manage or, especially, reject known risks.

Shipping the vision while resolving the engaged risks should always trump the addition of new risk.

Phillipe Cantin