Votre projet est-il un bon candidat pour Agile?

Pour réussir avec agile, assurez-vous que vos projets sont de bons candidats agiles.

http://www.bonniebiafore.com/is-your-project-a-good-candidate-for-agile/ par Bonnie Biafore

Ne forcez pas l’agilité sur chaque projet que vous exécutez simplement parce que les méthodologies agiles et itératives sont « à la mode ». Pour réussir avec agile, assurez-vous que vos projets sont de bons candidats agiles.

Voici les questions à vous poser avant de sélectionner une approche agile pour un projet.

Le projet est-il suffisamment important pour que les bonnes personnes s’y consacrent ?

Agile produit des résultats rapidement, ce qui nécessite un gros investissement de temps pour les membres de votre équipe. Les équipes agiles sont composées de gens du business et de personnes techniques qui sont essentiels à vos opérations commerciales. Assurez-vous qu’ils ont suffisamment de temps pour contribuer à votre projet. Cela nécessite souvent des compromis difficiles entre le travail de projet et les opérations.

Les membres de votre équipe ont-ils suffisamment de profondeur et d’étendue de connaissances ?

Ce qui rend les méthodologies agiles agiles, c’est la réactivité à l’évolution des besoins. Les experts du métier travaillent en étroite collaboration avec les experts de l’équipe technique pour fournir ce qui est nécessaire -> rapidement. Pour cela, votre équipe a besoin d’une connaissance approfondie des domaines métiers et techniques touchés par le projet. L’équipe réévalue constamment les besoins business du projet aux niveaux du produit, les fonctionnalités macros et micros et la priorité du besoin.

Votre sponsor a-t-il un état d’esprit agile ?

cadre exécutifLa réactivité agile à l’évolution des conditions business et son approche apprentissage sont très différents des méthodes de projet traditionnelles.

Votre sponsor doit être à l’aise avec l’évolution des besoins et des priorités de l’entreprise, prêt à participer à des revues fréquentes du produit en pleine évolution et prêt à intervenir pour obtenir les ressources agiles dont le projet a besoin.

Votre équipe peut-elle être co-localisée ou virtuellement co-localisée ?

Agile implique un dialogue profond, interactif et souvent dérangeant, qui nécessite l’environnement le plus riche que vous puissiez créer. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la co-localisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir.

Y a-t-il une synergie entre les membres business/métiers et technique de votre équipe ?

L’agilité nécessite le dévouement d’experts business et techniques qui soient ouverts aux nouvelles idées et se soutiennent mutuellement. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations. Pour réussir, une équipe agile doit bien s’entendre.

Le produit peut-il être construit de manière itérative ?

Les meilleures qualités d’Agile proviennent de la fourniture de parties utilisables de la solution tout en apprenant de chaque itération. Bien que ce soit plus courant avec les produits logiciels, d’autres produits peuvent également être fabriqués de cette façon. Avec un peu de créativité, les déménagements, les déploiements de processus et même certains projets de construction peuvent être produits par étapes itératives.

Pour en savoir plus sur les méthodologies agiles, consultez Become an Agile Project Manager learning path dans LinkedIn learning library.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agilescru

L’anti-modèle Agile dit du « Planning Tetris » se manifeste souvent avec l’approche SAFe

La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. 

The « Planning Tetris » Antipattern

https://failfastmoveon.blogspot.com/2021/11/the-planning-tetris-antipattern.html par Michael Küsters

 Nous devons utiliser tous nos Story Points

Ceci est un dysfonctionnement courant dans de nombreuses équipes Scrum, et en particulier dans les Agile Release Trains de SAFe où les équipes opèrent sur un horizon de planification de 3 à 5 sprints. Il en résulte un antipattern souvent appelé « Planification Tetris. » C’est extrêmement nocif, et voici pourquoi.

Bien que le plan de fonctionnalités ci-dessus semble être parfaitement optimisé, la réalité semble souvent différente : tous les articles génèrent de la valeur plus tard qu’ils le  pourraient potentiellement; à un coût plus élevé, en demandant plus de temps et avec une efficacité moindre !

Accumulation des travaux en cours

La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. C’est efficace sur le plan des ressources (c-à-d. maximiser l’utilisation du temps disponible), mais pas du débit (c-à-d. maximiser le rythme auquel la valeur est générée).

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Cela mène à une augmentation du travail en cours, ce qui est un problème pour de multiples raisons

Déni de valeur

Tout comme dans l’exemple de diagramme ci-dessus, « Fonctionnalité 1 » et « Fonctionnalité 2 » pourraient chacun être finis en un seul Sprint. Et encore, Fonctionnalité 1 ne fournit aucune valeur dans Sprint 1, et Fonctionnalité 2 n’a aucune valeur dans Sprint 2. Donc, nous perdons 1 Sprint de mise sur le marché sur Fonctionnalité 1 (notre plus haute priorité) – et sur Fonctionnalité 2 aussi :

Un exemple parfait de la façon dont l’utilisation optimale de l’équipe fait arriver la valeur plus tard !

Perte d’argent

Imaginez maintenant que chaque fonctionnalité coûte moins cher qu’elle ne le vaut (ce qu’elle devrait, sinon elle ne vaudrait pas la peine d’être développée) et vous voyez que l’efficacité « économisée » d’avoir travaillé sur les caractéristiques 3 et 4 avant de terminer la caractéristique 1 coûte à l’entreprise plus d’argent que les bénéfices cumulés.

Perte d’efficacité

Vous pouvez argumenter que « différentes personnes travaillent sur les fonctionnalités, donc il n’y a pas de multitâche. »

Oui, et Non. Que se passe-t-il vraiment ?

Le Sprint Planning du Sprint 1 doit discuter de 3 caractéristiques : 1, 3 et 4. Cela signifie que toute l’équipe discute de trois sujets différents (dont aucun ne sera livré dans ce Sprint). La même chose se produit dans les réunions journalières et les revues. Et peut-être aussi au niveau du code source. Les interférences des fonctionnalités peuvent également alourdir la complexité de la configuration technique, des processus de déploiement et autres.

L’équipe devient plus lente, donc moins efficace.

Ajout de risques inutiles

Livre sur Amazon

Dans les statistiques, il y a un phénomène appelé « la probabilité élevée d’événements à faible probabilité ». Permettez-moi d’expliquer brièvement : Il y a une quantité infinie d’événements presque totalement improbables, mais malheureusement, l’infini élevé divisé par l’infini faible est encore un nombre proche de : Quelque chose va arriver. Vous ne savez tout simplement pas quoi, ni quand, alors vous ne pouvez pas vous préparer ni en atténuer les effets. Comme vous ne savez pas quel aspect de votre plan sera touché lorsqu’un risque frappe, vous serez toujours pris par surprise.

En quoi est-ce un plus gros problème dans la planification de Tetris que dans la livraison séquentielle ?

Effet massif de répercussions en chaine

Certains effets « dominos » sont quasiment impossibles à arrêter.

Lorsque vous travaillez sur un sujet et qu’un événement touche toute votre équipe, vous avez à communiquer sur un problème. Lorsque la même chose se produit alors que vous travaillez sur de multiples sujets, tous sont touchés, et vous générez un effet de répercussion en chaine beaucoup plus fort.

Mesures d’atténuation complexes

Comme plusieurs sujets sont en cours de traitement, vous vous retrouvez soudainement à limiter l’impact sur plusieurs sujets. Et cela signifie des efforts d’atténuation multiples : moins de temps pour travailler, et en même temps un risque plus élevé que toutes les mesures d’atténuation ne réussissent pas. Vous vous retrouvez avec une probabilité plus élevée de ne pas être en mesure de revenir sur les rails !

Conséquences chaotiques

L’effet des répercussions en chaine dans l’organisation et des mesures d’atténuation pourraient entraîner des conséquences imprévues qui sont encore plus difficiles à prévoir que l’événement déclencheur. Dans de nombreux cas, la seule solution possible est de dire stop et de marquer tous les sujets commencés comme retardés, puis d’essayer de réparer la casse à partir de là.

Préparez vous à l’échec

Relisez ce billet sur la Loi de Parkinson

Il y a la Loi de Parkinson – « Le travail s’étend toujours pour remplir la quantité de temps disponible« . C’est souvent utilisé comme argument pour commencer un autre sujet, parce qu’il arrête le sur-investissement et garde les gens concentrés.

Mais il y a aussi la Loi des moyennes : « Les plans basés sur les moyennes échouent la moitié du temps. »

Cette dernière fait de la planification Tetris une approche suicidaire d’un point de vue business : Elle enclenche un cercle vicieux.

Échec prévisible

Parce qu’il n’y a pas de marge de temps intégrée dans la planification Tetris, le plan à mi-parcours échouera automatiquement dès qu’une seule fonctionnalité s’avère plus complexe que prévue. Plus les fonctionnalités font partie de notre pile Tetris, plus il est probable qu’au moins l’une d’entre elles échouera. Et l’équipe sera généralement blâmée pour cela. Pour cette raison, nous nous retrouvons avec…

Des estimations prudentes

Les équipes doivent insérer des zones tampons dans leurs estimations de fonctionnalités afin de réduire la probabilité de défaillance. Lorsqu’un plan Tetris s’étend sur plusieurs sprints, il se peut que certaines fonctionnalités ne soient pas « prêtes » à être implémentées pendant le sprint lorsque la marge de manœuvre serait disponible – donc nous nous retrouvons avec la Loi de Parkinson, les estimations gonflées ne réduisent pas les probabilités d’échec.

Un débit en baisse

À ce stade, La loi de Parkinson se combine avec le défaut des moyennes pour mettre l’équipe KO. Indépendamment de la manière conservatrice dont les estimations ont été construites, l’équipe finira toujours par échouer la moitié du temps. La conséquence est que le débit business continue de diminuer (Jusqu’à un fond intéressant : quand un Sprint ne contient qu’une seule caractéristique !)

Étranglement de l’équipe

Examinons maintenant l’impact psychologique de la Planification Tetris.

Pas d’espace pour la créativité

