Comment surmonter 4 objections communes au « Daily Scrum » ?

Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Et pourtant, elles sont fort utiles si bien menées.

Overcoming Four Common Objections to the Daily Scrum

https://www.mountaingoatsoftware.com/blog/overcoming-four-common-objections-to-the-daily-scrum par Mike Cohn

Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Je n’aime pas non plus les réunions. Mais, certaines réunions sont utiles et justifient l’investissement de notre temps. Je mets les réunions Daily Scrum bien-dirigées dans cette catégorie.

Dans cet article, je partage avec vous comment je traite quatre objections fréquentes à la participation au Daily Scrum. Je partage ensuite quelques attributs d’un Daily Scrum bien-mené pour qu’il n’y ait plus aucune objection à participer.

4 objections fréquentes

1. Nous parlons déjà beaucoup

Pas de temps à « perdre » alors que nous discutons déjà énormément.

La première objection au Daily Scrum est qu’une personne insiste sur le fait que les membres d’équipe parlent déjà fréquemment l’un avec l’autre et donc le Daily Scrum est une surcharge inutile.

Quand j’entends cette objection, j’y résiste en reconnaissant que les membres de l’équipe parlent vraiment fréquemment en effet l’un avec l’autre. Mais rarement parlent-ils tous ensemble.

Le Daily Scrum fournit cette opportunité. Pour beaucoup d’équipes, c’est l‘unique fois chaque jour où chaque membre d’équipe est capable de parler à tous les autres membres de l’équipe.

2. Rien d’important n’est jamais discuté

Une deuxième objection commune au Daily Scrum vient de membres d’équipe qui estiment que des Daily Scrum sont inutiles parce que rien d’important n’y est jamais discuté.

Repositionnez les attentes
catching the big one
On ne priorise pas la discussion pour discuter des plus importants problèmes en premier.

La première chose je fais quand je suis face à cette objection, est de poser une attente appropriée sur ces réunions avec l’opposant. Je suis très clair sur le fait que je ne m’attends pas à ce que quelque chose d’important soit abordé chaque réunion. Certains Daily Scrum s’avèrent vraiment être assez inutiles, ceux où chacun a réalisé un progrès convenable mais sans quoi que ce soit de remarquable hier et personne n’a de question sur le travail du jour.

Mais, la plupart des Daily Scrum remontent vraiment quelque chose d’utile pour l’équipe. Et l’idée est que les nombreux Daily Scrum où des choses importantes sont discutées compensent les réunions moins fréquentes où rien d’important n’est discuté.

Déterminez si l’objection est valide

La deuxième et plus importante chose que je fais quand j’entends cette objection, est de considérer si elle est recevable. Elle peut l’être. S’il en est ainsi le Scrum Master devrait la prendre en compte comme un indicateur que les réunions pourraient être améliorées.

Prenons le temps de considérer objectivement si la question est pertinente.

Les erreurs fréquentes qui rendent cette objection valable incluent laisser des participants blablater hors sujet, laisser la réunion durer trop longtemps, ou avoir une bande d’individus qui ne sont pas vraiment une équipe. Cette dernière erreur arrive quand « une équipe » est composée d’individus travaillant sur des projets totalement sans rapport.

3. Ne pourrions-nous pas juste le faire par email ?

Certains membres d’équipe ne font pas d’objection au concept d’engager avec leurs coéquipiers quotidiennement, mais au lieu de cela, objectent à en faire une réunion. Ils demanderont souvent d’abandonner le Daily Scrum en faveur d’un email quotidien de chaque personne adressant les mêmes questions habituelles du Daily Scrum.

J’ai rarement vu ceci fonctionner. Le plus grand problème est que la plupart des personnes ne lisent pas les emails. Ou, si elles le font, c’est un jour ou deux plus tard. Cela rend l’équipe moins réactive aux problèmes.

De plus, mener un Daily Scrum par email perd tous les bénéfices de la discussion dans l’instant présent qui devrait faire partie des réunions.

Et avec des outils comme Slack et semblables ? Vous penseriez peut-être que ma réponse serait la même que pour l’email. Cependant, j’ai vu des équipes mener avec succès l’équivalent de réunions Daily Scrum en utilisant Slack.

Je ne sais pas si c’est la nouveauté de tels outils ou quelque chose de fondamentalement différent entre la messagerie instantanée et l’email. Je ne favorise toujours pas de remplacer l’interaction vivante d’un Daily Scrum avec un équivalent Slack pour la majorité des équipes. Mais pour certaines équipes, particulièrement celles qui sont fortement géographiquement distribuées, cela semblent vraiment marcher de manière adéquate.

4. Les réunions durent trop longtemps

Une quatrième et finale objection que vous  entendrez consiste en ce que les réunions durent trop longtemps. Naturellement, vous voudrez prendre cette plainte au sérieux si vos réunions prennent plus longtemps que la norme de quinze minutes prescrites par presque tous les partisans de Scrum.

Mais si vos réunions finissent bien dans la limite des quinze minutes, j’ai constaté que la meilleure réponse à cette plainte est de demander à tout opposant combien de temps il pense serait approprié.

Vous obtiendrez une réponse utile particulièrement si vous incluez quelques-uns des bénéfices de la réunion en posant la question. Par exemple, vous pourriez demander, “Combien de temps pensez-vous serait approprié chaque jour pour nous tenir tous synchronisés, éviter les problèmes de communication, fournir de la visibilité sur ce que fait chacun d’entre nous, identifier et corriger des erreurs, construire la confiance et fournir un sentiment d’accomplissement ?”

CertYou est partenaire de DantotsuPM

7 Attributs d’un Daily Scrum bien mené

Les conseils ci-dessus aideront à surmonter les objections les plus communes que des membres d’équipe peuvent avoir à participer au Daily Scrum. Encore mieux, serait de conduire ces réunions si bien que les membres d’équipe les valorisent. Voici sept attributs d’un Daily Scrum bien mené.

1. Tenez les réunions chaque jour au même horaire et endroit

Vous voulez rendre ces réunions aussi faciles que possible. Pour la plupart des équipes, cela signifient les tenir à la même heure et au même endroit à chaque fois.

2. Débutez la réunion à l’heure

Je suis plus à l’heure que qui que ce soit d’autre. J’ai une fois dû me raisonner d’appeler un docteur quand j’ai réalisé que j’aurais une minute de retard à son cabinet.

Mais je reconnais tout de même qu’arriver quelques minutes en retard à une réunion qui dure toute une journée n’est pas une bien grande affaire. Être cinq minutes en retard à une réunion de huit heures représente 1 % du temps de la rencontre.

Mais être en retard à un Daily Scrum est une affaire beaucoup plus importante. Si les réunions commencent 5 minutes en retard chaque jour, les membres d’équipe qui sont arrivés à l’heure auront perdu plus de 20 heures sur l’année à attendre que la réunion puisse commencer.

3. Respectez la limite de 15 minutes

Il y a une raison pour laquelle beaucoup d’équipes conduisent les Daily Scrum en se tenant debout : Cette position nous aide à rester conscient du temps et facilite les réunions brèves.

4. Identifiez les problèmes mais ne les résolvez pas pendant la réunion

