Est-ce professionnel de finir le Sprint à 21h ?

Est-ce professionnel de finir le Sprint à 21h ?

Temps de lecture estimé : 10 minutes

Résumé

Parfois, certaines actions semblent bonnes à court terme, mais masquent en réalité des dysfonctionnements lourds. Faire des heures supplémentaires en situation de stress n’est pas un remède viable à long terme et ne doit pas être vu comme une solution professionnelle, mais un signal d’alarme à entendre courageusement.

Contexte

Nous sommes jeudi soir, la veille de la fin du Sprint. Il est prévu par le Product Owner que l’incrément qui va être inspecté demain soit mis en production à l’issue de la Sprint Review. La dernière mise en production a été réalisée plusieurs Sprints plus tôt. Le Scrum Master constate que “L’équipe reste jusqu’à 21 h la veille de la mise en production, elle est très engagée et professionnelle !” En êtes-vous certain ? Est-ce un comportement que vous souhaitez valoriser et voir reproduit régulièrement ? Ce comportement est-il vraiment aligné avec le rythme soutenable prôné par le Manifeste Agile et les valeurs de Scrum ?

Symptômes

Jeudi matin, la mise en production espérée le lendemain est très incertaine, d’autant plus que de nombreux travaux sont encore en cours.

Pourtant, aucune alerte ni action corrective n’a été levée au sein de l’équipe de développement ou avec le Product Owner pendant le Sprint.

Tous ces travaux représentent un risque important vis-à-vis de l’atteinte du Sprint Goal et de la réussite du Sprint.

En outre, les procédures de mise en production sont complexes et demandent l’intervention d’autres équipes opérationnelles qui ont les compétences, outils ou habilitations requises pour réaliser les installations sur les serveurs de production.

Enfin, l’entreprise attend beaucoup de cette nouvelle mise en production. La dernière a eu lieu il y a plusieurs Sprints, et l’équipe ressent une forte pression liée à l’importance de cette nouvelle mise en production.

Le risque et les enjeux sont ressentis par tous comme étant tellement élevés que l’échec n’est plus une option acceptable pour l’organisation.

Le niveau de stress est très élevé, l’équipe de développement sait déjà qu’une journée infernale s’annonce.

L’équipe marche sur une corde raide, elle ne travaille plus en confiance, dans le respect d’un rythme de travail soutenable, elle s’épuise physiquement et psychiquement, les risques d’erreurs croissent, la motivation baisse.

Causes

Une grande force de Scrum est d’être un formidable outil de gestion de risques.
Dans un environnement complexe, une approche empirique telle que Scrum est un outil parfaitement approprié : la part d’incertitude est si importante que nous avons plus de chance de réussir par l’exploration, l’analyse et la réaction que par la conception et le suivi d’un plan rigide.

Pour parvenir à cela, nous avons besoin des 3 piliers de l’empirisme que sont :

  • La Transparence,
  • L’Inspection
  • L’Adaptation.

Mais l’empirisme fonctionne à condition de travailler dans un contexte où l’adaptation est possible, c’est-à-dire qu’il est possible que les résultats ne soient pas ceux escomptés et que des décisions soient prises pour mettre en place des adaptations pertinentes.

En clair : vous avez le droit à l’erreur, car le risque lié à une erreur probable est acceptable.

Il est malheureusement fréquent que Scrum soit mis en place dans des organisations qui n’ont pas pleinement intégré ce que signifient les notions fondamentales d’empirisme et de complexité.


Scrum est mis en place sans changement d’état d’esprit ni changement de comportements :

on travaille “comme d’habitude”, on essaye au mieux de respecter le plan de livraison initialement prévu (respect des délais et des périmètres initialement prévus), mais en utilisant un nouveau jargon.


Ainsi, le Product Owner continue de prévoir des grosses livraisons peu fréquentes, ce qui affecte la transparence et restreint les opportunités d’inspection. L’horizon de risque acceptable pour fonctionner de manière empirique est alors largement dépassé. On ne “gère” plus les risques, on espère, on croise les doigts, on brûle des cierges et on fait tout pour que le plan soit respecté comme prévu.