Je n’ai jamais vu une organisation où le marketing produits était heureux que les développeurs ajoutent des « espaces créatifs » dans un plan Tetris. Il s’agit de lancer fonctionnalité, après fonctionnalité, après fonctionnalité, sans pause, sans pause. Lorsqu’une fonctionnalité est terminée, une autre est déjà en cours. Il n’y a pas de place pour la créativité.

Pas d’espace pour la croissance des personnes

Le seul résultat opérationnel pertinent dans les plans Tetris est généralement la valeur opérationnelle fournie.

Il ne tient pas compte du fait que les développeurs sont le capital humain de l’organisation, et leur croissance accroît la capacité de l’organisation à offrir de la valeur.

Surtout dans notre industrie technologique en rapide évolution, ne pas croître équivaut à reculer jusqu’à ce que finalement, l’équipe ne soit plus compétitive.

Pas de place pour l’amélioration

Je conseille souvent que les développeurs devraient prendre un certain temps pour regarder le travail « fait » pour réfléchir à comment il aurait pu être mieux fait, et de transformer cette meilleure façon en action. Avec Planning Tetris, cette opportunité n’existe pas car il y a toujours  une autre fonctionnalité en attente et améliorer quelque chose qui existe est toujours moins important que de livrer la prochaine grande chose. Cela finit souvent dans des produits ratés qui ne sont pas un plaisir ni pour les développeurs ni pour les clients !

Maintenant… et alors ?

Le fait que la planification Tetris soit une mauvaise idée devrait être évident.

Mais alors, quelle est la meilleure façon ? pouvez-vous vous demander.

Cela semble incroyablement simpliste, parce que c’est aussi simple que cela.

  1. Livre sur Amazon

    Réduisez la quantité de fonctionnalités sur lesquelles l’équipe travaille en parallèle au minimum absolu. Cela minimise le rayon de l’explosion.

  2.  Au lieu d’avoir des gens en parallèle de multiples sujets, laissez les gens « inefficaces », « peu qualifiés » prendre des parties plus faciles du travail pour améliorer leur capacité. Cela réduit l’impact des événements à faible probabilité et donne à chacun de l’air pour respirer.
  3.  Donnez du mou dans les sprints. La résilience acquise peut absorber l’impact. Elle réduit également le besoin d’estimations gonflées, contre la loi de Parkinson et le défaut des moyennes. Elle donne également aux gens de l’air pour respirer.
  4. Tirez : Soyez d’accord sur l’approche Pull-Forward. Lorsque l’équipe se sent sous chargée, elle peut toujours ramener les sujets futurs dans ces temps d’inactivité. Personne ne se plaint quand un sujet est fini à l’avance, tout le monde se plaint quand quelque chose arrive en retard. Le Pull-Forward n’a pas d’effets de répercussions en chaine ou de conséquences chaotiques.

Ok, trop de mots, alors pour faire court

  1. Séquencez.
  2. Donnez du mou.
  3. Tirez.
Tous les problèmes mentionnés dans cet article sont alors résolus.
Visitez le site de notre partenaire Virage Group

7 questions pour déterminer si être un Scrum Master vous convient ou pourrait vous convenir

Peut-être envisagez-vous de poursuivre une carrière en tant que Scrum Master. Ou peut-être ce rôle vous a-t-il récemment été assigné  et vous vous demandez si être un Scrum Master est bon pour vous.

7 Questions to Determine if Being a Scrum Master Is Right for You

https://www.mountaingoatsoftware.com/blog/7-questions-to-determine-if-being-a-scrum-master-is-right-for-you par Mike Cohn

Il y a beaucoup de bonnes raisons de devenir un Scrum Master ; l’emploi est très demandé et bien rémunéré. Mais la raison la plus importante, peut-être la seule, de devenir Scrum Master est que c’est le bon job pour vos compétences, votre personnalité et vos centres d’intérêt.

Après tout, je voudrais peut-être devenir un chanteur de K-pop parce que cela paie bien et qu’on en demande, mais il y aurait plein de choses qui me retiendraient de faire une carrière en tête des charts de pop musique.

Voici sept questions que vous pouvez vous poser pour voir si vous êtes plus adapté à une carrière de Scrum Master que je ne le suis à une carrière d’idole des adolescents.

1. Aimez-vous aider les autres ?

Les Scrum Masters doivent aimer aider les autres. Cela ne peut pas être quelque chose qu’un Scrum Master fait à contrecœur. Je pense qu’aider peut être particulièrement difficile si le Scrum Master est dans un double rôle et qu’on s’attend à ce qu’il contribue également en tant que programmeur, testeur, concepteur ou similaire. Quelqu’un dans ce rôle commence à travailler chaque matin en pensant : « Humm, devrais-je faire tout ce que je suis entré dans cette industrie pour réaliser ? Ou devrais-je résoudre les problèmes des autres ? ».

Même avec de bonnes intentions, il est difficile pour beaucoup d’entre nous de vouloir éliminer les obstacles et résoudre les problèmes de quelqu’un d’autre plutôt que de progresser dans nos tâches. Pourtant, c’est exactement ce que fera un excellent Scrum Master.

2. Avez-vous besoin d’être sous les projecteurs ?

Je compare parfois un Scrum Master à un caddy de golf. Un bon caddy peut être essentiel au succès d’un golfeur. Mais les caddies ne sont pas là pour leur propre gloire. Les grands caddies font tout ce qu’ils peuvent pour aider leurs golfeurs à donner une bonne image plutôt que de chercher à faire eux-mêmes bonne figure.

Les Scrum Masters agissent à peu près de la même manière. Par exemple, lors d’une revue dont l’équipe a de quoi être fière, un grand Scrum Master se met en arrière-plan pendant que l’équipe reçoit les éloges.

3. Savez-vous bien écouter ?

Nous savons tous qu’un Scrum Master aide à éliminer les obstacles à la progression et à la productivité d’une équipe. Cela signifie souvent écouter, poser des questions de clarification, puis résoudre le problème. Mais d’autres fois, cela signifie simplement écouter : laisser un membre de l’équipe se plaindre de quelque chose.

Les bons Scrum Masters savent quand passer à l’action et quand écouter avec sympathie.

J’ai déjà coaché une très grande organisation dans sa transition vers l’agilité. Une partie de ce travail impliquait l’embauche et l’établissement de contrats avec des Scrum Masters expérimentés pour aider ceux qui, au sein de l’entreprise, occupaient ce poste.

Pat était l’un des Scrum Masters expérimentés que nous avions embauchés. Quelques mois après l’avoir embauché, le vice-président en charge de la transition m’a demandé si Pat était bon. J’ai répondu avec confiance que Pat faisait un excellent travail.

J’ai demandé au vice-président pourquoi il était curieux à propos de Pat. Il a dit que c’était parce que Pat ne parlait pas beaucoup dans les réunions. J’ai dû souligner que nous ne payions pas Pat au mot prononcé et que lorsqu’il disait quelque chose, c’était souvent brillant.

4. Pouvez-vous influencer sans autorité (hiérarchique) ?

Influencer sans autorité hiérarchique est l’une des leçons les plus difficiles à maîtriser pour de nombreux Scrum Masters. Je trouve cela particulièrement vrai pour ceux qui deviennent Scrum Master après des rôles porteurs d’autorité, tels que chef de projet et leader technique.

Bien que ce soit difficile à apprendre, influencer sans autorité est une compétence importante pour tous les bons Scrum Masters. Si vous aimez mener de cette façon, comptez cela comme un point en faveur d’une carrière en tant que Scrum Master.

D’un autre côté, si vous préférez dire : « Faites-le simplement parce que je vous le dit », n’excluez pas de devenir un Scrum Master. Dans mes premiers rôles de leadership, c’était mon style infortuné et mal choisi. Vous pouvez le surmonter.

5. Êtes-vous à l’aise avec l’incertitude ?

Relisez ce billet sur VUCA

Les équipes Scrum existent vivent dans l’incertitude. Le product backlog est incomplet.  L’architecture émerge avec le temps.  Les équipes apprennent à accepter l’incertitude.

Pour les dirigeants, cependant, c’est souvent inconfortable. Cela nécessite de faire confiance à l’équipe et souvent d’accorder plus confiance aux membres de l’équipe que dans le passé pré-agile.

Un bon Scrum Master n’a pas à être enthousiasmé par l’incertitude, mais doit y être suffisamment à l’aise pour y vivre. Si vous êtes du genre à vouloir secrètement éliminer toute incertitude, vous serez frustré en tant que Scrum Master ou vous rendrez votre équipe folle à poursuivre un objectif impossible.

6. Pouvez-vous bien manager les conflits ?

Les équipes agiles sont utilisées pour relever les défis les plus difficiles d’une organisation, c’est-à-dire les projets qui ne réussiront pas autrement. Ajoutez à cela les fortes personnalités que l’on retrouve dans de nombreuses équipes de développement et il y aura des conflits.

Au minimum, les membres de l’équipe différeront sur la façon de résoudre les problèmes. Plus fondamentalement, vous devrez peut-être faire face à des conflits de personnalité entre les membres de l’équipe ou à des demandes irréalistes de la part des parties prenantes.

Vous n’avez pas besoin d’aimer les conflits, la plupart des gens ne les aiment pas. Mais pour servir votre équipe, vous devrez vous en occuper.

7. Êtes-vous assez technique ?

Pour être un excellent Scrum Master, vous devez savoir quelque chose sur le travail effectué par l’équipe. Vous n’avez pas nécessairement besoin d’être capable de faire l’un de leurs jobs ni de l’avoir fait dans le passé.

Vous devez en savoir assez pour parler couramment leur langue et faire preuve d’empathie pour les défis que présente leur travail.

Si vous n’avez pas une compréhension approfondie du travail pour avoir fait le job d’un membre de l’équipe auparavant, poser de bonnes questions est un excellent substitut.