Une bonne pratique commune est de discuter (et avec bon espoir résoudre) des problèmes immédiatement après la réunion. Idéalement cela peut être fait par le sous-ensemble de l’équipe nécessaire pour aborder ces problèmes; les autres membres d’équipe sont alors encouragés à retourner à leurs bureaux.

5. Gardez les participants sur le sujet

La plupart des équipes suivent l’approche d’avoir chaque personne exposer ce qu’ils ont accompli depuis la dernière réunion, ce qu’ils feront avant la réunion suivante et tout problème les ralentissant.

Toute discussion hors de ces sujets devrait être sévèrement limitée.

6. Les règles sont rappelées par l’équipe entière, pas seulement le Scrum Master

Quand le Scrum Master est le seul à imposer les règles de l’équipe lors des réunions, la réunion semble être tenue pour le Scrum Master. Cela ressemble à rapport d’activités où chaque participant fournit le statut seulement au bénéfice du Scrum Master.

7. L’équipe complète et seulement l’équipe participe

Chacun dans l’équipe devrait participer aux Daily Scrum. On devrait permettre à des externes à l’équipe d’observer la réunion. Ils devraient être découragés de contribuer à la discussion pendant la réunion à moins qu’un membre d’équipe ne lui pose une question courte.

Une fois que l’on conclut un Daily Scrum, mais avant que les participants ne se dispersent, beaucoup d’équipes demanderont aux observateurs s’ils ont des questions ou commentaires. Le Scrum Master ou un sous-ensemble de l’équipe peuvent rester et adresser ceux-ci. La clef est que ces commentaires d’observateur restent à l’écart du Daily Scrum.

Quelle est votre expérience ?

Les membres d’équipe peuvent sans aucun doute avoir des objections autres que les quatre les plus communes que j’ai adressées ici. Et il y a certainement des choses complémentaires importantes pour un Daily Scrum bien mené que les sept attributs essentiels que j’ai décrits.

Quelle est votre expérience ? Quelles objections avez-vous entendu et comment les avez-vous surmontées ? Partagez s’il vous plaît vos idées dans les commentaires.

Une équipe Agile ne devrait pas tout finir à chaque itération

On devrait s’attendre à ce qu’aucune équipe ne finisse tout à chaque fois.

An Agile Team Shouldn’t Finish Everything Every Iteration

https://www.mountaingoatsoftware.com/blog/an-agile-team-shouldnt-finish-everything-every-iteration par Mike Cohn

Depuis tout jeune, on nous apprend à ne rien laisser dans notre assiette !

Une mesure fréquemment utilisée d’une équipe agile est si les membres d’équipe finissent tout ce qu’ils ont prévu dans l’itération.

Il n’y a rien mal à évaluer si une équipe est capable à la fin de terminer ce qu’elle pensait pouvoir faire. Mais on devrait s’attendre à ce qu’aucune équipe ne finisse tout à chaque fois.

Ce serait peu réaliste et cela amènerait les équipes à moins s’engager pour pouvoir tout livrer sans prendre de risque.

Matchware est partenaire de DantotsuPM

Des attentes excessives peuvent entrainer des dysfonctionnements

Considérez une équipe dont le patron (le PDG) leur a dit que s’il leur arrivait d’échouer à tout finir, il “prendrait des actions correctives, jusqu’à et incluant probablement l’arrêt brutal du projet.”

Cette équipe ne va pas aller chercher une masse excessive de travail dans ses itérations. Les membres essayeront d’en choisir suffisamment pour ne pas être traités de paresseux, mais pas trop pour ne pas risquer de ne pas tout faire.

CertYou est partenaire de DantotsuPM

Une cible appropriée

Je trouve qu’un bon objectif pour une équipe est de finir tout ce qu’ils disent qu’ils feront environ 80% du temps. C’est un bon degré de prévisibilité pour le business sans être impossible à tenir par les équipes.

Pour être vraiment clair, une bonne équipe agile devrait finir 100% de ce qu’elle prévoit dans 8 itérations sur 10. Je ne dis pas qu’une équipe devrait finir 80% de son travail prévu à chaque itération. C’est très différent.

quelle est la cible à atteindre?
80% du temps dans la cible est déjà très bien.

Tout faire à chaque fois sera impossible pour des équipes fréquemment interrompues. Si une partie significative du travail de votre équipe est de répondre rapidement aux problèmes, vous pouvez vouloir vous donner une cible de pourcentage inférieur.

Ne le planifiez pas si vous ne pensez pas que vous le réaliserez

En essayant de finir 100% de son travail, 80% du temps, l’équipe devrait ressentir qu’ils vont réussir tout en comprenant, avec réalisme, qu’ils ne le feront pas à chaque fois.

J’aime y penser comme analogue au basketteur lançant le ballon. Le joueur ne devrait pas lancer le ballon à moins qu’il ne pense qu’il marquera le panier. Mais, même le meilleur basketteur comprend que tous ses lancers ne peuvent entrer dans le panier.

Un bon basketteur peut réussir 40 à 50% de ses lancers. Ce n’est pas suffisamment de prévisibilité pour la plupart des équipes, voici pourquoi je recommande de viser les 80%.

Quelle est votre expérience ?

Où en est votre équipe sur compléter ce qu’elle a dit qu’elle ferait ? Partagez s’il vous plaît vos idées dans les commentaires ci-dessous.

 

Agile SAFe peut-il s’interfacer avec « Waterfall » ?

Le manque de transparence cause des malentendus et des conflits. Générer de la transparence demandes des efforts spécifiques.

Can Agile (SAFe) Be Interfaced With Waterfall? – Transparency

https://tcagley.wordpress.com/2019/01/24/interfacing-agile-safe-be-interfaced-with-waterfall-transparency/ par Thomas Cagley

Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).

Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets

Le manque de transparence cause des malentendus et des conflits.

Cependant, générer de la transparence a un coût.

Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.

Plusieurs des techniques les plus communes pour générer de la transparence

#1 – Le Contrat

Spécifiez ce qui peut et doit être partagé dans le contrat.  Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre.  Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu).  Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.

#2 – Un Plan construit conjointement

Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres.  La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur  des risques et communiquer les dépendances en temps réel.

Matchware est partenaire de DantotsuPM

#3 – Des Cérémonies communes

Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies).  Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives.  Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.

#4 – Des Ateliers de mûrissement des exigences et de design

travail d'équipeCollecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.

#5 – Des Modèles de design

L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.

Facile ET difficile à la fois

une plus grande transparence comme base de relations et de travail

Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.

La planification Agile est différente et tout à fait primordiale.

Quelques astuces de planification tirées de la pratique des approches Agile dans la vraie vie.

Planning top tips

https://agilechangemanagement.co.uk/2019/10/23/planning-top-tips/ par Melanie Franklin

Les projets agiles sont basés sur le concept que livrer une solution imparfaite au business le jour promis est plus important que livrer une solution parfaite en retard.

Avec Agile, tenir vos promesses sur quand quelque chose sera disponible pour être utilisé en production est au cœur de la réalisation de bénéfices. Chaque élément fourni, même s’il a un nombre minimal de fonctionnalités peut résoudre un problème métier. Focalisez votre équipe sur faire utiliser leur livrable en production, en sachant qu’ils pourront ajouter davantage de fonctionnalités plus tard.

Il y a une fausse idée répandue qui est que ceux travaillant dans des équipes Agiles ne planifient rien.