Le travail est poussé vers l’équipe sans que l’organisation ne respecte la capacité et la responsabilité de l’équipe ou sans que l’équipe n’ait le courage de refuser de se laisser imposer plus de travail que de raison.
Il est également fréquent que les membres de l’équipe de développement travaillent en parallèle sur de trop nombreux Product Backlog items. L’équipe n’est pas focalisée sur l’atteinte du Sprint Goal, mais sur l’occupation des “ressources”.

De ce fait l’implémentation des Product Backlog items débute tôt dans le Sprint, mais ils sont déclarés “finis” très tardivement, et l’intégration de l’ensemble des travaux se termine dans la douleur jusqu’au jeudi soir 21 h !


L’équipe n’arrive pas à réduire les risques à cause de ce manque de focalisation pour terminer régulièrement et fréquemment les Product Backlog items, un par un au fil du Sprint. Parmi les causes possibles, on peut retrouver une insuffisance de collaboration entre les membres de l’équipe.

Cette insuffisance peut être accentuée par un manque de polyvalence (profils en “I” plus que profils en “T” car chacun a son domaine d’expertise et ne peut ou ne veut pas contribuer sur un autre domaine) ; un manque de compétence ou d’outils pour atteindre une Définition de Terminé permettant une mise en production simple ; des dépendances avec d’autres équipes qui empêchent notre équipe d’être suffisamment autonome pour implémenter et déployer des incréments seule et rapidement.

Tout cela laisse planer les risques comme une épée de Damoclès au dessus de la tête de l’équipe jusqu’à la toute fin du Sprint.

Remèdes possibles

Gunther Verheyen nous aide à comprendre ce qui signifie la notion d’engagement dans le contexte de Scrum :

“L’engagement concerne le dévouement et s’applique aux actions et à l’intensité de l’effort. Il ne s’agit pas du résultat final, car cela en soi est souvent incertain et imprévisible pour des défis complexes dans des circonstances complexes.”

Une équipe Scrum qui se déclare à la fois professionnelle et engagée doit donc limiter l’accumulation des risques en faisant les efforts pour se focaliser et collaborer à faire le travail différemment.

L’équipe doit exploiter l’empirisme pour travailler dans un périmètre de risque tolérable, ce qui signifie qu’au quotidien, en particulier grâce au Daily Scrum, l’équipe de développement doit inspecter le travail restant à accomplir pour atteindre le Sprint Goal et agir dès qu’elle considère, de manière professionnelle, que les risques s’accroissent au lieu de diminuer.

Par exemple, si l’équipe se rend compte que l’implémentation d’un Product Backlog item est plus difficile que prévu, le Sprint Backlog est impacté. Cela peut conduire l’équipe de développement à considérer maintenant que l’implémentation d’un autre Product Backlog item est fortement compromise, sauf à sacrifier la qualité, ce qui n’est pas une option acceptable de la part d’une équipe Scrum professionnelle.

L’équipe Scrum pourra alors agir avec ouverture, courage et professionnalisme et décider d’adapter le Sprint Backlog tout en préservant le Sprint Goal.

Cette adaptation peut se faire en décidant de revoir le découpage des Product Backlog items en isolant les fonctionnalités qui assurent l’atteinte du Sprint Goal et en laissant de côté pour des Sprints ultérieurs des fonctionnalités moins importantes. Mais l’adaptation peut se faire également en organisant le travail de l’équipe de développement différemment, en mettant en place du binômage, du mob programming, de la formation ou du mentoring pour faciliter la polyvalence, l’autonomie et la focalisation de l’équipe.

Ainsi, la gestion des risques est un sujet de préoccupation quotidien et n’est plus un sujet qui se rappelle douloureusement à l’équipe Scrum uniquement la veille de la fin du Sprint ou d’une mise en production.

De son côté, le Product Owner devrait rechercher à limiter autant que possible la taille des livraisons idéalement dès qu’un incrément est prêt, plusieurs fois par Sprint. Et bien sûr, le Scrum Master est là pour rendre tous ces problèmes transparents pour que l’équipe mette en place les adaptations pertinentes.

Conclusion

Une utilisation professionnelle de Scrum doit se traduire par le respect et la mise en oeuvre de l’ensemble des valeurs et principes de l’agilité.

En particulier, des produits à forte valeur ajoutée doivent être livrés rapidement et régulièrement, sans jamais abaisser les critères de qualité, dans le respect d’un rythme de travail soutenable pour tous.