Découvrez les types de questions qui aident votre équipe à résoudre les problèmes. Si le fait de négliger un certain type de travail leur a brûlé les doigts dans le passé, posez-leur des questions à ce sujet lorsqu’ils semblent l’avoir oublié. Vous pourriez demander, par exemple, « Y a-t-il des implications pour la base de données ? » si des modifications apportées à la base de données avaient été auparavant négligées.

Vous n’avez pas besoin d’être technique, peu importe ce que cela peut signifier pour vos livrables. Mais vous devez être capable de discuter intelligemment du progrès et des problèmes avec l’équipe.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Qu’en pensez-vous ?

Que pensez-vous de ces sept questions ?

Y aurait-il une autre question que vous poseriez avant de décider qu’une carrière en tant que Scrum Master est un bon choix pour une personne ?

S’il vous plaît partagez vos idées dans les commentaires.

Une série de vidéos introductives gratuites sur Scrum !

Voici une série de vidéos courtes qui peuvent vous être utiles pour répondre aux questions de certaines de vos parties prenantes sur Scrum et Agile.

Dans la première de ces 18 brèves vidéos, une formateur professionnel, Ryan Brook, décompose l’approche pas à pas et présente cette série de vidéos.

La playlist sur Scrum.org s’appelle Scrum Tapas

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Avec Scrum, quand un sprint est-il terminé ?

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé.

In Scrum, when is a sprint over?

https://www.extremeuncertainty.com/in-scrum-when-is-a-sprint-over/ par Leon Tranter

Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Qu’est-ce qu’un sprint ?

Un sprint est l’unité de temps fondamentale dans Scrum. Il s’agit d’une timebox (une durée spécifique et forcée) pendant laquelle une équipe Scrum tente de créer un ou plusieurs incréments de produit. Tous les événements Scrum (Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective) se déroulent au sein d’un sprint.

Il n’y a pas d’activité en dehors du sprint.

Une fois qu’un sprint se termine, le sprint suivant commence immédiatement et le cycle de sprint recommence. Il n’y a pas de sprints spéciaux comme « sprint zéro », ou « sprint de consolidation » ou « sprint de release ». A chaque sprint, l’équipe est destinée à déplacer certains éléments du backlog produit vers Done (Terminé) et à livrer un incrément de produit.

Et surtout, un sprint est strictement limité dans le temps, généralement deux semaines, bien qu’il puisse durer jusqu’à un mois.

Pourquoi est-il timeboxé ?

La limite de temps de sprint est très importante. Les équipes doivent accepter la timebox et la respecter, c’est-à-dire mettre fin au sprint et commencer un nouveau sprint une fois la timebox terminée.

Il est parfois tentant pour une équipe de laisser un sprint « traîner » un ou deux jours de plus, pour essayer de finaliser certains éléments, mais cela va à l’encontre de l’essentiel !

Si une équipe commence à faire cela, elle peut continuer à le faire, et le faire de plus en plus. Cela remonte à l’époque des méthodes prédictives dites en cascades, où les livraisons sont repoussées toujours plus tard car les équipes veulent mettre tout le contenu de leur périmètre fonctionnel dans une unique livraison ou release. Avant que vous ne vous en rendiez compte, vous pouvez revenir à une release tous les 6 mois !

La timebox stricte garantit qu’il existe un modèle régulier simple, une cadence, où une équipe s’arrête et inspecte son dernier livrable (dans la revue de sprint) et l’équipe elle-même (dans la rétrospective de sprint).

Quand un sprint est-il terminé ?

La réponse courte et simple est qu’un sprint est terminé lorsque la timebox de sprint se termine ! (Quelle que soit la cadence choisie par l’équipe pour les sprints, c’est-à-dire deux semaines, un mois, une semaine, etc.).

Une équipe peut choisir de changer la durée de ses sprints (c’est-à-dire que l’équipe peut choisir de passer de sprints de deux semaines à des sprints d’une semaine ou vice versa), mais ce n’est pas un changement ponctuel. Cette nouvelle timebox devient la timebox standard pour tous les sprints à partir de là (jusqu’à la prochaine fois que l’équipe voudra changer la timebox).

Un sprint n’est pas terminé lorsqu’un incrément de produit est créé ou livré. L’équipe continue simplement à travailler sur d’autres éléments de l’arriéré de produit ou product backlog. Elle peut même produire un autre incrément de produit dans ce sprinte (Il n’y a rien dans Scrum qui dit que vous ne puissiez livrer qu’un seul incrément de produit par sprint !).

Un sprint n’est pas non plus terminé lorsque l’objectif de sprint a été atteint. Dans la situation heureuse où il reste encore un peu de temps dans le sprint, l’équipe peut choisir d’effectuer le travail qu’elle veut dans le temps restant. Il peut s’agir de travailler sur d’autres éléments du product backlog, rembourser une dette technique, examiner certains éléments d’amélioration continue, etc.

L’important est que la timebox régulière soit respectée.

De quelles autres façons un sprint peut-il se terminer ?

Il n’y a que deux autres façons dont un sprint peut se terminer.

La première est si le Product Owner décide d’annuler le sprint en cours. C’est un cas extrême qui ne devrait arriver que très rarement. La seule raison donnée pour cela dans le Guide Scrum est que l’objectif de sprint est devenu obsolète. Cela peut se produire pour diverses raisons, mais elles ne devraient pas arriver souvent. Il est presque toujours plus bénéfique pour l’équipe de continuer et de terminer le travail qu’elle a prévu pour ce sprint.

Il n’y a pas d’autres moyens mentionnés dans le Guide Scrum. Le seul auquel je puisse penser est un exemple encore plus extrême et, espérons-le, rare. C’est si le produit ou l’équipe elle-même cesse d’exister. Si une équipe est au milieu d’un sprint et que, pour une raison quelconque, l’organisation décide d’arrêter tout travail sur le produit ou d’arrêter de financer l’équipe, alors évidemment ce sprint se termine.

L’organisation peut vouloir financer l’équipe pour le reste du sprint, mais si le produit lui-même est obsolète ou n’est plus financé, elle peut vouloir économiser de l’argent en ne terminant pas le travail en cours dans le sprint.

7 péchés des revues de projet que vous pouvez éviter !

Bien qu’il y ait probablement plus que ces 7 manières de gaspiller de précieuses revues de projet, apprenez pour commencer à reconnaitre et éviter celles-ci.

Seven Sins of Reviews

https://kbondale.wordpress.com/2021/04/18/seven-sins-of-reviews/ par Kiron Bondale

Votre équipe suit un framework Agile spécifique ou a adopté une approche mixte dans ses pratiques, un principe d’Agile est l’utilisation de courtes boucles de rétroaction pour soutenir l’inspection et l’adaptation.

Que votre équipe fixe une cadence régulière pour les évaluations externes des livrables ou qu’elles soient effectuées dans la foulée, il est important d’obtenir des retours exploitables. Mais mener une revue n’est pas seulement une question de rassembler les gens.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Bien qu’il y ait probablement plus que ces façons de gâcher les revues, en voici sept dont j’ai été témoin.

#1 – Le seul participant est un Product Owner (ou un rôle similaire représentant la voix du client).

Bien que nous nous attendions à ce que les Product Owners soient bien informés, leurs retours sont à un pas de distance de celui des véritables parties prenantes externes. Le Product Owner peut juger si le produit répond aux besoins, mais l’équipe perd l’avantage de poser des questions comme « Quelles nouvelles idées cette fonctionnalité vous donne-t-elle pour le produit ? » ou « Comment pourrions-nous faire en sorte que cette fonctionnalité ajoute plus de valeur pour vous ? ». De plus, les retours du Product Owner devraient (idéalement) être reçus par l’équipe quotidiennement plutôt que d’organiser un événement spécial uniquement à cette fin.

Visitez le site de notre partenaire Virage Group

#2 – Trop en mettre dans une seule revue et ne pas laisser suffisamment de temps aux parties prenantes pour digérer ce qu’elles ont vu.

Au fur et à mesure que les équipes s’améliorent dans la livraison, elles peuvent être en mesure d’effectuer plus de travail sur un même laps de temps.

ne chargez pas trop les revues

Dans ce cas, la fréquence des examens externes devrait être rapprochée afin que le contenu examiné soit moins important et que le contenu couvert soit organisé par ordre de priorité.

#3 – Organiser une démonstration plutôt qu’un échange bidirectionnel.

Si le seul but d’une revue est de montrer ce que l’équipe a accompli, cela pourrait être enregistré et envoyé aux parties prenantes pour qu’elles les regardent à leur guise.

La vraie valeur d’un examen réside dans la richesse des discussions entre les membres de l’équipe et les parties prenantes et entre les différentes parties prenantes en fonction de ce qu’elles voient.

L’utilisation de questions puissantes et ouvertes est un moyen de s’assurer que le partage des connaissances ne se fait pas dans une seule direction.

#4 – Avoir les mauvaises personnes dans la revue.

Il est presque aussi mauvais d’avoir les mauvais intervenants externes dans la salle que de n’en avoir aucun. Si des personas sont utilisés pour faciliter la découverte des exigences, il devrait y avoir au moins un représentant pour chaque persona si le contenu de ce qui est examiné les affecte.

Et parce qu’une revue est une séance de travail et pas seulement un forum de partage d’informations, nous ne voulons pas non plus avoir trop de monde dans la salle.

#5 – Prendre des engagements pendant la revue.

ne prenez pas d’engagements trop rapidement

Il peut être tentant pour un membre de l’équipe ou le Product Owner d’essayer de s’attirer les faveurs d’une partie prenante externe puissante en s’engageant à un changement spécifique du livrable ou sur une date de livraison, mais ce n’est pas le bon forum pour cela.

Le contenu et les dates souhaités peuvent être notés, mais le Product Owner et l’équipe doivent prendre le temps de comprendre les impacts de ces changements.

#6 – Critique ouverte du travail de l’équipe.

Il est naturel qu’une partie prenante externe soit frustrée si ses attentes n’ont pas été satisfaites pour le contenu examiné. Ces critiques sont essentielles pour aider l’équipe à s’améliorer au fil du temps.