Alors que les compétences de planification y sont plus importantes que dans l’approche prédictive « en cascade » (PRINCE2 ®) pour les projets parce que :

  • La planification est plus fréquente
  • La planification est faite en collaboration, impliquant chacun qui contribue au projet
  • Les plans y sont un mécanisme essentiel de suivi du progrès
QRP est partenaire de DantotsuPM
aux fausses croyances sur Agile

Pour ces raisons, les compétences de planification sont critiques au travail Agile efficace. La planification détaillée du projet de bout en bout au début ne fait pas partie Agile. Au lieu de cela, il y a la planification fréquente et la re-planification pendant tout le cycle de vie du projet. Quand un élément de la solution est livré au business, le focus se porte sur la planification de la livraison suivante.

Objectifs de la planification

Pour respecter l’importance de planification, j’encourage mes équipes à se mettre d’accord sur un jeu commun d’objectifs pour leurs sessions de planification.

Utilisez ceux-ci pour débuter avec votre équipe :

  • Assurons-nous que nous livrons une solution utilisable et de valeur
  • Assurons-nous que nous n’avons rien oublié
  • Donnons la priorité au travail le plus important en premier
  • Allouons le travail aux meilleurs de l’équipe pour le faire
  • Clarifions l’ordre/le séquencement pour réaliser des économies d’efforts
  • Créons un visuel qui permette aux autres de voir ce que nous faisons et quand afin qu’ils puissent aligner leur travail avec le nôtre
  • Utilisons ce visuel pour fournir un suivi facile de notre progression sans devoir écrire de rapport d’avancement
CertYou est partenaire de DantotsuPM

Ordre du jour de la planification

Supportez ces objectifs en définissant comment va se dérouler chaque session de planification.

J’encourage mes équipes à utiliser un ordre du jour standard pour tous les événements de planification.

Utilisez cet ordre du jour type pour encourager votre équipe à faire de même :

  • Examiner les résultats de notre session de brainstorming préparatoire.
  • Appliquer les critères de priorisation pour créer une liste agréée de travail pour ce sprint
  • Définir ensemble qui va construire et qui va tester le résultat.
  • Chaque personne crée son propre échéancier pour le sprint en s’assurant que les must have  ne dépasse pas les 60 % du travail.
  • Chacun effectue un contrôle croisé de son échéancier avec la personne testant son travail.
  • Réserver le temps nécessaire dans son agenda pour réaliser le travail
  • Se mettre d’accord sur comment vous partagerez le progrès avec l’autre
Matchware est partenaire de DantotsuPM

Pour plus d’astuces sur l’application des pratiques de travail Agile dans la vraie vie, abonnez-vous au bulletin de Melanie ou visitez son site Web.

La curiosité est essentielle pour une gestion du changement, un « change management », efficace.

Le change management Agile c’est surtout de la création d’idées nouvelles et différentes.

Curiosity is essential for effective change management

https://agilechangemanagement.co.uk/2018/12/11/curiosity-is-essential-for-effective-change-management/ par Melanie Franklin

L’approche Agile signifie que les idées sont très tôt dans leur développement distribuées au business pour qu’ils les essayent. Leurs retours sont essentiels au concept et pour ajouter plus de fonctionnalités.

CertYou est partenaire de DantotsuPM

Mais…Je commence à se demander combien d’entre nous sont vraiment prêts pour ces retours. Après tout, c’est souvent un mélange d’éloges et de critiques, qui penche trop souvent vers la critique :

  • Il ne fait pas ce que nous avons dit !
  • Où est la fonctionnalité X ?
  • J’ai pensé que ça allait remplacer Y mais maintenant il ne semble pas que ce soit le cas ?
  • Il ne se connecte pas avec Z donc nous aurons besoin d’un processus manuel pour enregistrer ces données!

Ceci vous semble-t-il familier ? Il est difficile d’aller chercher des réactions, mais si ce doit être utile, je dois le faire dans un état d’esprit de curiosité.

Curiosité

La curiosité est une belle qualité plutôt qu’un vilain défaut.

Je dois commencer le processus avec un véritable intérêt pour ce que je vais entendre. Et pour obtenir les retours les plus utiles, je dois entendre des perspectives différentes. J’ai besoin de courage pour dépasser mes contacts habituels et trouver un ensemble le plus diversifié possible de voix. Après tout, plus la personne donnant les réactions a une expérience et un contexte différents des miens plus ils vont possiblement poser des yeux neufs sur la question.

Je viens de finir de lire l’excellent livre par Michelle Obama où elle fait ces remarques “la similarité amène davantage de similarité, jusqu’à ce que vous fassiez un effort réfléchi pour la neutraliser.” Elle parlait des recruteurs à la Maison Blanche mais c’est vrai de tous ceux avec qui nous travaillons.

Mes efforts pour neutraliser la similarité impliquent un effort conscient de reconnaître mes expériences et rechercher des personnes qui en ont de différentes. À moins que je ne sois très honnête avec moi-même sur mon contexte, mes accomplissements, mon chemin de vie, il est ardu de reconnaître l’existence de quoi que ce soit de différent.

Cherchez votre opposé

Beaucoup de mes clients essaye d’encourager cette auto-évaluation sur les biais cognitifs inconscients, qui semble vraiment être la tendance. Ce que je retiens de cela est “cherchez l’opposé” car semble être une bonne place pour commencer :

  • Je cherche des personnes qui ont la moitié de mon âge.
  • Je cherche des personnes sans diplômes.
  • Je cherche des personnes qui ont changé d’industries de multiples fois.
  • Je cherche des personnes qui ont travaillé pour le même employeur pendant des décennies.
  • Je cherche des personnes qui ont vécu et ont travaillé dans des pays différents.

Comme nous changeons de saison, je veux vous soumettre le défi suivant. Sortez et faites-vous de nouveaux contacts !

FDF est partenaire de DantotsuPM

Commencez à discuter avec de nouvelles personnes

Au lieu de regarder votre montre, engagez la conversation avec vos voisins.

Faites l’effort conscient d’engager la conversation avec des personnes que vous ne connaissez pas dans la file d’attente pour déjeuner. Demandez-leur où elles travaillent et ce qu’elles font. Allez dans une autre partie de votre bâtiment et présentez-vous à de nouveaux collègues. Demandez à être conférencier externe dans d’autres réunions d’équipe pour pouvoir partager ce sur quoi travaille votre équipe avec d’autres parties de votre société.

Engagez la conversation avec des clients et des fournisseurs et demandez-leur quelles sont leurs priorités et défis pour la saison prochaine et dites-leur sur quoi vous travaillez. Découvrez s’il y a les zones d’intérêts communs et une chance de collaborer.

Un printemps d’opportunités !

Je sais que tout cela semble un travail difficile mais chacun a ce nouveau printemps à l’esprit et c’est une belle occasion de parler de ce qui a été réalisé récemment et ce qui vient ensuite.

Autrement dit vous avez déjà une entrée en matière, alors sortez et utilisez-la.

Une vidéo avec une grande affiche gratuite pour bien expliquer les principes fondamentaux de Scrum à votre client et organisation

Vous souhaitez recevoir une aide visuelle mais aussi le bon discours pour interpréter le guide Scrum?

https://www.scrum.org/resources/blog/scrum-poster-visual-guideaid