Charge à chacun d’agir en professionnel responsable et d’avoir le courage de transformer ses manières de travailler afin d’obtenir tous les bénéfices de l’Agilité. Cela peut nous inviter à remettre en cause nos modèles mentaux si l’on veut obtenir des changements pérennes.

Et vous, qu’allez-vous avoir le courage de faire différemment maintenant ?

Different

Améliorer la prédictibilité

Améliorer la prédictibilité

Temps de lecture estimé : 10 minutes

Résumé

Améliorer la prédictibilité est important pour notre organisation personnelle et nos parties prenantes.

Dans l’article, Scrum et efficacité personnelle, j’ai partagé mon expérience d’utilisation de certains principes de Scrum pour être plus efficace personnellement.

Le but étant de démontrer qu’il est possible de travailler autrement et être plus serein. Dans cet article, je partage des idées pour améliorer la prédictibilité du travail que je suis en mesure de faire chaque semaine (la durée de mes Sprints personnels).

Améliorer la prédictibilité – travailler différemment !  Si vous appliquez cette manière de faire à vous-mêmes, vous comprendrez quelle est l’état d’esprit à avoir dans un contexte complexe et comment l’empirisme vous aide à devenir meilleurs, individuellement ou en équipe. Scrum est décrit dans le Scrum Guide, les idées suivantes utilisent certains principes de l’empirisme et de Scrum.

QU’EST-CE QUE J’AI APPRIS DES SPRINTS PASSÉS

L’analyse des données récoltés au cours des semaines passées m’a permis d’apprendre à :

  • Découper plus finement mes activités
  • Trouver des axes d’amélioration
  • Mieux comprendre ma capacité à faire

Améliorer la prédictibilité

Découper plus finement mes activités

Je n’ai jamais passé du temps à réfléchir à toutes les activités indispensable pour écrire un article du blog, d’habitude dès que j’ai une idée, j’écris et je publie l’article.

Parfois je ne finis pas, car je commence à faire autre chose.  Pour changer cette situation, la première chose que j’ai faite a été simplement d’écrire un élément dans mon Product Backlog personnel : « Idée blog : Scrum et efficacité personnelle ».

J’ai créé une checklist dans la fiche, en pensant à tout ce que je fais quand j’écris un article : écrire l’article en français, relire l’article en français, chercher les images pour l’article, poster l’article sur le blog en français, traduire l’article en anglais, etc… à la fin, au total, j’ai créé une vingtaine de tâches.

C’est assez révélateur de la complexité de l’activité, le voir matérialisé est assez impressionnant.

Exemple item backlog
Detail item backlog

Je me suis rendu compte que je pouvais découper en trois éléments distincts tout le travail décrit dans la checklist.

J’ai finalement crée trois éléments distincts cohérents et bien séparés. Le découpage plus fin amène à des avantages indéniables :

  1. Je peux publier un article en français en Sprint X, et en anglais le Sprint X+1 (avant je publiais tout en une seule fois, après deux semaines de travail). En résumé je peux créer de la valeur (j’espère) et obtenir un feedback plus rapidement.
  2. Je peux varier le travail de chaque Sprint, en ajoutant différents éléments et pas passer une semaine à travailler uniquement sur un billet de blog
  3. J’améliore ma capacité à estimer la quantité de travail à faire en un Sprint
  4. J’automatise, délègue ou élimine une partie du travail pour lequel je n’ai pas de valeur ajouté.
Items backlog

Améliorer la prédictibilité

Trouver des axes d'amélioration

En analysant le travail fait à la fin de chaque Sprint, il est possible de se rendre compte du travail qui peu être automatisé. J’ai remarqué que je passais pas mal de temps à fournir des créneaux de disponibilité à mes prospect, clients ou collègues.

Une action concrète d’amélioration a été l’implémentation de la prise de RDV automatisée (Planifier un entretien avec Fabio). Une chose en moins à gérer et qui m’aide beaucoup.

Améliorer la prédictibilité

Mieux comprendre ma capacité à faire

En découpant mes activités plus finement, comme nous l’avons vu précédemment, j’ai pu améliorer la compréhension de ma capacité à faire en un Sprint.