Mais si cette critique est fournie de manière abusive, le moral et la productivité de l’équipe en prendront un coup.

#7 – Ne pas prendre suffisamment de temps pour analyser ce qui a été appris lors d’une revue.

Si nous mobilisons un temps précieux pour les parties prenantes, il nous incombe de bien utiliser leurs retours. Il peut être pratique d’organiser une rétrospective ou un artefact similaire immédiatement après une revue, mais cela peut ne pas laisser le temps nécessaire à l’équipe et au Product Owner pour digérer correctement les retours qu’ils ont reçus.

Des critiques bien managées sont un ingrédient clé de la construction du bon livrable pour nos clients, donc éviter ces sept péchés contribuera grandement à tirer une valeur réelle de ces rencontres critiques.

Amplifiez les succès et les réussites de vos projets Agiles

Les sociétés n’augmentent pas le succès d’Agile ou de Scrum, elles en amplifient le succès.

Scaling Success

https://agile-scrum.com/2021/02/05/scaling-success/ par Zuzi Sochova

Dans notre voyage vers Agile, nous nous demandons souvent par où commencer, quels pratiques, outils et processus devrions-nous nous utiliser ?

Ce que j’ai appris pendant mon propre voyage est que nous n’avons pas besoin d’une « autre » méthode. Aucune de celles-ci n’est une solution miraculeuse de toute façon. Elles sont toutes formidables pour entamer comment changer la façon dont vous travaillez et les mentalités.

Mais la partie la plus importante de votre voyage est le succès.

  • Pouvez-vous partager une histoire de réussite ?
  • Pouvez-vous utiliser vos propres mots pour décrire comment votre propre environnement a changé et montrer l’impact de ces nouvelles manières différentes de travailler ?

Si oui, les gens vont s’y mettre et essayer d’atteindre un impact similaire.

Les transformations agiles les plus réussies que j’ai vues ont commencé exactement comme cela. Avec une petite équipe expérimentant de nouvelles pratiques et partageant l’impact observé avec d’autres. Selon le point de départ, ces équipes partagent des histoires de réussite différentes et diverses, comme. 5 fois moins de bogues reportés par des clients, 3 fois plus de valeur livrée sur une période donnée (ce n’est pas la même chose que plus de fonctionnalité, mais souvent le contraire), un délai de mise sur le marché significativement plus rapide, une motivation plus élevée et un meilleur niveau d’engagement, plus d’innovations qui aboutissent à une satisfaction client meilleure… l’impact varie en fonction de l’environnement.

Pour nous, il y a quelques années c’était plus de flexibilité, apprendre plus rapidement et une meilleure satisfaction client.

Partager sur les succès n’a rien de nouveau dans le management du changement. C’est l’une 8 étapes dans Conduire le changement: Feuille de route en 8 étapes de John Kotter que pour quelque raison on ne connait toujours pas assez largement dans la communauté agile, donc j’ai pensé à vous les rappeler ici .

#1 – Créez le sens de l’urgence

Sur Amazon

À moins que vous ne sachiez pourquoi vous changez la façon dont vous travaillez (pour être plus agiles, Scrum ou Kanban), ne le faites pas. Ni Agile, ni Scrum, ni Kanban ne sont votre but. Ce sont juste des ‘béquilles’ vous aidant dans votre voyage vers la réussite. Vous devez avoir un objectif plus élevé défini qui sera plus fort que les objectifs individuels et unifiera donc les personnes.

#2 – Construisez une coalition de direction

Vous ne pouvez jamais changer l’organisation si vous êtes seul. Vous devez trouver des partisans (des enthousiastes agiles dans votre cas) qui créeront une équipe qui vous aidera à changer le système. Ainsi, au minimum deux personnes complémentaires qui sont de vrais aficionados agiles, car trois personnes constituent l’équipe la plus petite. Les autres vous rejoindrons en observant des résultats.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

#3 – Formez une vision et des initiatives stratégiques

Parfois avoir d’un but n’est pas suffisant car les gens ne voient pas de manière d’y arriver et le changement dans sa globalité est trop abstrait. C’est un espace où les structures, les méthodes et les pratiques sont utiles.

#4 – Enrôlez une armée de volontaires

Recrutez des enthousiastes.

Finalement, c’est le moment de le rendre plus grand. Faites-en un mouvement, pas juste un autre projet. Faites-y adhérer un plus grand groupe. Faites-les s’impliquer. De nouveau, si vous sautez certaines des étapes précédentes, cela ne pourra pas grandir.

#5 – Permettez l’action en faisant tomber les barrières

Libérez les énergies.

Maintenant, une fois que vous avez l’énergie de votre côté, vous devez l’aider et éliminer les barrières (hiérarchie, silos, positions détaillées, KPIs individuel, …), sinon, tout l’enthousiasme initial va s’évaporer avant que vous ne le compreniez.

#6 – Générez des victoires dans le court terme

Célébrez toutes les avancées.

Générez du succès rapidement et souvent et rendez-le visible à toutes et tous. Partagez des histoires d’améliorations, célébrez même de petits pas de progrès. Le succès est un moteur puissant pour le changement. Accélérez, multipliez les succès. Sans cela, tout changement mourra.

#7 – Soutenez l’accélération

pousser les gens dans la bonne direction
Continuez tout le temps de pousser.

Vous pouvez la célébrer, mais vous ne pouvez pas arrêter de pousser après la première victoire, ne soyez pas trop satisfait. Il y a toujours une meilleure manière. Trouvez un autre défi, découvrez une meilleure façon de travailler jusqu’à ce que la vision de la nouvelle façon de travailler définie par le but original devienne vraie.

#8 – Institutionnalisez le changement

Utilisez ce levier pour accélérer.

Finalement en créant des liens entre la nouvelle façon de travailler et le succès vous tenez le levier du changement.

Ces liens sont la glu qui empêche l’environnement de retomber en arrière dans l’ancienne façon de travailler.

Agile est un changement majeur et sans le conduire comme un changement vous aurez beaucoup de mal à réussir.

N’oubliez donc pas de définir à quoi ressemble le succès, célébrez-le et rendez-le meilleur au fil du temps.

buisness presente / cadeau d'affaire

Ces nombreuses ressources GRATUITES seront utiles à toutes et tous les managers de projets.

Bonjour, en cette période de cadeaux, j’ai mis à jour la page « ressources gratuites » de ce blog qui rassemble de nombreux pointeurs vers des outils, documents, rapports, référentiels… qui sauront vous être utiles toute l’année !

Ces nombreux documents GRATUITS seront utiles aux managers de projets

Project Management Institute

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
  1. PMBOK et Agile Practice guide
  2. PMI Pulse of the profession report
  3. PMI FRANCE – Les “LIVRES BLANCS”
  4. PMI met le focus sur le Portfolio Management
  5. Toutes les présentations sur le management de projet du PMI Montréal
  6. Les résumés de recherches des ressources académiques du PMI®
  7. The PMI Lexicon of Project Management
  8. Project Management Skills for Life® maintenant disponible en Français !
  9. PMI Report: Capturing the Value of Project Management through Knowledge Transfer
  10. PMI® Thought Leadership Series on Talent Management
  11. Project management Docs: free templates per PMBOK process groups
  12. Le dernier rapport « Earning Power: Project Management Salary Survey » est disponible. Etes-vous rémunéré à votre juste valeur ?
  13. les 10 principes directeurs de « Brightline » ?
  14. Retrouvez tous les webinaires (gratuits) de la Communauté Francophone du PMI !
  15. Pulse of the Profession® 2021: Beyond Agility – Au-delà de l’agilité. Travaillez-vous dans une organisation « gymnaste » ?
  16. La PMI Educational Foundation, ce sont aussi des ressources gratuites pour apprendre le management de projets dont certaines en français

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Prince2

QRP est partenaire de DantotsuPM, visitez leur site et leur blog
  1. PRINCE2 Process Flow Diagram est une représentation graphique (en anglais) de tous les processus PRINCE2
  2. Prince2 on Wikipedia
  3. Prince2 Wiki
  4. La version 2017 de Prince2
  5. La version originale de 2007 des « GUIDELINES FOR MANAGING PROJECTS » by UK Department for Business, Enterprise and Regulatory Reform
  6. The PRINCE2 Processes e-book by KnowledgeTrain

Agile

  1. 144 Termes Agile
  2. Livre blanc QRP: Pourquoi choisir une méthode Agile
  3. Scrum Alliance Report 2015
  4. the Nexus Framework
  5. 2021 Gartner Market Guide for Enterprise Agile Frameworks
CertYou est partenaire de DantotsuPM
CertYou est partenaire de DantotsuPM

Divers

  1. le guide gratuit en anglais pour le PM dans les organisations non gouvernementales PM4NGOS
  2. Livre blanc CSP sur Neurosciences et formations
  3. Comparison of project management software

  4. Job Growth and Talent Gap in PM report
  5. Sustainability Manifesto for Projects
  6. Free stuff from « A Girl’s Guide to Project Management » !
  7. A Business Analysis for Practitioners: A Practice Guide
  8. si votre projet professionnel implique d’aller vivre à l’étranger, voici 2 pointeurs utiles…
  9. Matrice d’Affectation des Ressources (RAM ou RACI)
  10. le standard P5 pour le développement durable
  11. les bulletins du Risk Doctor 
  12. 25 Useful Brainstorming Techniques
  13. une BD « Management Par Projet » de Net’sfive !
  14. Formation « Introduction to PM² » sur European Union Academy
  15. Si la Business Analysis vous intéresse, découvrez la chaine YouTube de IIBA® Geneva
  16. « The state of Project Management 2021 » : Plus de la moitié des projets ne sont pas menés par des managers de projets professionnels !
CSP est partenaire de DantotsuPM, Découvrez tous leurs ateliers

Le Manager dans les Daily Scrum : Quelles sont les choses à ne pas faire en dehors d’éviter totalement sa présence.

Un des anti-modèles les plus courants aux Réunions Daily Scrum est la participation active des managers.

Back To Basics: Managers and Daily Scrum Meetings