Demandez votre copie gratuite de ce très sympathique et complet poster Scrum et montrez-le à vos collègues et amis.

Cette affiche peut être un outil d’apprentissage (par exemple lors de la lecture du guide Scrum) et un outil permettant à un ScrumMaster d’expliquer Scrum à l’organisation, au responsable produit ou à l’équipe de développement.

https://www.incrementor.com/agile-poster-series

Une seule demande par personne est acceptée. Expédition aux États-Unis et en Europe uniquement. Vous serez informés par e-mail une fois le poster expédié.

Et voici la bande son en anglais dans cette vidéo

CertYou est partenaire de DantotsuPM

Un webinaire et papier blanc de Melanie Franklin nous donnent un aperçu de l’impact des approches agiles sur la façon dont nous gérons le changement !

L’utilisation d’une approche Agile est pertinente pour tout type de changement, et pas seulement pour les changements technologiques.

Melanie le précise parce que, trop souvent, on a l’impression que Agile ne s’applique qu’aux projets des nouvelles technologies.

Les principes et techniques d’Agile ont été largement adoptés dans l’ensemble de la communauté informatique, mais les initiatives de restructuration des entreprises, de changement de localisation, d’acquisition et de rationalisation des processus bénéficient toutes d’Agile.

En effet, Agile est une façon de travailler qui permet de décomposer un objectif en petits étapes, chaque pas (ou Sprint en approche Scrum) menant à une réalisation qui peut être utilisée, davantage développée et construite.

Inscription à un wébinaire gratuit à la demande

Papier Blanc en anglais pour entrer dans les détails

CertYou est partenaire de DantotsuPM