Je sais aussi prévoir dans quelle semaine je m’occuperai d’un nouvel élément du Product Backlog. Évidemment plus on positionne l’élément loin dans le temps, moins les prévisions seront précises.

Exemple : cette semaine,  j’ai reçu l’article d’un collègue pour relecture. Je peux prévoir que pour la fin de la semaine prochaine j’aurais fait le travail.

Cela implique que:

  1. vous êtes concentrés sur l’objectif du Sprint en cours
  2. vous savez ce qui est important pour vous. La collaboration et l’entraide est important pour moi, cette demande entre directement en haut du Product Backlog. Une demande administrative se trouvera plutôt au fond du Product Backlog.

Pour terminer avec la prédictibilité, il est très utile de compter le nombre d’éléments du Product Backlog que vous êtes capables de terminer à chaque Sprint.

Nombre Items 1
Nombre Items 2

Au fil du temps, en gagnant de l’expérience dans le découpage fin de vos activités et en automatisant d’autres, vous aurez une meilleure capacité de prévisions.

Voici un exemple de mes derniers Sprints (Velocity = nombre d’éléments du Product Backlog terminés à la fin du Sprint).

 

Sprint Sprint Goal Velocity
1 Understand French training requirements 28
2 Prepare Virtual PSPO training 24
3 Test Virtual PSPO training 25
4 Run Virtual PSPO training 14
5 Improve Virtual PSPO training from experience 13
6 Write first XXX whitepaper revision 19
7 Complete XXX whitepaper 11
Mes derniers Sprints, avec le Sprint Goal correspondant et la quantité d’éléments de Product Backlog terminés (Velocity)

Les données relatives à la vélocité me sont utiles pour améliorer les prévisions. Au début du Sprint 7, je connaissais la moyenne de mes trois meilleurs Sprints (25 éléments), celle de mes trois pires Sprints (15 éléments) et la moyenne la plus probable (20 éléments). 

En connaissant le nombre total d’éléments dans mon Product Backlog, je peux réaliser ce qu’on appelle un Burndown Chart, une manière de visualiser le travail fait et celui restant à faire (voir mon burndown personnel).

AMELIORER LA PRÉDICTIBILITÉ - Burnout Personnel
Burnout Personnel

Le Sprint 7 a révélé que, en réalité, j’ai encore beaucoup à apprendre de ma capacité à faire. En effet j’ai pu terminer uniquement 11 éléments du Product Backlog et toutes les données statistiques doivent être revues. C’est la preuve qu’il est utile de procéder ainsi.

Remarque : la vélocité est une donnée empirique, constatée à la fin du Sprint. Elle ne donne pas d’indication sur la valuer crée. Une vélocité faible, n’est pas forcement une information negative. Vous pouvez lire l’article « Velocity in Scrum, actually » pour approfondir ce sujet

Quand j’aurais mieux appris à faire mes prévisions, je pourrais aussi avoir une meilleure prédictibilité.

Conclusions

Après avoir vu dans le premier article, Scrum et efficacité personnelle, comment organiser son travail en Sprints, nous avons exploré comment utiliser les données recueillis pour améliorer notre prédictibilité.

Vous comprenez comment cela fonctionne au niveau personnel, attention vous ne pratiquez pas Scrum, mais les principes applicables dans un contexte complexe, comme peuvent l’être nos vies, parfois.

Au sein d’une Scrum Team, utilisez-vous les données empiriques pour vous améliorer ? Quelles actions concrètes et mesurables avez-vous implémenté récemment ? Le découpage du Product Backlog en éléments plus fins quels résultats a donné ?

J’espère que, grâce à ces articles, vous obtenez une meilleure organisation personnelle et une meilleure prédictibilité. Si quelqu’un vous dit qu’il faut travailler plus, aidez cette personne à comprendre qu’en réalité il faut travailler différemment, vous savez comment maintenant !

efficacité professionnelle

Scrum et efficacité personnelle

Scrum et efficacité personnelle

Temps de lecture estimé : 10 minutes

Résumé

Parfois, certaines actions semblent bonnes à court terme, mais masquent en réalité des dysfonctionnements lourds. Faire des heures supplémentaires en situation de stress n’est pas un remède viable à long terme et ne doit pas être vu comme une solution professionnelle, mais un signal d’alarme à entendre courageusement.