https://tcagley.wordpress.com/2020/09/24/back-to-basics-managers-and-daily-scrum-meetings/ par Tom Cagley

Si vous n’allez pas plus loin dans la lecture de ce billet, je recommande aux managers de rester éloignés du Daily Scrum. Même s’il n’est pas interdit aux managers de venir au Daily Scrum ni que ce soit intrinsèquement mauvais en soi il y a toutes sortes de fréquents résultats négatifs.

Voici 4 des pires attitudes

1 – Mettre l’équipe sur le grill

Transformer le Daily Scrum en une réunion de statut où la déviation par rapport plan du leader est mise en évidence et même punie.

Ce comportement rend pour le moins difficile de produire une mentalité agile.

2 – Distribuer du Travail

Les leaders qui utilisent le Daily Scrum pour assigner du travail empêchent les équipes d’apprendre à s’auto-organiser et élimine l’objectif de planning d’équipe de la réunion. J’ai demandé à un manager pourquoi il distribuait le travail dans le Daily Scrum, sa réponse fut « je suis responsable de m’assurer que chacun est occupé ».

Distribuer du travail pendant cette rencontre signifie que le manager doit avoir une compréhension détaillée de toutes les histoires et tâches nécessaires pour faire quelque chose, les entraînant vers un micromanagement du travail. Le Daily Scrum est un événement dans l’équipe projet Agile dont l’objectif va à l’encontre de cette approche.

CSP est partenaire de DantotsuPM, Découvrez tous leurs ateliers

3 – Le « paraître »

La perception qu’a de vous votre manager (ou la personne renouvelant votre contrat) est importante pour votre carrière. C’est une tendance humaine de base que de vous assurer que vous paraissez bons aux yeux du patron, même parfois aux dépends de vos pairs. Ce comportement n’amène pas à partager les problèmes, demander de l’aide, ni à re-planifier.

4 – Désintérêt

J’ai récemment observé un manager qui venait chaque jour au Daily Scrum et passait tout son temps à faire des choses sur son téléphone. Quand s’adressait à lui, il semblait choqué que quelqu’un lui parle. Après le quatrième jour, j’ai pu coincer la personne pour une discussion. Sa formation Agile indiquait qu’il devait aller au Daily Scrum, mais il ne souhaitait pas être là. Il était passif-agressif. Il n’est plus revenu après cette rencontre et chacun s’est senti plus à l’aise. En tant que manager, si vous allez aller au Daily Scrum (ne le faites pas s’il vous plaît) écoutez et prêtez l’attention.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

En règle générale, les managers devraient trouver une raison d’être n’importe où plutôt qu’au Daily Scrum.  Comme avec toutes les règles, il y a des exceptions. Par exemple, le scénario de manager-joueur, où un membre de l’équipe est aussi le manager. J’ai entendu des scénarios où la présence d’un manager était utile, mais j’ai entendu ces histoires de managers pas de leurs équipes.

CERTyou, spécialiste des formations certifiantes et partenaire fidèle de DantotsuPM

CERTyou : PMP® et PgMP® du PMI® mais aussi cybersécurité, ITIL, Business Analysis et bien d’autres formations certifiantes !

Une qualification très exigeante.
Olivier Boisne, dirigeant de CERTyou, nous rappelle que depuis 2020, CERTyou est reconnu par le PMI Monde comme PREMIUM AUTHORIZED TRAINING PARTNER.
CertYou est même leader en France sur les formations PMP : 117 avis clients

Sont toujours inclus dans nos formations PMP

  • Le simulateur,
  • le support de formation officiel PMI,
  • le PMBOK papier,
  • l’examen PMP,
  • l’adhésion PMI Monde et
  • l’adhésion PMI France.
Il n’y a pas de frais supplémentaires à prévoir pour passer l’examen PMP.
CertYou réalise également des formations PfMP et PgMP, qu’ils sont les seuls à les faire en France. L’objectif est d’acquérir de nouveaux concepts, méthodes et techniques pour améliorer ses compétences en management de programme et projet, sur la base du standard PMI®. Le but est de préparer le participant à la certification PgMP®.
En cette année 2022 et pour 2023, CertYou a reçu de fortes demandes en management/gestion de la cybersécurité. Les certifications demandées sont CISSP, CISA, CISM, ISO 27005, ISO 27001.

Un peu de business analyse avec CBAP aussi !

Un très gros avantage offert par CERTyou est le suivi après la formation initiale.

Inclus ! Votre apprentissage avec CERTyou continue même après votre formation PgMP : Program Management Professional PMI avec le Coaching Après-Cours.

Témoignage client sur une formation PMP®.

“PMI,” the PMI logo, “PGMP”, “PMP” and “Project Management Institute” are registered marks of Project Management Institute, Inc.


Voici les formations les plus suivies chez CERTyou

 

Choses à faire avant la réunion de planification du sprint

Découvrez ce que vous devriez faire avant même le début de votre réunion de planification de sprint afin de faire du prochain sprint un succès.

https://blog.gurock.com/sprint-planning/ par Nishi Grover Garg

Les équipes Scrum se réunissent pour décider des éléments de travail de leur prochain sprint lors de la réunion de planification du sprint. Mais est-ce le début de la conversation pour le sprint à venir, ou y a-t-il des choses à faire avant ?

Priorisez le Product Backlog, l’arriéré de produit

La première et la plus importante considération est d’avoir un product backlog vivant qui est à jour et hiérarchisé pour suivre l’évolution des besoins de l’entreprise. Le propriétaire de produit doit avoir un œil constant sur l’ajout, la suppression, la modification et la mise à jour d’éléments dans le product backlog. Lorsque le temps vient de planifier le sprint suivant, le chef de produit doit apporter à la table une liste des éléments de valeurs les plus élevées que l’équipe puisse choisir.

Détaillez les fonctionnalités

Étant donné que la plupart des exigences agiles sont courtes, soit sous la forme d’histoires utilisateur (User Stories) ou simplement de phrases listant les fonctionnalités nécessaires, elles nécessitent d’être détaillées pour pouvoir être implémentées. Le propriétaire de produit doit passer du temps à rechercher chacune des fonctionnalités et à essayer de présenter en termes simples le besoin réel que chacune exprime. Utilisez des listes à puces ou des phrases simples, pour expliquer la fonctionnalité en détail. Nous voyons cela se produire principalement pendant ou après la réunion de planification du sprint, mais si des exigences sont connues avant la réunion, le propriétaire de produit peut avoir une longueur d’avance.

Décidez d’une définition de done

Au cours d’une réunion de planification de sprint, l’équipe choisit généralement ce qu’elle fera et livrera à la fin de cette itération de sprint. Il est impératif que les membres de l’équipe connaissent et conviennent d’une définition de done pour chaque histoire utilisateur ainsi que chaque tâche de chacune. Qu’il s’agisse d’une tâche de développement, d’une tâche de conception ou d’exécution de test ou d’une tâche de revue de livrable, tout le monde doit s’accorder sur une compréhension commune de ce que signifie « done » afin d’assurer une livraison fluide et aucun conflit à la fin du sprint.

Soignez les user stories

Chaque histoire utilisateur qui est mise en avant pour la planification du sprint doit être soignée, développée et détaillée avec les connaissances et les commentaires de l’équipe entière.

Lorsque les testeurs, les développeurs et le propriétaire de produit s’assoient ensemble et discutent d’une nouvelle fonctionnalité, de nombreuses nouvelles questions peuvent survenir de la part de l’équipe. Les questions portent souvent sur l’intégration avec les fonctionnalités existantes, le comportement de la fonctionnalité dans des cas spécifiques ou la manière dont le comportement doit être adapté pour différents types d’utilisateurs. Les cas spéciaux font également partie des critères d’acceptation définis dans l’histoire utilisateur pour la rendre complète.

Quelles que soient les questions, il est préférable de les poser au plus tôt et d’y répondre avant de choisir l’histoire utilisateur. Fondamentalement, cela signifie qu’une conversation doit avoir lieu pour chaque user story, afin que l’équipe puisse se comprendre et décider des critères d’acceptations définis et agréés par tous.

Ces sessions de « toilettage d’histoires » doivent avoir lieu avant la réunion de planification du sprint afin que pendant la planification, l’équipe sache exactement ce qui est requis de cette fonctionnalité et puisse donner de meilleures estimations et story points en fonction de sa complexité.

Commencez par le design

De nombreuses histoires utilisateur ont besoin de storyboards visuels ou de maquettes de l’interface utilisateur, et dans ces situations, les concepteurs d’expérience utilisateur ou UX designers peuvent avoir besoin d’être impliqués. Ces histoires doivent être sélectionnées un sprint à l’avance et allouées d’abord aux UX designers, afin qu’ils puissent construire les maquettes ou les images d’écran prêtes avant que la fonctionnalité ne soit sélectionnée pour le développement dans le sprint suivant. Cette approche facilite la communication et évite les retards pendant le développement.

De même, certaines histoires utilisateur peuvent nécessiter une recherche sur une nouvelle approche, une nouvelle technologie ou un nouvel outil avant de commencer, ou il peut être nécessaire de créer un design d’architecture complet pour une certaine partie avant de se lancer dans sa mise en œuvre. Dans de tels cas, la tâche de conception ou de R&D doit être créée et démarrée dans un sprint précédent, puis allouée au développeur ou à l’architecte principal au sein de l’équipe pour préparer les designs et résultats de recherche pertinents. Ils peuvent ensuite partager ces informations avec l’équipe afin que tout le monde soit prêt à commencer à travailler sur la mise en œuvre dans le sprint suivant.

Un propriétaire de produit doit être constamment à l’affût des histoires utilisateur qui peuvent nécessiter un travail de conception ou de recherche avant de les commencer, et avoir ces user stories distribuées aux personnes concernées avant le sprint pour s’assurer que la mise en œuvre sera fluide et que la livraison pourra avoir lieu à temps.