pour en apprendre davantage sur Disciplined Agile Delivery (#dad) !

Cette brève vidéo donne un aperçu du cycle de vie agile de base avec Disciplined Agile Delivery qui est l’application la plus courante de DA.

Relisez le billet « Voici pourquoi le PMI a acquis DA« 

CertYou est partenaire de DantotsuPM

 

Commençons bien l’année, faisons un peu de ménage dans notre « product backlog » !

Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…

Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.

Qu’en pensez-vous et comment traitez-vous ce problème ?

Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?

Est-ce périodiquement lors de grands « ménages » saisonniers ?

Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?

CertYou est partenaire de DantotsuPM

Agile, c’est aussi et surtout commencer par faire simple avant d’améliorer, d’automatiser et d’optimiser.

Je vous l’accorde volontiers, il ne s’agit pas avec Agile d’oublier que la complexité est bien réelle ni de l’ignorer…

Mais, il faut savoir commencer petit puis apprendre en marchant si l’on veut tirer rapidement bénéfice des avancées même modestes.

Par exemple, vous pouvez trouver acceptable d’avoir des paramétrages codés en dur dans la première version du logiciel, ou bien des capacités réduites de personnalisation, ou encore un seul profil/persona utilisateur…

Ou des choix de coloris limités pour vos premières productions.

CSP est partenaire de DantotsuPM

Devrions-nous adopter certaines des approches de « triage » utilisées dans les services des urgences des hôpitaux pour définir nos MVPs ?

Livre sur Amazon

Darria Long, médecin urgentiste, explique les principales leçons tirées des urgences de l’hôpital sur la gestion du stress, du chaos et de la vie.

Le Dr. Darria Long Gillespie est un médecin d’urgence formé à Yale et Harvard, auteur du livre à succès « Mom Hacks ».

Vous avez toujours voulu savoir ce qu’est et n’est pas un Scrum Master, voici une vidéo faite pour vous.

Avec l’essor massif de l’Agilité dans les organisations et plus particulièrement de la méthode Scrum, un nouveau rôle est apparu : Scrum Master.

Et avec ce rôle de nombreuses questions:

  • Peut-il développer ?
  • Est-il chef de projet ?
  • Est-il le responsable des développeurs ?
  • Comment s’interface-t-il avec les utilisateurs et le Product Owner ?
  • Quelles sont ses missions ?

Cette vidéo devrait vous permettre de faire le tri entre les mythes et les réalités qui entourent ce rôle.

En bonus vous repartez avec quelques outils bien pratiques dans votre rôle quotidien de Scrum Master si vous l’êtes et vous comprendrez mieux ce rôle si vous ne l’êtes pas !

CertYou est partenaire de DantotsuPM

 

Montez ou restez dans le train SAFe© avec la 5.0 !

Téléchargez la présentation “What’s New in SAFe® 5.0 ?”

SAFe permet de monter à l’échelle dans l’implémentation de méthodes Agile et de mettre en place gouvernance projet et programme robuste.

Hexagon est partenaire de DantotsuPM

Ce jeu de transparents présente une vue assez détaillée de tous les changements introduits dans le SAFe Framework©.

Téléchargez le document: https://v5preview.scaledagileframework.com/?ddownload=41425
© Scaled Agile, Inc.

CertYou est partenaire de DantotsuPM

Dans les projets liés à la conception de produits et services, la priorisation est plus Art que Science

Il n’y a pas d’approche de priorisation foncièrement mauvaise ni systématiquement bonne mais il y a des incontournables.

Prioritization is More Art Than Science

http://www.cleverpm.com/2018/10/05/prioritization-is-more-art-than-science/ par The Clever PM

Un challenge très commun chez les managers de produit de tous niveaux d’expérience est de comprendre et mettre en œuvre une certaine forme de processus répétable autour de la priorisation.

Certaines personnes prennent une approche très légère, elles font des décisions basées sur leur propre expérience, données et conviction sur la direction du produit.  D’autres prennent une approche beaucoup plus rigoureuse, appliquant des scorecards et autres mesures « objectives » à travers une pléthore de différentes métriques potentielles.

Je dois ici vous dire qu’il n’y a rien de mauvais avec n’importe laquelle de ces approches, mais il m’est aussi apparu clairement au cours de mes années de  manager de produit qu’il n’y a aucune solution miracle pour vous assurer que vos décisions de priorisation seront bonnes plus souvent que mauvaises.

Trop compter sur des systèmes et des scores aboutit souvent seulement à un faux sentiment de sécurité que « le processus » était bon, quand en creusant vous constaterez que ces “scores objectifs” ne sont rien plus qu’un système avec lequel jouer.

Il y a cependant 3 choses dont je pense que chaque système de priorisation devrait tenir compte.  Aussi, sans plus de cérémonie, discutons valeur, difficulté et instinct

#1 – Prioriser c’est prendre en compte la valeur

Si nous pensons au problème racine que nous essayons de résoudre avec nos efforts de priorisation, ce devrait être que nous essayons de livrer la plus grande valeur possible, aussi rapidement que possible, en apportant des bénéfices à nos utilisateurs finaux et clients.  Si c’est votre but (et si ça ne l’est pas, honte à vous !), alors l’un des facteurs les plus importants à considérer dans vos efforts de priorisation est la valeur que cette chose apportera vraiment.

Apporter la plus grande valeur possible, aussi rapidement que possible à nos clients.

Certains lui donnent une valeur numérique, d’autres utilisent une valeur monétaire — quoique ce soit qui marche, tant que vous considérez combien de valeur vos efforts vont délivrer.  Cependant, baser vos décisions seulement sur la valeur marchande peut souvent aboutir à une dépriorisation de la dette technique et des investissements d’infrastructure. S’il vous plaît, pour l’amour de toute puissance supérieure en laquelle vous croyez, n’en soyez pas la victime.  Bien que la dette technique et l’infrastructure pourraient ne pas avoir la valeur évidente pour le client, échouer à investir le nécessaire dans celles-ci causera l’échec de votre produit à un certain point critique pour un certain client critique.  Si vous utilisez la valeur pour le client comme unique ou principale métrique, assurez-vous s’il vous plaît que vous avez un groupe de taches séparé pour le travail qui vous permet de rembourser votre dette technique et investir dans des améliorations d’infrastructure.  Ayez confiance en moi, vous respirerez beaucoup plus librement en sachant qu’il n’y a pas un certain item technique inconnu qui va causer un effondrement général au plus mauvais moment possible.

#2 – Prioriser c’est prendre en compte la difficulté

Alors que la valeur pour le client est importante, il est également important que nous comprenions la quantité de travail qui va entrer dans toute nouvelle fonctionnalité ou amélioration de notre produit.  Peu importe combien la valeur client est incroyablement élevée, si vous ne parviendrez jamais en réalité à compléter le travail à temps pour capitaliser sur cette opportunité.  Trop souvent, des managers de produit décident seuls de la difficulté de quelque chose sans impliquer quelqu’un côté développement, support, ou équipes de livraison : C’est une erreur de débutant que même les managers de produit avec plus de 10 années d’expérience font tout le temps (oui, je la fais aussi parfois).

Attention au mirage venu de la seule imagination du manager de produit sans réelle prise en compte de la faisabilité.Évaluer l’effort exigé pour ajouter une  fonctionnalité ou une capacité est plus précis quand réalisé en impliquant les gens qui feront effectivement le travail. Ils connaissent leurs capacités mieux que vous, ils connaissent la technologie mieux que vous, ils connaissent le code existant mieux que vous, etc.  Cela ne signifie pas que vous devez tout décomposer en tâches, ou même en histoires utilisateur mais cela veut dire que vous devez consulter vos équipes techniques pour avoir une meilleure idée de combien une fonctionnalité est « grande », ou combien de temps il leur faudrait pour la produire.  Quand nous devons évaluer la difficulté de résoudre un problème, assurons-nous que nous nous basons sur des experts et n’utilisons pas simplement nos propres opinions qui seront plus souvent fausses que correctes.

#3 – Prioriser c’est aussi suivre son instinct

Des données objectives et quantitatives sont des apports épatants dans tout processus de priorisation et plus de données vous pouvez obtenir, meilleures vont probablement être vos décisions.  Mais il y a aussi un aspect inexprimable à la priorisation qui fait de ce processus tout entier plus un art qu’une science.  Franchement, si tout ce qu’il fallait était des données objectives déposées dans un tableau qui donne un score alors vous n’auriez pas vraiment besoin de managers de produit pour mener vos efforts de priorisation.  Vous auriez un système basé sur l’Intelligence Artificielle qui considère vos idées, prend toute les données disponibles et vous dit exactement que faire et précisément quand le faire.  Heureusement pour ceux d’entre nous qui avons choisi le Management de Produit pour carrière, ce n’est pas le cas.

Il y aura toujours une partie d’analyse subjective quand on regarde les données et prend des décisions sur si vraiment la direction que nous indiquent  les données signifie réellement quelque chose dans le schéma d’ensemble.  J’ai travaillé dans des environnements où les décisions ont été prises par des résultats d’étude Six Sigma, des tableaux, un processus « objectif » de collecte de données et celles-ci ont poussé des fonctionnalités que personne ne voulait ni ne se souciait et en gaspillant des ressources techniques.  L’équipe de Management de Produit savait qu’il y avait de meilleures options, savait qu’il y avait d’autres données subjectives pour soutenir ces efforts, mais a été forcée de se taire et de “laisser marcher le système”.  Mais il n’a pas fonctionné, parce qu’il a ignoré l’expérience globale que de bons managers de produit apportent à la table.  Un bon manager de produit sait quand insérer l’instinct et l’expérience dans l’équation et changer ou réarranger des choix basés seulement sur des données « objectives ».

Sans instinct, sans le ressenti dans ses tripes, seuls les choix apparemment les plus sûrs seront adoptés et l’innovation jetée par la fenêtre.

SAFe 5.0, une brève avant-première par Henny Portman

Elle arrive bientôt, la nouvelle version de SAFe !

SAFe 5.0 brief preview

https://hennyportman.wordpress.com/2019/10/08/safe-5-0-brief-preview/ par Henny Portman

Au début 2020, une nouvelle version de SAFe sera disponible. Elle est, comme d’habitude, entièrement compatible avec la version précédente SAFe 4.6, permettant une migration en douceur.

Il y a maintenant 7 compétences fondamentales qui permettent l’agilité dans le business. Certaines sont repositionnées et restructurées et 2 nouvelles compétences étendent SAFe afin qu’il englobe l’entreprise toute entière et permettent l’agilité d’affaires. Voir la nouvelle grande image de SAFe.

Les deux nouvelles compétences sont : Culture d’Apprentissage Continu (Continuous Learning Culture / CLC) et Agilité Organisationnelle (OA).

La Culture d’Apprentissage Continu est basée sur trois dimensions : L’Organisation Apprenante (vision partagée, systems thinking, modèles mentaux, apprentissage dans l’équipe, maîtrise personnelle), l’Amélioration Inexorable (un sentiment constant de danger, optimisation de l’ensemble, culture de résolution de problème, Prise de recul aux événements marquants principaux, l’amélioration basée sur les faits) et la Culture d’Innovation (les gens innovateurs, le temps et l’espace, aller voir, expérimentation et réactions, pivoter sans pitié ni culpabilité, innovations à contre-courant).

Les trois dimensions d’Agilité Organisationnelle sont : des gens pensant LEAN et des équipes agiles (house of lean, principes SAFe, Manifeste Agile), des Opérations LEAN (temps de traitement –temps d’attente – temps de traitement) et Agilité de Stratégie.

L’ancienne compétence DevOps et release on demand est maintenant appelée Livraison de Produit Agile (Agile Product Delivery). Ici nous voyons des développements sur la Cadence, la livraison sur demande, DevOps et le Pipeline de Livraison en Continu. Une nouveauté est  la Position Centrée sur le Client Customer Centricity qui comprend : étude de marché, design avec l’utilisateur) et Design Thinking dans la Livraison Agile de Produit.

Livre sur mazon

Les équipes business de l’entreprise montent maintenant ‘sur le train’ et participent à la livraison et au support de solutions business innovantes. Ces équipes adoptent les valeurs, principes et pratiques Lean et Agiles.

Un dixième principe SAFe est ajouté : S’organiser autour de la valeur. Ce principe est basé sur Kotter ‘dual operating system’ comme décrit dans son livre XLR8 – Accelerate. Building strategic agilty for a faster moving world.

Si je prends une vue d’ensemble de la forêt agile, je replace SAFe pour souligner que SAFe couvre maintenant, au niveau produit, cible produit ainsi que le choix de culture.

Voir Bird’s eye view on the agile forest blog pour l’article complet.

Voir le Scaled Agile website pour plus d’information sur SAFe 5.0

Guide Kanban pour les équipes Scrum par Scrum.org

Un tout nouveau guide disponible gratuitement et traduit en français.

 