Scrum et efficacité personnelle sont ils compatibles ? Ces dernières semaines j’ai expérimenté l’utilisation de Scrum pour mon organisation personnelle. Si vous avez beaucoup de sujets à traiter, vous vous sentez débordés et dépassés par les événements, alors il est possible que cet article vous soit utile. J’en suis à la septième semaine d’expérimentation.

Cet article pourrait être utile aussi aux personnes qui ne connaissent pas Scrum. En effet, les principes que j’explique et que je me suis appliqué ne sont rien d’autre que les principes de Scrum.

Rendre le travail à faire visible

Un des facteurs d’anxiété et de stress chez moi dérivent du fait que j’essaye de tout mémoriser. Il est évident que cela dévient impossible à un moment donné, pour cela je m’aide avec l’agenda, les notes et les rappels. Je voulais trouver un moyen plus efficace de rendre le travail visible, j’ai alors pensé à Trello (il y a d’autres outils) et j’ai commencé à reporter sur cet outil toutes mes notes, mes rappels et mes idées à explorer.

J’ai organisé l’espace avec les colonnes suivantes :

  • Modèles : tous les modèles d’éléments de backlog, pour éviter de retaper à chaque fois l’élément entier. C’est utile, par exemple, pour organiser une formation car j’ai une check-list avec 45 items.
  • Product Backlog : la liste de toutes les choses à faire
  • Sprint Backlog : la liste de toutes les choses à faire dans un Sprint (dans mon cas une semaine), parfois je rajoute des détails dans les commentaires de la fiche
  • On Going : la liste des choses en cours. Je limite volontairement à un élément cette colonne (je me demande si je ne vais pas la retirer, car en gros, l’élément en haut du Sprint Backlog est l’élément on-going)
  • Done : toutes les choses que j’ai terminé. Terminé pour moi veut dire que je n’ai plus rien faire après et pour vous ?

J’ai aussi ajouté trois autres colonnes : « A lire », « En cours de lecture », « Lus ». Cela parce que j’ai remarqué que j’étais en train de lire trois livres en parallèle et j’avais du mal à les terminer. J’ai donc décidé de rendre cela visible et de me fixer des objectifs de lecture. J’ai séparé la lecture du Product Backlog, car j’ai vraiment beaucoup de livres à lire et cela aurait difficile à suivre dans le Product Backlog.

Exemple de mon tableau Trello

Les codes couleur me sont utiles pour comprendre dans quel domaine je passe la plupart de mon temps, ou pour bien équilibrer un Sprint. Par exemple, les items rouges correspondent aux tâches administratives : si je me rends compte que la moitié d’un Sprint est constitué de rouge, je comprends qu’il y a un problème, car cela m’empêche de créer de la valeur et faire ce que j’aime : Scrum (vous l’aviez deviné ?).

Ordonnancer le travail à faire

Au début, vous aurez uniquement la colonne Product Backlog pleine d’éléments, les autres colonnes seront vides. Il est temps maintenant d’ordonnancer le travail à faire. Vous utiliserez les critères qui sont les plus adaptés à votre cas, comme : urgence, importance, gains financiers, etc. Personnellement j’ai ordonnancé avec un objectif en tête : à chaque semaine créer du contenu de valeur (le plus petit qu’il soit) plus d’autres choses (tâches administratives, etc.).

durée et objectif d’un Sprint

Vous l’aviez sans doute deviné, maintenant il est temps de se fixer des objectifs, mais avant vous devez décider la durée du Sprint (j’ai choisi une semaine), ne dépassez pas le quatre semaines !

Une fois la durée fixée, vous allez piocher dans votre Product Backlog, en imaginant tout le travail que vous allez pouvoir faire au cours du Sprint. Ne passez pas plus d’un quart d’heure dans cette activité, de toute manière vous allez vous tromper au début 😉

Je me suis fait une fiche modèle sur Trello qui délimitera un Sprint et dans laquelle je note mon Sprint Goal, l’objectif pour la semaine. Cela me permettra d’embarquer dans le Sprint Backlog en grande partie les éléments du Product Backlog aligné avec le Sprint Goal (et logiquement en haut de la liste).