Nishi est une formatrice en entreprise, une passionnée agile et une testeuse dans l’âme ! Avec plus de 11 ans d’expérience dans l’industrie, elle travaille actuellement chez Sahi  Pro en tant qu’évangéliste et responsable des formations. Elle est passionnée par la formation, l’organisation d’événements et de rencontres pour une communauté de test, et a été conférencière lors de nombreux événements et conférences de test.

Consultez  son blog où elle écrit sur les derniers sujets dans les domaines Agile et Testing.

CertYou est partenaire de DantotsuPM

2021 Gartner Market Guide for Enterprise Agile Frameworks

Obtenez votre exemplaire gratuit dès aujourd’hui !

Le Project Management Institute a été reconnu comme fournisseur représentatif dans le Gartner Market Guide de 2021.

Obtenez votre exemplaire du rapport Gartner Market Guide for Enterprise Agile Frameworks 2021 pour en savoir plus sur le marché agile.

© 2021 Gartner, Inc. and/or its affiliates.

Vous pouvez utiliser ce Guide pour mieux comprendre quel est le statut des approches Agiles et identifier qui peut le mieux vous aider à vous former.

Lesquelles de ces approches Agiles s’harmoniseront le mieux avec vos plans futurs et votre situation actuelle ?
CertYou est partenaire de DantotsuPM

Que lisiez-vous en Juin 2021 sur le blog du management de projet DantotsuPM.com ?

Ces 3 billets qui retinrent l’attention de nombreuses et nombreux PMs et Agilistes.

7 choses qu’un leader ne devrait jamais faire dans ses courriers électroniques

Avant que vous ne répondiez à cette saga surchauffée de courriels, voici comment éviter certaines bévues dans l’étiquette entourant l’usage de la messagerie électronique qui seraient potentiellement embarrassantes ou dommageables.

QRP est partenaire de DantotsuPM

38 Biais Cognitifs et leurs impacts sur les managers de projets et leurs équipes

Avec les 27 déjà décrits en 2019-2020, vous voici équipés de davantage de connaissances sur 65 biais cognitifs.

FDF est partenaire de DantotsuPM

Un tour de SAFe en 5 minutes !

Cette vidéo explique les principes principaux de SAFe 5.0 en cinq minutes.

CertYou est partenaire de DantotsuPM

Le Manifeste Agile en chanson

Une parodie originale avec cette reprise du classique “Bohemian Rhapsody” de Freddy Mercury et Queen, entièrement réécrit à partir de zéro en studio avec les mots du guide Agile Product Management.

Rien de sérieux et quel beau travail d’équipe Agile !

CertYou est partenaire de DantotsuPM

La magie des Sprints de 1 jour !

Quelle devrait être la durée de vos sprints ? Généralement, 1 ou 2 semaines, avec une préférence vers le sprint plus court.

Mais ce n’est pas le sujet du jour. Je veux vous parler de la magie des sprints de 1 jour.

The Magic of 1-Day Sprints https://agileforall.com/the-magic-of-1-day-sprints/ par Richard Lawrence

J’ai remarqué que l’efficacité d’une équipe n’est pas fonction de combien de temps ses membres ont travaillé ensemble de façon agile. C’est plutôt fonction de combien de cycles ils ont réalisé ensemble. Combien de fois ils se sont regroupés, ont pris des engagements, ont réfléchi à comment les tenir et ensuite regardé rétrospectivement et adapté leur pratique. Autrement dit, pour une équipe Scrum, combien de sprints ils ont fait ensemble. En général, plus de sprints, plus d’enseignements.

Cela crée une opportunité unique que certains de mes clients veulent exploiter. Quand une équipe commence ou se regroupe, particulièrement après l’un de nos ateliers « Agile for Teams », il y a la nouvelle prise de conscience de soi-même, de l’enthousiasme et des idées à essayer. Pendant les deux semaines suivantes, vous pouvez les canaliser en un premier sprint fort… ou vous pouvez saisir l’occasion d’en faire dix.

Dix sprints de 1 jour vous permettent d’achever 10 cycles de travail et d’apprentissage ensemble, 10 fois plus rapidement qu’une équipe typique. Et cela vous force à identifier les compétences et pratiques critiques comme trouver de petites poches de valeur et collaborer ensemble sur quelque chose au lieu de juste de remettre son travail de l’un à l’autre en séquence, ignorant facilement les compétences et pratiques dans un sprint de 2 semaines.

Vous dépenserez plus de temps dans les cérémonies de sprint. Aussi, ne devriez-vous probablement pas les adopter pour toujours. Mais si vous ressemblez à mes clients, vous serez étonnés de constater combien vous aurez réalisé.

CertYou est partenaire de DantotsuPM

Alors, comment vous y prendre en pratique ?

Voici une journée 9h00-17h00 typique
  • 9:00-9:30 — Planifier la journée. Trouvez un, peut-être deux, incréments de valeur que vous pouvez achever ensemble aujourd’hui.
  • 9:30-12:00 — Réalisez des choses
  • 12:00-13:00 —Pause déjeuner
  • 13:00-13:15 — le Daily Scrum pour se coordonner sur les progrès du matin et prévoir l’après-midi
  • 13:15-16:30 — Réalisez plus de choses finies (en incluant le mûrissement d’items du backlog pour rendre la planification du lendemain plus facile)
  • 16:30-17:00 — Revoyez ce que vous avez fait et faites une rétrospective rapide de comment vous pourriez travailler différemment demain
  • 17:00 — Rentrez à la maison

Vous ne parvenez pas à avoir 8 heures en commun en raison d’autres engagements extra-professionnels d’autres membres d’équipe ?

Ne vous inquiétez pas, vous pouvez tout de même faire des sprints quotidiens. Le changement clé est de mettre la revue, retro et planification en séquence le matin ou l’après-midi quand vous êtes tous là. Puis, le temps à une extrémité ou l’autre de la journée de travail devient la partie sprint. 2vitez juste de travailler des heures supplémentaires car vous voulez parvenir à une réelle compréhension de ce que votre équipe peut accomplir en un jour de focus.

3 astuces pour ce travail

#1. Mettez-vous d’accord au départ que ce sera une expérience de deux semaines et non pas votre nouveau normal.

Travailler de cette façon est un changement intense pour la plupart des équipes. Savoir de ce sera limité dans le temps donne l’espace psychologique nécessaire pour vraiment essayer.

#2. Planifiez des choses plus petites que vous ne le pensez.

En réalité finir quelque chose de significatif en un seul jour est une partie clef de cette expérience. Il vaut mieux finir quelque chose de trop petit et terminer tôt que toujours quitter sur une chose partiellement faite. Et les compétences de découpage que vous développez seront de valeur à votre équipe sur le long terme.

#3. Bien que ce soit une expérience sur comment vous travaillez, faites attention que sur quoi vous travaillez est bien réel.

Vous en avez besoin que le quoi soit représentatif de votre travail normal pour en transférer facilement les enseignements. (Si, pour une certaine raison, vous ne pouvez pas le faire avec votre travail réel, le faire en style hackathon avec une innovation ou un projet caritatif peut aussi vous apprendre quelque chose. Ce mieux que rien, mais ce ne sera pas aussi instructif que 10 sprints d’1 jour de travail réel.)

Testez-le et donnez vos retours dans les commentaires !

Si vous préparez une certification #Scrum, attention à 5 différences introduites dans le guide en 2020 !

« Il m’a été donné de constater que certains organismes de certifications Framework Agile Scrum n’ont pas mis à jour certaines questions de certifications par rapport au guide Scrum 2020. Il appartient donc aux candidats de répondre en tenant compte du contexte de la question. » Zidane Zait

Zidane Zait

Zidane Zait, coach Agile et formateur Scrum, enseigne aux équipes l’agilité, l’Agile Framework Scrum et Agile MS Project. Son objectif est de faciliter le développement d’un esprit agile, la réalisation de solutions de valeur, la collaboration, l’auto-gestion des équipes, l’amélioration continue ainsi que l’engagement, la passion et l’enthousiasme envers ces approches.

5 changements entre le guide Scrum 2017 et le guide Scrum 2020 qui méritent d’être rappelés

  1. Guide téléchargeable gratuitement

    Dans le guide Scrum 2020, on trouve le rôle de « développeurs » alors que dans les guides précédents on utilise le rôle « d’équipe de développement »

  2. Introduction de l’Objectif de Produit dans le Guide Scrum 2020 pour permettre à la Scrum Team de se focaliser sur un objectif plus important.
  3. Les guides Scrum 2017 et précédents, utilisent le terme de autoorganisée, alors que le guide Scrum 2020 utilise le terme de Scrum Team autogérée.
  4. En plus des thèmes « Quoi » et « Comment » de la Sprint Planning, le Guide Scrum 2020 met l’accent sur un troisième thème « Pourquoi », faisant référence à l’Objectif de Sprint.
  5. Simplification globale du langage utilisé dans le guide Scrum 2020 pour atteindre un public plus large, gérant des projets hors du domaine informatique.
     

Pour rappel, relisez ce billet sur « Le guide Scrum 2020 : De nombreux articles et commentaires d’experts francophones »

CertYou est partenaire de DantotsuPM

Un peu de Scrum en musique pour terminer ce billet.


Zidane Zait ajoute ces autres changements à prendre en compte

Changement, évolution et améliorations apportées au guide SCRUM 2020:

En plus, des 5 changements et améliorations repris dans cet article, on peut les compléter par ce qui suit :

• Le guide 2020 définit le mot produit, comme un produit physique, un service, ou quelque chose de plus abstrait.

• Le terme « développeur », est un terme générique, et ne concerne pas uniquement le domaine informatique, on peut le remplacer par « réalisateur » en dehors du développement logiciel.

Suppression des trois questions de la mêlée quotidienne et laisser la liberté aux développeurs d’inspecter la progression vers l’Objectif de Sprint. Les questions supprimées sont :
1. Qu’est-ce que j’ai fait hier ?
2. Qu’est-ce que je vais faire aujourd’hui ?
3. Y a-t-il des problèmes rencontrés ?

• La version 2020 ne parle plus de vision de produit, mais plutôt d’objectif de produit.