à télécharger en ligne

L’approche Kanban, orientée flux, peut améliorer et compléter le cadre de travail (Framework) Scrum ainsi que sa mise en œuvre. Les équipes peuvent ajouter des pratiques Kanban complémentaires, qu’elles débutent avec Scrum ou l’utilisent déjà.

Le Guide Kanban pour les équipes Scrum est le résultat d’une collaboration entre des membres de la communauté Scrum.org et des leaders de la communauté Kanban.

Ensemble, ils supportent Le Guide Kanban pour les équipes Scrum. Ils partagent la conviction que les professionnels du développement de produits peuvent bénéficier de l’application de Kanban couplée à celle de Scrum.

CertYou est partenaire de DantotsuPM

MVE et MVP et MMF : Quelle est la différence ?

Livrer souvent un produit certes incomplet mais utilisable et de valeur c’est Agile !

Personnellement, je ne connaissais ni MVE ni MMF et je trouve que ces concepts sont utiles pour préciser ce que l’on cherche à réaliser et surtout ce que l’on peut ou pas livrer aux clients et utilisateurs. L’idée des spikes sur une journée pour préciser les besoins me parait également très intéressante.

MVE and MVP and MMF: Defining the Difference

https://blog.gurock.com/mve-and-mvp-difference/  par Catherine Nest

Source : Egg Lighting

La promesse des approches agiles est de livrer quelque chose souvent. Nous livrons, ainsi nous pouvons obtenir des réactions et discuter du reste à faire avec notre client (ou le Propriétaire de Produit / Product Owner). Et, donc nous pouvons évaluer notre processus et notre travail d’équipe tout le temps.

Trop souvent, les gens pensent aux fonctionnalités comme la somme de tout ce qui pourrait être dans ce périmètre. Cependant, nous en avons des alternatives à ce « tout » avec une variété de minimums.

Définissez les divers Minimums

Nous avons beaucoup de « minimums » possibles quand nous pensons aux histoires et plans de travail :

  • MVE, Minimum Viable Experiment – Expérience Viable Minimale : une histoire fournit des réactions pour l’équipe et le propriétaire de produit.
  • MVP, Minimum Viable Product – Produit Viable Minimal : une histoire ou un jeu d’histoires qui apportent assez de fonctionnalités pour que le client puisse les utiliser, même si ce ne sont pas les pleines fonctionnalités.
  • MMF, Minimum Marketable Feature – Fonction Commercialisable Minimale : le plus petit morceau de fonctionnalité qui le client considère de valeur.

Les MVEs peuvent être utiles quand vous voulez savoir si vous devriez même songer à cette partie d’un jeu de fonctionnalités.

Une équipe à la société Acme se débattait avec l’ensemble de fonctionnalités appelé « Rapports ». La fonctionnalité couvrait plusieurs grands rapports : ventes par géographie, par type de produit, agrégées par plusieurs clients et autres.

L’équipe savait qu’elle avait besoin d’une base de données, d’un système de production configurable et de sécurité/protection des données, parce que les clients pourraient accéder directement à certains de ces rapports. Et, chaque client devait avoir ses données protégées. Aucun client ne pourrait voir des données d’autres clients. Ils savaient qu’ils auraient besoin d’au moins deux niveaux de protection pour les clients et en interne à leur organisation.

En essayant d’écrire l’histoire dressant la liste de fonctionnalités des rapports, ils avaient créé plus de 20 histoires, juste pour les rapports client. Ils ont alors décidé qu’ils avaient besoin d’un MVE pour voir ce quels étaient les besoins minimaux pour les rapports clients. Peut-être sur-analysaient-ils le jeu minimal de rapports clients.

Comme ce produit exigeait de la sécurité, tant le MVP que le MMF nécessitaient une base de données avec des fonctionnalités de management de la sécurité. L’équipe savait que pour la base de données, ils auraient probablement besoin de données avant de créer un schéma pour cette base.

Ils ont finalement choisi d’expérimenter avec des données simulées pour voir de quoi les clients auraient vraiment besoin. Puis, ils pourraient élaguer l’arriéré d’histoires.

Les expérimentations créent un accord commun sur ce qui est important

Quand l’équipe a créé son histoire utilisateur originale pour des rapports clients, les membres avaient identifié trois niveaux de sécurité : le vendeur chez le client, le directeur commercial du client (ou tout autre membre de la direction) et les personnels internes de gestion de produit et commercial. Acme avait besoin d’informations sur ses clients et les clients de la sécurité nécessaire pour l’un et l’autre, c’est pourquoi il y aurait des niveaux différents de sécurité.

L’expérimentation initiale était simple : Sur un petit jeu de produits, comment les clients avaient-ils besoin de visualiser les données ?

L’équipe a pensé à simuler les rapports dans un fichier informatique. Puis, un testeur a suggéré qu’ils créent plutôt les prototypes sur papier car ils seraient faciles à changer instantanément, si nécessaire.

L’équipe (incluant le Product Owner) a passé une heure à créer une variété de prototypes papier et de flux de travail qu’ils pensaient que le client voudrait. Ils ont appelé le chef de produit qui avait rencontré un client la semaine précédente. Ils lui ont déroulé les flux.

Le chef de produit a accepté le premier flux et a rejeté les trois suivants et a expliqué pourquoi. Les explications ont surpris tant le Product Owner que le reste de l’équipe. Ils ont appris beaucoup de cette expérimentation et furent capables de reporter à plus tard un certain nombre d’histoires utilisateurs sur les Rapports – le tout en un seul jour de travail.

Puis, ils ont eu besoin de considérer le schéma de la base de données. Ils savaient qu’ils n’auraient pas de MVP sans la sécurité nécessaire. Cela signifiait qu’ils devaient embarquer non seulement la sécurité, mais aussi sa performance.

Les Spikes ont aidé toute l’équipe à apprendre ensemble

Ndlt : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.

Copyright 2000 Don Wells

Cette équipe avait essayé les spikes dans le passé et les avait appréciées.

Ils avaient un flux typique
  • L’équipe entière se rencontre 20 minutes maxi le matin (à 9 :00) pour passer en revue l’histoire. L’équipe a souvent besoin de seulement 5 minutes, mais on y alloue 20 minutes.
  • L’équipe décide comment travailler ensemble. Dans ce cas spécifique, deux développeurs travaillent en paire sur le schéma, deux autres membres de l’équipe sur les tests automatisés et l’autre développeur s’assure qu’il créée des outils pour que les testeurs puissent vérifier les résultats dans la base de données. Ils décident de développer et tester directement dans la base avant l’interface utilisateur.
  • L’équipe est séparée en ses sous-groupes et travaille pendant une heure.
  • Toutes les heures, ils se réunissent 5minutes pour un point rapide. Quelqu’un a-t-il été bloqué ? Tout se passe-t-il comme prévu ? Quelqu’un aurait-il besoin d’aide ? Quelqu’un a-t-il terminé et pourrait aider les autres ?

Leurs réunions n’étaient pas des standups traditionnels, où trop souvent, l’équipe se concentre sur la personne. Ces rencontres ont permis aux membres d’équipe de se concentrer sur le travail.

Au point rapide, l’équipe décide si elle a besoin de modifier les sous-équipes pour améliorer le flux du travail. Ils font ceci à chaque heure (avec une pause déjeuner) jusqu’à 16:00 ou quand ils ont terminé, le premier des deux.