Le modèle que j’utilise pour créer un Sprint. Je remplace le X par le numéro du Sprint et j’ajoute l’objectif
Un exemple de mon premier Sprint, avec le but spécifié. Entre parenthèse il y a le nombre d’éléments du Product Backlog que j’ai terminé au cours du Sprint.

Sélection du travail à faire au cours d’un Sprint

Maintenant que l’objectif est clair, je vais choisir dans le Product Backlog les choses à faire (en général je fais cela le vendredi soir, pour démarrer le lundi avec une liste déjà prête… mais que parfois je modifie).

Il faut bien réfléchir à vos disponibilités, pensez aussi à dégager du temps pour votre bien être. Par exemple, j’envisage d’ajouter des éléments « Sport » à ajouter et inclure dans un Sprint. Souvent les bonnes idées me viennent en courant, le cerveau est bien fait et il utilise ce temps pour digérer l’information.

Vous êtes prêts pour votre premier Sprint, préparez vous, il sera plein de surprises 🙂

Le Sprint

Démarrez votre cycle de travail, en prenant le soin de respecter les quelques règles que vous vous êtes fixés. Les miennes sont : pas plus d’un élément à la fois, fini veut dire que je n’ai plus rien à faire sur l’élément, pas de concessions sur la qualité du résultat.

En ce moment j’expérimente le timeboxing de certaines activités consommatrices de temps, comme par exemple la lecture et réponses des emails. Quand je commence à regarder mes mails, je démarre le minuteur à 30 minutes, quand ça sonne j’arrête de m’occuper des emails et je considère la tâche comme terminée. J’ai trois éléments dans le Sprint Backlog : check emails matin, check email après-midi, check email soir… ça fait une heure trente ! Mais c’est un timebox, donc parfois ce travail me prends seulement 5 minutes. Le minuteur est utile quand vous avez un milliard de messages et vous risquez d’y passer la matinée, ce qui était mon cas.).

Chaque matin, relisez votre objectif du Sprint… êtes vous toujours concentrés sur ce but, l’aviez vous oublié ? Est-il toujours d’actualité ?

Petit conseil : ne changez pas l’objectif du Sprint une fois que vous avez démarré. Si quelque chose d’importante tombe, notez le dans le Product Backlog. S’il est vraiment très important, mettez le en haut du Product Backlog, vous le traiterez le Sprint prochain. Ne vous faites pas distraire par les nouveautés.

Fin de Sprint

Ça y est, nous sommes à la fin du Sprint (de la semaine pour moi). Maintenant il est très important de prendre le temps d’analyser le travail fait, le travail qui reste dans la colonne « On Going » et, surtout si votre objectif à été atteint ou pas ! Dans le premier cas, c’est bouteille de champagne, dans le deuxième une bière… et oui, il faut savoir se récompenser à la hauteur de ses résultats :-). Je parie que cela vous motivera a atteindre votre Sprint Goal… bien évidemment, si vous n’aimez pas, ou vous ne pouvez pas boire de l’alcool, réfléchissez à la récompense que vous voulez vous donner à la fin du Sprint.

Ce n’est pas fini. Maintenant il faut savoir comment mieux faire au prochain Sprint. Prenez une heure, au moins, pour réfléchir à toutes les choses qui se sont bien passées et aux améliorations que vous souhaitez mettre en place pour le prochain Sprint.

Obligez vous, à chaque Sprint, à trouver une action d’amélioration que vous mettrez en oeuvre concrètement au prochain Sprint. Définissez, dans l’action d’amélioration, les résultats attendus au cours du Sprint et vérifiez les à la fin.

Maintenant les éléments qui restaient dans la colonne « on-going » et « Sprint Backlog » doivent être remises dans le Product Backlog.

Faite la somme des éléments qui se trouvent dans la colonne « Done » pour le Sprint que vous venez de terminer. Cela nous sera utile plus tard.

Il est vendredi soir, mon Sprint vient de se terminer, ceci était le dernier Item à faire. Une fois l’article publié je mettrai l’élément en « Done » et je verrai si je peux ouvrir ou pas une bouteille de Champagne 😉

Dans deux semaines je publie un nouveau article à ce sujet : comment améliorer la prédictibilité personnelle avec un Burndown chart.

Bon week-end !