• Le Product Owner est redevable de définir et communiquer explicitement l’objectif du produit.

• Les développeurs sont redevables envers la qualité du produit en adhérant à la définition de terminé

• Le Scrum Master est redevable pour être le facilitateur de l’équipe et garantir son efficacité.

Plusieurs incréments peuvent être créés pendant un sprint au lieu d’un seul dans les versions précédentes.

Trop de règles rendent l’agilité impossible

Combien de règles devez-vous suivre ?

Too many rules makes agility impossible

https://hennyportman.wordpress.com/2020/04/01/too-many-rules-makes-agility-impossible/ par Henny Portman

Un des principes du Manifeste Agile est la Simplicité — l’art de maximiser le travail non fait — est essentielle. Les études du Standish Group présentées dans l’un de leurs Chaos Report montrent que 60 % des fonctionnalités développées ne sont pas ou rarement utilisés. Si vous livrez seulement les bonnes, votre client obtiendra le produit beaucoup plus rapidement et à bien meilleur marché.

Considérer de manière critique les fonctionnalités du produit que vous développez est une façon de prendre en compte ce principe. Vous pourriez appliquer ce même principe au processus que vous utilisez pour développer votre produit. Combien de règles devez-vous suivre ?

Avez-vous jamais joué au jeu de Go ?

Le Go est un jeu de société de stratégie vieux de 2500 ans pour deux joueurs, dans lequel le but est d’entourer plus de territoire que l’adversaire. Malgré ses règles relativement simples, Go est déjà très complexe. Ou pensez au « jeu de la vie » de Conway sur l’automatisation cellulaire. Juste quelques règles très simples et des résultats stupéfiants. Ajouter davantage de règles aboutira au chaos.

CSP est partenaire de DantotsuPM

J’ai lu une histoire à propos des garderies d’enfants en Israël.

Ils faisaient face au problème e que certains parents venaient chercher leur enfant trop tard. Comme solution, ils ont mis en œuvre une nouvelle règle : Si vous venez chercher votre enfant en retard, vous devez payer une amende. Suite à cette règle même encore plus de parents sont venus récupérer leur enfant en retard. Ce qui était un compromis moral (je ne peux pas y aller trop tard) est maintenant devenu une transaction financière : je paie ma dette. Les règles ne sont pas nécessairement sacrées, les principes le sont.

Si vous regardez certaines structures agiles ou façons de travailler, vous pouvez vous demander si les concepteurs vous forcent à adopter une règle ou à la transgresser. Beaucoup sont pensées pour vous aider à construire des équipes d’équipes qui développent un produit ou un service, mais ici aussi, si vous pouvez réussir à ‘simplifier’ votre architecture vers des micro services vous n’aurez pas besoin de ces structures pour « monter en échelle/volume ».

Si vous comparez le nombre de règles de Scrum avec celles de SAFe, vous pourriez vous demander si vous réussissez sortir des agile release trains grâce aux règles SAFe ou malgré elles ?

Structure agile ou façon de travailler Règles
Manifeste agile 4 valeurs, 12 principes
Scrum 3 rôles, 5 cérémonies, 3 artefacts, 5 valeurs
Nexus 6 rôles, 5 cérémonies (équipe), 6 événements (Nexus), 7 artefacts, 5 valeurs
LeSS 5 rôles, 5 cérémonies (équipe), 3 événements (équipe d’équipes), 4 artefacts, 28 règles (LeSS), 12 règles (LeSS énorme)
AgilePM 13 rôles, 6 processus, 15 produits, 8 principes
PRINCE2 Agile 9 rôles, 7 processus, 7 thèmes, 7 principes, 5 comportements, 26 produits
Disciplined Agile Delivery 11 rôles, 3 phases, 6 cycles de livraison, 7 principes
SAFe 12 rôles, 6 cérémonies (équipe), 7 événements (programme), 2 cérémonies (grandes solutions), 7 artefacts, 4 valeurs, 10 principes

CertYou est partenaire de DantotsuPM

Si vous voulez fonder un laboratoire d’innovation ou de croissance, assurez-vous de rester à distance de la bureaucratie. Pour réduire des obstacles, exemptez le laboratoire des règles d’entreprise, des procédures, des manuels, des directives, des principes et des formats. Les approches innovantes peuvent faire sans !

Jim Johnson, rêveur et président du Standish Groupe a partagé dans un interview pour un magazine de Managers de Projet des Pays-Bas : “L’analyse des données de projet a apporté des standards, des approches et des structures, bien que j’hésite en réalité sur les standards, parce qu’ils limitent la croissance. Toutes choses bien considérées, le réflexe de construire des structures accroit les chances d’échec d’un projet technologique. Des structures sous forme d’outils de gestion compliqués, trop de règles de gouvernance, des exigences professionnelles trop étroitement définies… Des structures construites avec les meilleures intentions rendent les projets plus lents, plus chers et plus consommateurs de temps. Des structures dans lesquelles personne n’ose prendre la moindre décision.”

Si vous recherchez l’agilité, pensez à une citation de Pablo Picasso “Apprend les règles comme un professionnel afin de pouvoir les briser comme un artiste”.

Ou avec mes propres mots : Utilisez le bon sens en appliquant des approches agiles ou façons de travailler et démontrez une mentalité agile en comprenant juste la logique plutôt qu’en suivant des règles.

 

Comment travailler dans des environnements agiles pour les managers de projet ? 4 domaines d’attention.

Que les managers de projet devraient-elles et ils garder en permanence à l’esprit dans les projets qui utilisent une approche agile ?

Four vital ways of working for project managers in agile environments

https://www.axelos.com/news/blogs/april-2020/four-ways-of-working-for-project-managers-in-agile par Allan Thomson – PPM Ambassadeur de Produit

Une checklist dans PRINCE2 Agile® best practice guidance décrit les points majeurs dont il faut avoir conscience.

Partenaire de DantotsuPM

#1 – Collaboration et auto-organisation

Un projet impliquant des méthodes agiles doit être basé sur une collaboration efficace avec une équipe auto-organisée qui résout les problèmes ensemble.

Un manager de projet devrait avoir confiance en l’équipe pour produire sans micro-management. PRINCE2 Agile souligne le besoin de permettre aux gens d’avancer pour produire les bonnes solutions exigées par le projet.

Et cela signifie que le comité de projet doit être clair sur ce que veut dire avoir d’une équipe « autonome » et être content que l’équipe projet fasse des changements si nécessaire. Si un élément de changement est majeur, PRINCE2 recommande de manager par exception (quand une situation dévie au-delà de ce que le comité de projet peut accepter).

#2 – Transparence, communication et exploration 

Un manager de projet doit communiquer la vision du produit clairement et l’équipe doit croire en la vision pour contribuer et créer un changement de valeur.

Cela peut impliquer le fait de donner la priorité aux exigences de produit majeures en se basant sur une méthode comme  MoSCoW (must have, should have, could have, won’t have for now). Puis, communiquer le résultat aux parties prenantes sur ce qu’elles obtiendront, devraient obtenir et n’auront pas.

Cette transparence avec les parties prenantes sur ce que sera le produit viable minimal les rassure sur le fait d’obtenir rapidement de la valeur pour leur investissement.

#3 – Environnement

Si Agile est un nouveau concept dans une organisation, PRINCE2 Agile introduit un « Agilomètre« . Le but de l’Agilometer est de fournir un guide vers agile qui créera un niveau de contrôle et de prévisibilité sans devenir excessivement normatif. Cela inclut l’évaluation de l’environnement et son niveau d’acceptation de méthodes et des comportements agiles.

Et, dans cet environnement, le manager de projet doit comprendre et adopter le rôle de servant leader. Il aide l’équipe à déplacer ou éliminer les points bloquants l’avancée du projet. Pour cela, l’engagement des parties prenantes est crucial.

Si l’équipe projet est novice avec les manières de travailler dites « agiles », introduisez-les à Scrum la méthode la plus utilisée. Puis, soyez clair avec les parties prenantes sur ce processus de développement et les éléments de langage utilisés. Soyez également transparent sur ce qu’ils auront et n’auront pas. Par exemple, montrez-leur la partie du produit qui est prête, mais ne les exposez pas à ce qui n’est pas encore prêt à voir ou démontrer.

CertYou est partenaire de DantotsuPM

Faire suivre cette démonstration client par une rétrospective d’équipe permet à chacun de reconnaître ce qui s’est bien déroulé avec les parties prenantes et ce qui n’a pas été. Cela crée une mentalité d’amélioration continue dans l’équipe.

#4 – Planification, suivi et contrôle 

Prenez contact avec chaque personne impliquée dans le projet chaque jour.

Il est essentiel de savoir si l’équipe est heureuse de la façon dont ses membres travaillent dans un environnement agile et un manager de projet doit y devenir un facilitateur. Vous créez dans l’équipe la confiance que vous savez ce que vous faites !

PRINCE2 Agile est construit sur le concept « d’infléchissement » ou « de priorisation », produire pour créer la valeur maximale en premier. Cela représente un changement significatif dans comment les gens pensent et agissent en travaillant sur un projet. Le comité de projet doit le comprendre pour fournir une direction efficace au projet.

Il y a une logique à suivre pour travailler de cette façon
  • Tenez les délais et respectez les jalons
  • Protégez le niveau de qualité car cela est primordial
  • Embrassez le changement puisqu’il va arriver
  • Gardez des équipes stables, n’essayez pas d’ajouter des gens pour aller plus vite
  • Acceptez que le client n’a pas besoin de tout : c’est le cas !

En fin de compte, PRINCE2 Agile complémente la bien établie méthode PRINCE2 mais dans un contexte agile. Ces conseils de bonne pratique prouvent maintenant pour être appropriés et applicables dans de nouveaux pays, avec de nouvelles traductions en allemand, polonais et hollandais.

Un tour de SAFe en 5 minutes !

Cette vidéo explique les principes principaux de SAFe 5.0 en cinq minutes.

Elle comprend une explication des cadences, des cérémonies et des processus de Scrum et de SAFe applicables aux équipes, aux programmes, aux grandes solutions et aux portefeuilles de projets.