L’équipe s’ arrête à 16:00 pour plusieurs raisons
  1. Ils sont fatigués. Ils se sont concentrés toute la journée sur du travail difficile.
  2. S’ils ne peuvent pas « finir » le spike dans la journée, le travail nécessitait probablement plus que même deux journées. Ils ont besoin de se regrouper et de replanifier.
  3. S’ils ont terminé, ils peuvent expliquer ce qu’ils ont découvert au Product Owner.

À la fin de la première journée, ils se sont rendus compte qu’ils auraient besoin d’autres scénarios pour la performance et la sécurité. Il était le temps de discuter de comment ces aspects fonctionnaient ensemble et séparément avec le Product Owner.

Que pourraient-ils reporter en matière de performance, d’autant plus qu’ils n’allaient pas encore exécuter ces rapports sur de gros volumes ?

Les MVPs fournissent des retours à l’équipe

Produit Viable Minimum (MVP)

Le Product Owner mène la discussion d’équipe sur ce qui constitue un réel MVP. Un MVP signifie que les clients devaient être capables d’utiliser ce que l’équipe a livré. Ils choisissent cinq histoires et créent ce premier MVP centré seulement sur le vendeur interne à la compagnie. L’équipe s’attend à recevoir des réactions du personnel commercial sur les fonctionnalités et la performance. Ils utilisent ces retours pour prévoir les MVPs suivants à destination du personnel commercial de la société.

Dans ce cas, le Product Owner décide quel persona est le plus important à quel moment, pour séquencer les MVPs de manière logique. Il faut trouver la balance entre manager les retours de l’équipe et délivrer de la valeur pour les clients.

Les MVPs permettent de créer un produit commercialisable ou MMF

Il faut plusieurs MVPs pour créer une MMF, une Minimum Marketable Feature (Fonction Commercialisable Minimale). Ce MMF fournit assez de valeur (et de cohérence produit) pour trois personae clés : le personnel commercial interne et leurs managers, ainsi que l’équipe de ventes.

Plus petit votre MMF, plus rapide le flux de travail pour le produire.

Vos minimums sont-ils assez petits ?

Je travaille régulièrement avec des équipes qui pensent qu’un MVE est la même chose qu’un MVP et qu’un MMF. Même s’il est possible que les trois soient identiques, le plus souvent ils sont différents.

Je constate que quand les équipes utilisent des spikes d’un jour, apprenant ensemble pendant cette journée, elles sont mieux à même de faire la différence entre ces divers minimums.

A quel point pouvez-vous minimiser votre travail et en maximiser la valeur pour vos clients ?

Livre sur Amazon

Cet article a été écrit par Johanna Rothman. Johanna, est connue comme la “Pragmatic Manager” qui fournit des avis honnêtes sur vos problèmes.

Son dernier ouvrage est “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”

 

scrum methodologie agile

si vous voulez devenir formateur certifié Scrum…

Scrum Inc a créé le « Licensed Scrum Program »

PMGS est partenaire de DantotsuPM

La mission du Scrum Inc « Licensed Scrum Program«  est de développer Scrum dans le monde entier, en libérant les gens des servitudes incroyables du système dans lequel ils travaillent. Nous sommes à un moment charnière où les plus grandes organisations du monde se rendent enfin compte que leur façon de travailler ne marche pas. Elles doivent changer et cherchent à le faire en faisant preuve « d’agilité », souvent sans les pratiques prouvées qui produisent de bons résultats.

Le programme « Licensed Scrum«  est conçu pour fournir aux particuliers et aux organisations une voie claire de mise en œuvre de Scrum d’une façon qui conduit à des résultats opérationnels immédiats et fait en sorte que Scrum ait un impact de transformation durable.

Ce programme enseigne comment nous délivrons réellement deux fois plus de résultats en la moitié de temps dans des organisations à travers le monde entier. Les formations de Scrum Inc. comprennent les principes Lean, les modèles du mouvement Scrum Pattern Language et les leçons tirées des implémentations de Scrum@scale dans la vraie vie.

Visionnez cette vidéo de Jeff Sutherland, l’un des concepteurs de Scrum.


You can register for a class on our website: http://www.scruminc.com/LSProgram If you’re interested in becoming a Licensed Scrum Trainer, learn more at: http://www.scruminc.com/LST


CertYou est partenaire de DantotsuPM

 

Voici pourquoi le #PMI® a acquis Disciplined Agile

ACQUISITION DE DISCIPLINED AGILE PAR LE PMI  (press release)

Livre sur Amazon

C’est pendant l’été, le 12 août, que le Project Management Institute a acquis les

droits sur Disciplined Agile (DA).

 

La boite à outils DA est un ensemble complet de connaissances agiles (un Body of Knowledge – BOK) qui fournit des conseils simples et pratiques pour aider les personnes, équipes et entreprises à décider de leur « façon de travailler » en fonction du contexte.

Parmi les principes clés

  • Être centré sur le client
  • Être pragmatique plutôt que puriste
  • Proposer une large gamme d’options agiles et LEAN
  • Adapter ses pratiques en fonction du contexte
  • Optimiser les flux dans l’ensemble de l’entreprise

CertYou est partenaire de DantotsuPM

Il s’agit pour les organisations d’adapter « leur façon de travailler » à leur contexte.

Disciplined Agile a compris la nécessité de personnaliser toute méthode ou toute approche, traditionnelle et prédictive, Scrum ou SAFe, afin d’obtenir des résultats qui les différencient de leurs concurrents.

La combinaison de PMI et DA offre donc une proposition de valeur nouvelle et attractive. Voici, je pense, pourquoi le PMI a fait cette acquisition. Elle lui permet de rester à la pointe dans le management de projet en utilisant de manière pragmatique des approches Agiles quand cela fait sens pour le projet.

PMI is a registered mark of Project Management Institute, Inc.

Si vous connaissez ou utilisez déjà Disciplined Agile, n’hésitez pas à me contacter pour partager votre expérience sur ce blog.

Manager à l’ère du numérique et de l’Intelligence Artificielle avec Cécile Dejoux

Lors du dernier forum National du PMI France, le demi-millier de très chanceux participants ont pu échanger avec Cécile Dejoux !

Son entrée en matière a immédiatement capté notre attention avec une intéressante analogie gastronomique : « Nous sommes dans une nouvelle civilisation : Avant, on faisait confiance à l’expert, aujourd’hui à la multitude. »

Il s’agissait bien sûr des recommandations du guide Michelin versus celles de Trip Advisor.

Cécile entra ensuite dans le vif du sujet avec 4 étapes pour réussir toute transformation numérique.

  1. Repérer les dysfonctionnements
  2. Alléger les processus
  3. Tester de nouvelles méthodes de travail
  4. Penser en écosystèmes

Elle a identifié 4 compétences numériques

Livre sur Amazon

Sans dévoiler toute la pertinence de l’approche que vous retrouverez dans son ouvrage « Métamorphose des managers : à l’ère du numérique et de l’intelligence artificielle » que je vous invite à lire, j’ai tout de même noté cette liste intéressante, celle des compétences numériques.

  1. Curation
  2. Granularisation
  3. Partage
  4. Valorisation

4 Compétences d’Agilité