Pour en savoir plus sur SAFe, consultez le site scaledagileframework.com et la formation SAFe sur scaledagile.com.

CertYou est partenaire de DantotsuPM

Comment nous avons accidentellement inventé les histoires de travail, les Job Stories

La chose la plus formidable que vous puissiez comprendre en construisant un produit est quelles sont les motivations derrière les actions des gens.

How we accidentally invented Job Stories

https://www.intercom.com/blog/accidentally-invented-job-stories/ par Paul Adams

Chez Intercom, nous réévaluons constamment nos processus pour construire un excellent produit, un produit que les gens trouvent de valeur et utile, un produit qu’ils aiment.

nous écoutons les clients

Une chose sur laquelle nous portons une énorme attention est la recherche. Nous embauchons des personnes avec de l’expérience dans la recherche directe et chacun dans l’équipe produit parle directement aux clients. Nous avons aussi embauché un Directeur de Recherche bien plus tôt que la plupart des autres startups : Sian Townsend qui a précédemment mené les équipes de recherche pour Google Maps.

Bien sûr, il est évident que vous devriez parler aux clients fréquemment pour essayer de comprendre leurs besoins, mais quel est le meilleur outil pour y répondre n’est pas évident.

Chez Intercom, nous pensons constamment aux choses à partir des premiers principes et très tôt nous avons appliqué ce focus sur comment nous parlons à nos clients. Nous étions les grands supporters de l’approche Jobs-to-be-Done (JTBD), mais la plupart de ce qu’a été écrit sur JTBD a été appliqué aux milk-shakes et barres chocolatées. Il y avait peu de recherches publiées sur la façon d’appliquer JTBD au développement de logiciel. Alors, nous avons créé notre propre processus basé sur ce que nous savions.

Les Personas pour l’empathie, pas pour la pensée nouvelle

Livre sur Amazon

Pendant la majorité de ma carrière j’ai utilisé des personas et des scénarios comme des outils pour comprendre les clients.

Popularisé par Alan Cooper dans The Inmates are Running the Asylum, ils sont depuis devenus l’un des outils le plus largement utilisés dans le panel de recherche et conception de l’équipe.

 

Livre sur Amazon

Cooper a aussi écrit un livre fantastique appelé About Face que je recommande à tous les designers qui rejoignent mon équipe, mais je leur dis de sauter les chapitres sur des personas.

Quand je travaillais chez Google, j’ai créé des douzaines sinon des centaines de personas à travers beaucoup de projets. Nous suivions souvent la soigneusement méthode de Cooper et nous créions aussi souvent des itérations de notre propre fait. Universellement, j’ai constaté que leur valeur était limitée. Ils aidaient souvent à construire de l’empathie entre les employés qui étaient déconnectés de leurs utilisateurs, mais ils menaient rarement à des idées révolutionnaires ou fraîches de réfléchir à un problème.

Nous n’avons jamais utilisé de personas chez Intercom.

Les motivations des personnes peuvent être très similaires quelques soient les démographies

La première fois que j’ai vraiment commencé à mettre en doute la valeur des personas était quand j’ai quitté Google et rejoint Facebook. Une des choses saisissantes à propos des données comportementales de Facebook sur leurs utilisateurs était combien le comportement des gens était similaire. Les personas m’avaient amené à croire que les gens sont vraiment différents, avec des objectifs vraiment différents, mais les similarités sont beaucoup plus grandes que les différences et peu importe la démographie que vous pouvez imaginer : la race, l’âge, le genre, etc. Par exemple, les motivations d’une mère mariée avec trois enfants aux États-Unis postant les photos d’un barbecue familial est essentiellement la même que celle d’un adolescent coréen postant les photos de la fête à la maison le soir précédent. Les buts et attributs semblent totalement différents, mais leurs motivations sont les mêmes.

Les personas ne nous mèneraient jamais à un même produit conçu et construit pour ces deux audiences. Alors que les meilleurs personas se concentrent sur les buts (les buts dirigent le comportement des personnes) aussi bien que les attributs, la réalité est que la plupart des personas se concentrent seulement sur les attributs des personas et même des personas dirigés par leurs objectifs ségrèguent artificiellement ces audiences. Les personas limitent artificiellement la cible de votre produit parce qu’ils se concentrent sur des attributs plutôt que des motivations et des résultats. Cette observation a détruit ma foi en eux comme outil.

Ici les clients sont importants

Concevoir pour les motivations et les résultats est bien meilleur que concevoir pour des attributs. C’est la différence clef entre les personas et JTBD. Les personas regardent des rôles et des attributs, JTBD regarde des situations et des motivations. Les personas expliquent qui sont les gens et ce que font les gens. Mais ils jamais expliquent entièrement pourquoi les gens font quelque chose. Pourquoi les gens font certaines choses est beaucoup plus important.

Passer de ce que veulent les gens à pourquoi ils le veulent

les 5 pourquoi, les 5 whys
Utilisez la technique des 5 pourquoi (relisez ce billet)

Ainsi à la mi-2013 chez Intercom, nous nous sommes demandé quel pourrait être un meilleur outil que des personas. Nous parlions à des douzaines de clients chaque semaine et notre équipe de support client parlait à des centaines de plus, recueillant des demandes de fonctionnalités et comprenant les problèmes et les contraintes de notre produit.

Avoir cette relation directe avec nos clients a été inestimable, mais il y avait deux défis que nous avions besoin de surmonter :

  1. Les gens sont des experts dans leur problème pas la solution, mais il est plus naturel de suggérer une solution en forme d’une demande de fonctionnalité. La description d’une suggestion de solution est plus facile que la description d’un problème, mais vous devez retourner vers ces personnes avec des questions pour vraiment comprendre leur problème.
  2. Quand ils répondent, leur réponse initiale vous dira ce qu’ils veulent, sous forme d’attributs, mais pas pourquoi cela importe. Donc vous devez continuer à fouiller dans leurs motivations.

Il était donc critique que nous découvrions quel problème nos clients essayaient de résoudre et pourquoi ils avaient besoin de le résoudre.

Et une fois que nous aurions compris le problème, comment pourrions-nous faire de toute cette compréhension quelque chose d’actionnable pour l’équipe de conception ?

Les longs rapports de recherche et les packs de transparents de présentation avec des résultats de recherche sont difficiles à mémoriser et faciles à ignorer. Nous avions besoin de quelque chose de concis, de facile à communiquer et à se souvenir. Je ne peux compter chez Google le nombre de fois où nous faisions participer des gens à la recherche, à co-créer des Personas avec nous, seulement pour ensuite les ignorer parce qu’ils étaient trop difficiles à se souvenir, trop détaillés à analyser.

Se référer aux Personas n’est pas le chemin par défaut, en fait c’est le chemin de moindre résistance. Et souvent parce que les Personas ne sont pas assez concis pour des équipes développement rapide de produit.

En dehors des Personas, un autre outil très populaire est les User Stories, que le mouvement de développement de logiciel Agile avait popularisées. Nous n’avions jamais utilisé de User Stories non plus. Pour commencer, elles ne proviennent pas de recherche empirique et le format est technique plutôt que centré sur le client. Elles sont formatées pour décrire la fonctionnalité à construire, plutôt que les motivations des personnes.

Histoires de travail : Capturer des situations, motivations et résultats

Après avoir réfléchi à ce problème en repartant des premiers principes, nous avons inventé des Histoires de Travail, les Job Stories. Elles ne portaient pas ce nom en ce temps-là (Alan Klement l’a trouvé plus tard pour nous) mais le processus était là et fonctionnait bien pour nous.

CertYou est partenaire de DantotsuPM

Après avoir longuement considéré JTBD, nous avons créé notre propre approche centrée sur les situations, motivations et résultats :

 [ Quand _____]  [je veux faire _____]  [pour pouvoir _____]

‘ Quand ____ ’ se concentre sur la situation, ‘ je veux faire ____ ’ se concentre sur la motivation et ‘ pour pouvoir ____ ’ se concentre sur le résultat. Si nous avons compris la situation dans laquelle les gens rencontrent un problème à résoudre, comprendre la motivation pour le résoudre et comprendre à quoi ressemble un bon résultat, nous sommes confiants que nous construirons un produit de valeur pour nos clients.

Les Histoires de Travail sont maintenant un outil clef pour nous. Elles garantissent que l’équipe est en mode recherche, que les membres de l’équipe comprennent si bien le problème qu’ils peuvent le capturer en un format concis. Et que leur résumé du problème peut être mis en action par toute l’équipe de conception et technique.

Nous sommes impatients de vous revoir !

Avant que nous ne commencions un quelconque projet chez Intercom, nous créons un résumé d’une page pour le projet. C’est très simple et doit tenir sur une page d’A4 (qui est alors imprimée et collée sur les murs du bureau pour que les différentes équipes aient la visibilité du travail entrepris dans la société). Il a une section sur ses Histoires de Travail. Ces Histoires de Travail sont ce qui assure que nous comprenons le problème ou l’opportunité que nous abordons et elles nous tiennent focalisés sur celles-ci partout dans le projet.

Téléchargez le modèle au format  Word ou PDF

Les personas y ont leur place. Dans des environnements politiques où les gens disent seulement ce que l’on veut entendre sur les besoins réels des clients, je les ai trouvés utiles pour gagner en acceptation; ils peuvent conduire un rapport plus fort avec les réels utilisateurs d’un produit.

Mais les personas sont :
  • Laborieux à bien créer
  • Trop concentrés sur les différences entre les personnes
  • Et difficiles à se rappeler et à référencer.
En fait :
  • Beaucoup de personnes avec des attributs divers ont des motivations très similaires
  • Ces motivations sont faciles à rechercher
  • Et le focus sur ce que vous construisez peut être capturé en une série de phrases courtes et mémorisables.
Si cela ne vous convainc pas, souvenez-vous que les personas contraignent artificiellement le l’ensemble du marché pour votre produit. Nous misons tout sur les Histoires de Travail.