Pour vous donner envie d’en apprendre davantage sur son blog et ses MOOCs…

  1. Aller Vite
  2. Expérimenter
  3. Faire confiance aux personnes : « People before process »
  4. Nouveaux usages

Pour aller plus loin

Suivez l’actualité de Cécile Dejoux : https://www.ceciledejoux.com/presse  et découvrez ses ouvrages et MOOC dont voici un teaser.

De nombreuses présentations de la  journée de management de projet 2019 du PMI France sont disponibles sur le site du PMI France

Est-il plus pertinent pour vous d’adopter une approche itérative Agile, une prédictive comme Prince2 ou de mixer les 2s ?

La promesse de PRINCE2 Agile : une parfaite tempête ?

https://www.citi.co.uk/blogs/methodology/the-promise-of-prince2-agile/ par Jane Nichols

Comment avoir une approche de management de projet en laquelle on a déjà confiance et y ajouter le nouveau ‘ test de pertinence ’ pour s’assurer que l’approche adoptée est la bonne pour le projet en question ?

PMGS est partenaire de DantotsuPM

Une parfaite tempête de circonstances dans la gestion de projet dans le secteur public au Royaume-Uni aide à ouvrir la porte aux méthodes agiles et en particulier aux promesses de PRINCE2 Agile.

D’abord, certains projets n’ont pas atteint le succès escompté, ne livrant pas le produit escompté ou ne répondant pas aux attentes des parties prenantes. En combinant ces problèmes  avec la suite probable de mesures d’austérité du Gouvernement et encore plus d’attention sur les projets rend fort attirante l’opportunité d’avoir l’accès à des méthodes qui aideront à les mener plus efficacement.

D’autre part, il y a eu des dépenses significatives engagées dans les formations et certifications  PRINCE2® dans les secteurs tant publics que privés et les organisations veulent s’assurer que leurs investissements produisent un retour maximal. Les managers de projets qui ont acquis une certification de base ou avancée pourraient appliquer leur expertise de ces pratiques pour un effet encore plus important en se servant plus largement de la méthodologie qu’ils ont appris pour réussir l’examen. Cela signifie porter l’utilisation de PRINCE2 au-delà de la connaissance sur une application tangible et augmenter le retour sur l’investissement en conséquence. Et c’est pourquoi la création de PRINCE2 Agile fournira une combinaison gagnante de méthodologies aux projets : Ajouter Agile à l’approche PRINCE2 la rend plus flexible, pratique et de valeur.

Il s’agit de prendre l’approche de management de projet en laquelle on a déjà confiance et d’y incorporer le nouveau ‘ test de pertinence ’ pour s’assurer l’approche adoptée est la bonne pour le projet en question. Cela aidera les managers de projet à développer leur capacité professionnelle à choisir la meilleure approche pour un projet et prendre les bonnes décisions plutôt qu’être contraints à utiliser une seule et unique méthode.

QRP International est partenaire de DantotsuPM

Pourquoi mixer PRINCE2 et Agile ?

Le cocktail combinant PRINCE2 et Agile amènera les praticiens au-delà du simple ‘ posséder la connaissance ’ et les équipera de techniques pratiques pour démarrer. L’avantage d’utiliser les deux approches ensemble signifie que les managers de projet ‘ ne repartent pas de zéro ’ mais construisent sur leurs connaissances existantes.

Du point de vue d’une organisation, cela aidera à rentabiliser l’investissement fait dans PRINCE2 et adresser des secteurs où, parfois, cela ne convient pas tout à fait. En termes simplistes, cela permettra aux organisations d’être plus agiles en utilisant des approches qui aident à produire ce que veut l’utilisateur sans s’attendre à ce que l’utilisateur dise d’entrée de jeu “je sais ce que je veux”. Au lieu de cela, le projet peut présenter le résultat possible dans des livrables plus petits et les évaluer avec l’utilisateur pour démontrer ce qui est possible sans devoir décider du produit final dès le départ.

Cette façon de travailler permet d’apprendre rapidement, de manager plus efficacement les exigences des utilisateurs, de contrôler les dépenses et d’augmenter la probabilité de livrer le bon produit au final.

Partenaire de DantotsuPM

Dépasser la méthode : la promesse de PRINCE2 Agile

Tant dans PRINCE2 que PRINCE2 Agile, l’utilisation de l’approche dite de MoSCoW (classification des exigences projet entre : Must, Schould, Could et Won’t be included) est une façon pratique de donner aux managers de projet la capacité de retourner voir leurs sponsors et être explicites sur quels sont les éléments à fournir et selon quelles priorités.

Le manager de projet et l’équipe sont donc plus certains des besoins en ressources, des éléments à fournir par le projet et de comment tout cela s’aligne avec le cas d’affaires. Cela, à son tour, rend l’exécution du projet plus prévisible, plus sûre et en fin de compte avec davantage de chance de réussir.

Dans certaines formations PRINCE2, la technique de Moscow peut ne pas être détaillée à moins que les chefs de projet ne soient en position de prendre d’importantes décisions et cette approche peut donc être nouvelle pour ces managers de projet. PRINCE2 Agile comble le trou entre la théorie et la pratique avec une approche pour l’utiliser dans les projets qui devrait la rendre plus facile et plus fréquemment déployée.

Avoir la capacité d’aller au-delà du suivi d’une méthode ou une discipline et commencer à utiliser l’apprentissage résultant de l’expérience apportent extrêmement de valeur aux managers de projet. En fait, il s’agit de construire une plus grande compétence professionnelle, à long terme à travers la communauté des managers de projets et de programmes dans son ensemble.

‘Le 70-20-10’, le modèle d’apprentissage utilisé dans le secteur public correspond à 10 % pour l’étude en salle de formation, 20 % à apprendre des autres et 70 % par l’expérience. Cela signifie des managers de projet qui développent la capacité, par leur expérience aussi bien qu’études et obtention de qualifications, de gérer des projets plus complexes avec une plus grande confiance et meilleure efficacité. PRINCE2 Agile est un bon pont pour lancer les chefs de projet dans ce voyage vers l’application ce qu’ils savent.

Se concentrer sur le futur de la réussite de projet

Une nouvelle approche, comme la promesse de PRINCE2 Agile, accroit l’opportunité que les bons produits soient livrés pour répondre à un cas d’affaires. L’approche se fonde sur ce que l’on a déjà appris et devrait nous amener à progresser tant sur les  processus que les résultats réalisables. Pour des organisations considérant une aussi nouvelle approche, le critère de décision est simple : Obtenir un retour sur investissement.

Mais la volonté d’adopter une telle méthodologie exige la coopération des membres de deux communautés de pratiques tout à fait distinctes et leurs perceptions les uns des autres. La communauté Agile peut considérer PRINCE2 Agile comme inflexible alors que les praticiens PRINCE2 questionnent le niveau de contrôle avec des principes de livraison Agile.

Mais avec une compréhension des bénéfices mutuels sur le contrôle et la flexibilité, basée sur la communication claire de ces avantages, les deux camps devraient reconnaître la valeur que chacun peut apporter pour mener le projet au succès.

Clairement, la gestion du changement impliquant la dimension culturelle sera importante pour persuader des professionnels de projet que mixer PRINCE2 et Agile aura un impact positif sur leur travail dans le long terme.