Tag Archives: scrum

18 Janvier – Montréal – Introduction à l’Agilité

13 Jan

Cette introduction (ou ré-introduction) vise les vendus et les désabusés, les initiés et les nouveaux intéressés.

C’est un rafraichissement sur l’agilité qui permettra de faire un petit pas en arrière et mieux préparer les prochains. Pour certains, ce sera un retour sur les fondements de l’agilité et pour d’autres ce sera la satisfaction d’une curiosité qui perdure. Avec plus de dix ans d’expérience, l’agilité a maturée mais pourquoi reste-t-elle difficile à maitriser ?

  • bonhom-questionQu’est-ce donc que l’Agilité déjà ?
  • Quelle est la différence avec Scrum ?
  • Je fais quoi avec mon Gantt ?
  • Est-ce que le Web est un bon candidat ?
  • Pourquoi est-ce que je vis autant de difficultés ?
  • Par où dois-je commencer ?

Une recontre Agile Montréal !

Tous les détails

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Enregistrer

connaissez-vous les 12 principes Agile qui accompagnent les 4 composantes majeures du « Agile Manifesto » ?

10 Jan

Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste Agile, les connaissez-vous ?

Examining the Twelve Principles of Agile par The Clever PM

Beaucoup d’attention est portée au « Manifeste Agile » et bien qu’il soit une composante importante de Agile, ce n’en est pas toute la substance. Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste. Jetons un rapide coup d’œil à chacun d’entre eux et voyons combien ils affectent comment nous percevons et implémentons les pratiques Agiles…

1. Notre priorité la plus haute est de satisfaire le client par la livraison rapide et continue de logiciel de valeur.

bonhom-serviceCeci est l’aspect le plus important d’Agile qui doit être compris et adopté comme une partie de la culture de toute organisation qui veut être « Agile » : le client et l’utilisateur final sont le focus ultime du processus tout entier, du commencement jusqu’à la fin. Le client est le juge du succès ou de l’échec d’un produit ou d’une fonctionnalité, pas la société ni ses parties prenantes. Le client est celui avec les problèmes que nous adressons et comme tel il doit être partie intégrante du processus de développement de produit du commencement à la livraison.

Ignorer vos clients jusqu’à ce que votre produit soit prêt à être expédié est l’anti-modèle Agile numéro 1 dans le monde.

2. Accueillez avec bienveillance les demandes d changement, même tard dans le développement. Les processus agiles exploitent le changement pour donner un avantage compétitif du client.

changementsLa deuxième partie la plus importante de Agile est en fait…  …de faire preuve d’agilité. N’importe quelle organisation qui investit lourdement dans la définition en amont, la conception et la définition des besoins n’est Pas Agile…et ne fait certainement pas preuve d’agilité. Tout le point de l’agilité est que vous pouvez vous accommoder d’importants changements de besoins à n’importe quel point du processus et toujours livrer quelque chose qui est utile pour le client et résout un ou plusieurs de leurs problèmes. Des processus agiles s’appuient sur la Priorisation et non par la Négociation de contrat pour atteindre le succès. Quand de nouveaux besoins surviennent, ils ne sont pas soumis à de lourds et détaillés processus de management des changements.  Ils sont plutôt ajoutés à la pile de tout le reste à faire et évalués tout simplement comme une autre tâche ou histoire utilisateur déjà dans le processus.

Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin

Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin

Penser que les choses sont totalement ou presque entièrement définies à l’avance est un autre anti-modèle Agile dont beaucoup de sociétés souffrent fréquemment.

3. Livrez souvent (entre deux semaines et deux mois) du logiciel qui fonctionne avec une préférence pour les fréquences les plus rapides.

scrumIl y a plusieurs choses dans ce principe. D’abord du logiciel qui marche est le but du processus à chaque étape, ensuite le travail devrait être itératif et s’améliorer à chaque livraison et, finalement les itérations qui sont engagées devraient être les plus courtes possible. Si vous travaillez sur un projet qui progresse pendant six mois sans vérifier les résultats intermédiaires avec le client (ou son représentant), vous n’êtes pas Agiles. Si vous travaillez sur des itérations d’une semaine, mais ne livrez pas quelque chose qui résout au moins un problème client à chaque itération, vous n’êtes pas Agiles. Les itérations agiles doivent être assez longues pour livrer un logiciel qui fonctionne et assez courtes pour vous assurer que ce que vous livrez résout bien dans les faits des problèmes clients.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Travailler itérativement ne signifie pas nécessairement que vous êtes Agiles; l’itération est importante, mais livrer un logiciel qui fonctionne l’est tout autant.

4. Les gens du métier et les développeurs doivent travailler ensemble quotidiennement pendant tout le projet.

collaborateLa collaboration et les interactions entre les gens sont critiques au succès de toute organisation Agile. Les silos et le « jeté de besoins par-dessus le mur » sont contre-productifs aux approches Agiles, comme l’est de segmenter votre organisation entre les gens « du métier/business » et les « techniciens ». Tout le monde du côté « métier/business » devrait être prêt, consentant et disponible pour fournir autant de support que possible aux équipes « techniques » et vice versa. L’idée séculaire qu’il y a une certaine différence inhérente entre la façon dont « l’activité business » devrait être exécutée et la façon dont « la technologie » devrait l’être est entièrement artificielle et contre-productive dans un âge d’innovation rapide et de livraisons encore plus rapides.

Décourager la collaboration ou encourager le « silotage » des efforts est un anti-modèle Agile qui persiste dans trop de cultures d’entreprise.

5. Construisez les projets autour de personnes motivées. Donnez-leur l’environnement et le support dont elles ont besoin et faites leur confiance pour faire le travail.

Agile valorise les personnes en tant que personnes et les équipes en tant qu’équipes. Les gens  ne sont pas des rouages interchangeables que vous pouvez aléatoirement déplacer d’un projet à un autre et vous attendre à ce qu’ils excellent continuellement. Les individus sont motivés par des choses différentes et dans une vraie approche Agile nous exploitons ce qui motive individuellement les membres de notre organisation pour créer des équipes avec ces individus motivés qui sont intrinsèquement motivés pour réussir. Agile déboute de l’idée que la récompense extrinsèque fournit des résultats exceptionnels et se concentre plutôt sur l’assurance que les individus aient la motivation, l’environnement et les outils dont ils ont besoin pour réussir tout seuls. Il n’y a aucune approche de type « la carotte et le bâton » dans Agile. Il y a des problèmes à résoudre pour les clients qui sont intéressants et fascinants et qui sont résolus par des personnes qui ont l’intérêt nécessaire et la motivation intrinsèque pour les résoudre.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

Attendre des gens d’être performants simplement parce qu’ils sont membres « d’une équipe » et non pas parce que cette équipe partage la motivation intrinsèque de réussir est un anti-modèle extrêmement commun dans les grandes organisations.

6. La méthode la plus efficace et effective de transmettre des informations dans une équipe de développement est la conversation en face à face.

Business DiscussionLa méthode séculaire d’avoir un unique expert du sujet qui écrit tout qu’il veut avoir et le remet aux développeurs comme « une liste à exécuter » de besoins est hérétique aux approches Agiles. Des personnes différentes pensent et communiquent différemment et le texte écrit est l’une des pires façons d’exprimer que vous essayez de dire. Au pis-aller, c’est vague et difficile à déchiffrer pour la personne qui ne l’a pas écrit; au mieux, c’est un document clinique, stérile qui remplace le sentiment par la précision. Si le but est d’exprimer la douleur que ressent le client et motiver les équipes à exceller dans leur job parce qu’elles le veulent, alors aucune de ces approches par des besoins écrits n’aura le résultat que nous désirons. Nous utilisons plutôt des choses comme les Histoires Utilisateur, qui explicitent le problème que nous voudrions résoudre, mais qui permettent à notre équipe de développement d’utiliser sa créativité pour y répondre de la meilleure façon possible.

Même quand nous utilisons des outils pour suivre le travail et communiquer les informations les plus basiques, nous ne pouvons pas oublier que la façon la plus importante de communiquer l’un avec l’autre, indépendamment des rôles, est toujours la conversation en face à face.

7. Le logiciel qui marche est la principale mesure de progrès.

avis perso KPIsParticulièrement dans le monde des grandes sociétés, nous aimons le concept que tout peut être mesuré, évalué et KPIsé. Nous suivons les revenus, des points d’histoire, la vélocité, la consommation, les nombres d’erreurs découvertes, Ad Nauseum. Pourtant nous oublions souvent que ce que nous essayons vraiment de faire est résoudre des problèmes pour les clients. Et aucune de ces mesures n’indique combien de valeur nous apportons en réalité ni si nous résolvons vraiment des problèmes clients. Le but final de chaque itération devrait être du logiciel qui marche, qui fait quelque chose que nous pensons être de valeur. Sans cela, c’est un échec. Quoi que ce soit de plus que cela est du glaçage sur le gâteau. Les équipes Agile se mesurent elles-mêmes sur si elles apportent réellement de la valeur et si elles créent vraiment quelque chose qui marche la fin de chaque itération.

Répétons ceci : la vélocité n’est pas la mesure du progrès. La consommation n’est pas la mesure de progrès. Les points d’histoire ne sont pas la mesure de progrès. La capacité n’est pas la mesure de progrès. Les délais ne sont pas la mesure de progrès. La seule chose qui importe est combien vous créez de logiciel qui marche.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

8. Les processus agiles font la promotion du développement durable. Les sponsors, les développeurs et les utilisateurs devraient pouvoir indéfiniment tenir une allure constante.

Voir les billets sur l'initiative ecoPMI

Voir les billets sur l’initiative #ecoPMI

Il y a cette idée fausse dans le monde, tenue tant par les développeurs que par des hommes d’affaires, que Agile signifie aucune documentation, que Agile veut dire faire quoi que vous ayez besoin de faire pour atteindre un but, que Agile signifie changer les priorités et équipes rapidement pour assurer une production maximale, que Agile rime avec imprévisibilité et manque de prédictibilité. Le fait est, l’un des buts principaux d’Agile est créer un environnement de prévisibilité, de stabilité et une allure constante et acceptable de développement de produits qui dure indéfiniment. Il n’y a rien dans les principes Agile qui écarte de créer des planning (quoique ces plans portent un peu d’incertitude !) ni d’être capable de prévoir quand quelque chose pourrait être livré. Au contraire, il n’y a rien dans les principes Agile qui s’attend à ce que des développeurs s’engagent dans des comportements de pression exagérée. En fait, de tels comportements sont de bien des façons antithétiques aux concepts Agiles : si votre équipe doit travailler beaucoup trop durement pour livrer quelque chose, vous avez manqué en amont à vos devoirs de priorisation efficace des Histoires Utilisateur.

Aucune vraie pratique Agile ne devrait aboutir à de l’épuisement, des périodes critiques, ni une incertitude constante et prolongée. Les anti-modèles aboutissent à ces comportements contradictoires.

9. L’attention continue à l’excellence technique et à la bonne conception améliore l’agilité.

good and badDes équipes vraiment agiles ne rassemblent pas à la va vite de mauvais morceaux de code pour l’appeler « bon ». Elles prennent le temps et mettent les efforts nécessaires pour comprendre ce qu’elles essayent de réaliser, comment elles pensent pouvoir résoudre les problèmes et décomposer les choses en assez petits « morceaux » de travail pour à la fois itérer sur le problème et livrer des solutions potentiellement exploitables à chaque étape du projet. La majorité de ce travail se produit avant que les équipes ne s’engagent à faire le travail. Il y a là du pré-travail pour parler approches, pour discuter architecture et s’engager dans des discussions avec des représentants du métier, des parties prenantes et les équipes techniques. Nous nous référons souvent à ceci comme à des sessions de démarrage ou de préparation d’arriéré de produit mais Agile ne devrait jamais être une excuse pour la mauvaise qualité ou une conception erronée.

La conception erronée et de faibles standards aboutissent à de pauvres solutions qui ne répondent pas vraiment aux besoins clients; c’est un facteur de ralentissement, pas un facteur d’accélération.

10. Simplicité, l’art de maximiser la quantité de travail non fait, est essentielle.

construction progressive. Chaque brique apporte de la valeur.Beaucoup trop de personnes lisent ceci de la mauvaise façon et limitent ainsi leur capacité à totalement s’engager dans des pratiques Agiles fortes. Simplifier vos buts, vos histoires, votre travail et tout le reste est un processus qui commence par l’opposé : une très large compréhension de ce que sont les buts et de comment ils pourraient être atteints. Le résultat de tels efforts n’est pas nécessairement un projet plus petit, mais des incréments plus petits et plus simples qui peuvent s’additionner en quelque chose de très grand et qui peuvent aussi indirectement réduire les buts globaux. Le plus grand obstacle est ici que le simple est plus difficile que le complexe, particulièrement quand les gens s’engagent dans des séances de remue-méninges, ce qui arrive souvent avec des équipes techniques. Résolvez le problème d’abord, itérez ensuite par petits morceaux.

« Rendez chaque détail parfait et limitez le nombre de détails à perfectionner. » Jack Dorsey

11. Les meilleures architectures, besoins et conceptions naissent d’équipes auto organisées.

teamingLe mot clé est ici « naissent ». Quand vous réunissez les bonnes personnes et que toutes sont alignées vers les mêmes buts, certaines choses se produisent. D’abord, elles se tiennent naturellement responsables, parce qu’il y a un sentiment intrinsèque de camaraderie et de but commun. Deuxièmement, Elles se supportent et en même temps se défient pour assurer que le résultat final respecte non seulement leurs attentes individuelles, mais aussi leurs attentes collectives qui sont presque toujours plus élevées. Et finalement, elles  améliorent le tout par la collaboration : la valeur de n’importe quelle équipe auto-organisée est au moins 2 fois plus importante que la somme de ses parties individuelles. Le facteur clé est ici auto-organisation, qui peut être dure à vendre dans beaucoup d’organisations, mais les meilleures équipes ne sont pas celles assemblées par un cadre intermédiaire, ce sont plutôt des groupes de personnes qui ont choisi de s’aligner vers un but commun.

Les personnes qui travaillent vers un but commun parce qu’elles le veulent seront toujours plus efficaces, plus fortes et plus fiables que des équipes travaillant ensemble parce qu’on leur a dit de le faire.

12. À intervalles réguliers, l’équipe réfléchit à comment devenir plus efficace, puis règle et ajuste son comportement en conséquence.

Get the book on Amazon

Get the book on Amazon

Dans presque chaque organisation que j’ai observée face au défi d’implémenter les pratiques Agile, la plus grande chose qu’elle loupe est l’importance de l’amélioration continuelle ou continue. Agile a ses origines dans des concepts industriels LEAN : la valeur de l’individu, la primauté du résultat sur le processus et, plus important encore, le besoin de constamment mesurer, ajuster et améliorer comment vous faites ce que vous faites. Toute équipe qui veut ne pas s’engager dans les rétrospectives et les revues d’équipe avec leurs parties prenantes après chaque itération risque la stagnation et les anti-modèles parce qu’elle ne les voit jamais arriver. Beaucoup d’équipes voient ces sessions comme contre-productives, des pertes de temps, des exercices « soft skills » qui consomment seulement de leur temps d’exécution. Mais la plupart des équipes les évitent simplement par crainte (et le rationalisent comme elles le peuvent): la crainte d’être sur la sellette, la crainte d’accepter la responsabilité, la crainte de changement. La vérité vraie est que quand elles sont exécutées correctement, elles peuvent être les réunions les plus enrichissantes dans lesquelles les équipes s’engageront. Elles sont destinées à pousser les gens à constamment s’améliorer et être plus efficaces et il n’y pas de bonne raison de ne pas s’engager dans ces discussions.

L’absence de « regarder derrière soi » profondément et honnêtement pour évaluer comment une équipe avance et où elle peut s’améliorer est un anti-modèle fatal au succès de Agile sur le long terme.

Enregistrer

Enregistrer

24 January – Webinar ScrumPulse – Women In Agile: Empowering the Next Generation of Influencers

5 Jan

Have you wondered how a woman’s unique perspective can help organizations enable sustained business agility?

  • sourireWhat unique strengths do women bring to an Agile Transformation?
  • What challenges do women face in the Agile Industry and how can we inspire more women influencers?
  • What is the most important advice for a woman who wants to become an Agile Influencer?
  • How can we collectively foster the next generation of women in this industry?
CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Join the qualified, pioneering, international panel of Women Agile Influencers as they explore these questions, share their inspiring journeys and provide actionable tips to enable more Women Agile Influencers.

Scrum and Upcoming Agile Webcasts

Scrum and Agile Webcasts

This session will be moderated by Daphne Harris who will guide the conversations with panelists: Jill Graves, Patricia Kong, Pradeepa Narayanaswamy, Stacy Martin, and Stephanie Ockerman.

Register to attend this Webcast on Women in Agile

CSP est partenaire de DantotsuPM

CSP est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Image

plan du métro « Agile » par Deloitte

29 Déc

Merci à Olivier Lefebvre, PMP®, de m’avoir indiqué cette carte très intéressante à partager avec tous les « Agile addict » !

Version du plan animée par Karim Abdi (exampm) pour une meilleure lecture (les méthodes apparaissent les unes après les autres):

plan-metro-agile-animated

https://image-store.slidesharecdn.com/dba2e6e7-c5bf-404d-98f3-4db3531b1156-original.jpeg

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

19 janvier – Le Mans – Journée Agile

27 Déc

L’agilité, c’est quoi ?

L’agilité avec l’ensemble de ses valeurs, de ses principes, de ses méthodes et pratiques, se diffuse progressivement dans nos environnements de travail et dans l’enseignement.

le-mans-agile-2017Novices ou experts, curieux ou praticiens, venez donc partager et échanger sur des thématiques agiles telles que le Management Agile, la programmation agile, le Lean IT, Lean Startup, Scrum, Kanban, eXtreme Programming … ou encore l’enseignement en mode Agile.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

http://agile-mans.org/ Inscriptions gratuites

Enregistrer

Enregistrer

les articles les plus lus sur DantotsuPM en Juillet 2016

19 Déc

Plusieurs documents et des pointeurs vers des formations et du développement personnel en ce mois estival où les lecteurs avaient peut-être plus de temps pour réfléchir à comment développer leurs propres capacités et compétences.

Lean Project Management – Téléchargez ce guide gratuit

Si vous ne connaissez pas encore ce guide centré sur l’association du Lean Project Management et des projets de transformations organisationnelles, il n’est pas trop tard pour le lire !

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Scrum Valuesmises à jour du « Scrum Guide »

5 Valeurs : Courage, Focus, Engagement, Respect et Ouverture.

et si vous leviez la tête de ce diagramme de Gantt et preniez le temps de réfléchir ?

Prenez vous du temps chaque jour juste pour vous poser et réfléchir ?

Essayez Bubble Plan !

Essayez Bubble Plan !

Comment faire remplir les suivis de temps par votre équipe ?

Ces 3 étapes simples feront que votre équipe renseigne les suivis de temps…

rubix problem solutionAmenez-moi des solutions pas des problèmes : leadership versus management

Le leadership est une chose dont beaucoup d’organisations manquent.

les chefs de projets restent très recherchés

Selon le baromètre Expectra 2016, les chefs de projets font partie des 10 métiers cadres les plus difficiles à recruter

Les grands chefs de projet peuvent manager quoi que ce soit!

Les bons chefs de projet ont des compétences qui s’appliquent dans chaque profession liée au management.

Découvrez le MOOC d’introduction aux certifications professionnelles du PMI®

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Durée de Sprint, quelle est la bonne durée ?

16 Déc

Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie mais il y a 2 principes pour en déterminer la valeur optimale pour votre projet.

Sprint Length: What Length is the Right Length?

http://blog.3back.com/scrum-tips/sprint-length-what-length-is-the-right-length/ Par Docteur Dan Rawsthorne

hourglass-time-cloclk-deadline-sablierOn me demande souvent, ‘Combien de temps devrait durer un Sprint pour mon équipe ?’ Et ‘le Sprint doit-il être de durée fixe ?’. Je constate qu’il ne suffit pas de répondre : « N’y réfléchissez-y pas trop longtemps. Si vous utilisez un environnement raisonnable et un langage de développement comme Java ou dot-net, utilisez une durée de Sprint de deux semaines. Cela semble marcher pour la plupart des équipes, mais certains utilisent une semaine ou trois semaines. Voyez simplement ce qui vous convient. »

Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie.

Deux principes sur la durée

Il y a deux principes pour déterminer la durée d’un Sprint.

  1. Le Sprint ne devrait pas être changé après son démarrage.
  2. Les Sprints devraient être de même durée.
Ne pas se mentir à soi-même ni à l'équipe

Ne pas se mentir à soi-même ni à l’équipe

Je pense que la première règle est claire et directe. Ce serait tricher que de changer la durée du Sprint après qu’il ait commencé. Si l’équipe ferme les yeux sur le changement de la durée de Sprint, elle sera tentée de changer la définition de « Done » pour permettre certains changements de contenu. Ceci est une mauvaise chose: La chose correcte à faire est d’ajouter une autre histoire utilisateur (User story) à l’Arriéré de produit (Product Backlog).

Quant aux Sprints devant tous être de même durée, c’est un peu plus délicat. J’ai déjà dit qu’un Sprint de démarrage pourrait être de seulement une semaine, donc, clairement je ne suis pas totalement inflexible sur le fait que tous les Sprints devraient être de même durée. Puisqu’un Sprint est une boucle de retour d’information, l’équipe doit prendre en compte les parties prenantes. Avoir une durée de Sprint fixe donne aux parties prenantes un rythme constant pour les revues de livrables, ce qui est réconfortant et installe une routine familière. Cependant, avoir des durées de Sprint différentes pour des Sprints spécialisés, comme la prise en compte des périodes de fêtes (ou des vacances), ou une autre raison dont l’équipe et les parties prenantes peuvent convenir, ne me semble pas être une terriblement mauvaise chose.

Est-ce assez long ?

estimate durationUn Sprint doit être assez long pour vraiment achever des histoires (user stories). C’est-à-dire l’équipe doit pouvoir amener ses histoires jusqu’à leur état fini (« done »). C’est une règle dans Scrum qu’un Sprint ne devrait jamais excéder un mois. En général, la longueur de Sprint devrait être approximativement de trois fois le temps nécessaire à analyser et réaliser totalement une histoire de taille moyenne. Ceci semble donner assez de flexibilité dans le système pour permettre à l’équipe de s’auto-organiser pour obtenir un travail fini. Mon expérience est qu’une histoire prend environ 2-3 jours pour une équipe typique qui est bien en place, donc une longueur de Sprint raisonnable est deux semaines. Cependant, les environnements sont différents; certains sont plus faciles (ou plus difficiles) que d’autres. Je m’attends donc à ce que les longueurs de Sprint d’une équipe varient largement en fonction de ces différences d’environnement.

Est-ce assez court ?

La durée de Sprint devrait être suffisamment courte pour que le changement d’avis sur les besoins soit plus lent que la durée du Sprint. C’est-à-dire, si la durée de Sprint est de deux semaines, l’équipe espère que les changements de besoins arrivent plus lentement que toutes les deux semaines. Ce qui veut dire que les parties prenantes peuvent attendre jusqu’à la fin du Sprint pour voir leur ‘nouveau truc’ délivré avant de vouloir le changer.

finiDans l’environnement business actuel, il est typique que la modification de besoins soit trop rapide pour le Sprint. Il y a des bogues à réparer dans d’autres systèmes que l’équipe maintient, il y a des cas d’urgence partout dans l’organisation à fixer et les parties prenantes changent presque constamment d’avis sur ce qui est important. Ce sont autant de raisons pour que l’équipe raccourcisse la durée de Sprint ou celle du cycle de planification.

Des choses se produisent et les équipes développent des méthodes pour manager le fait que des besoins devraient être changés plus d’une fois par Sprint.

Soyez ouverts à re-planification

Parfois la durée de Sprint d’une équipe est juste trop longue pour que survivent les accords pris : la fréquence de changement des besoins est plus rapide que la longueur de Sprint ne peut le supporter. Il est tentant d’essayer de raccourcir les Sprints, mais peut-être n’est-ce pas faisable parce que les parties prenantes ne peuvent pas manager des revues plus fréquentes, ou parce que l’équipe ne peut pas développer plus rapidement.

Essayez Bubble Plan !

Essayez Bubble Plan !

Que fait l’équipe ?

Scrum n’est rien sinon adaptatif. En fait, si l’équipe ne s’adapte pas pour respecter ses propres réalités, ce n’est pas du Scrum. Alors, adaptez-vous… l’équipe pourrait avoir des sessions de planification de Sprint plus fréquentes – peut-être une fois par semaine.

Par exemple, si l’équipe a une durée de Sprint de deux semaines, du lundi au vendredi deux semaines plus tard. Alors, l’équipe pourrait planifier chaque lundi, et non pas seulement un lundi sur deux. Le premier lundi l’équipe remplirait son Sprint à environ 80 % de sa capacité et le deuxième lundi les membres de l’équipe se poseraient la question : « qu’ajoutons-nous maintenant ? »

Je constate que beaucoup d’équipes se sont spontanément déplacées vers ce système, donc c’est un modèle connu qui est très efficace. Il devrait faire partie de la boîte à outils du ScrumMaster.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

14 December – Webinar (ScrumPulse) Software Craftsmanship in Professional Scrum

7 Déc

What is the role of software craftsmanship in the practice of Professional Scrum?

Scrum and Upcoming Agile Webcasts

Scrum and Upcoming Agile Webcasts

What separates Professional Craftsmen from those who are just hacking around?

How do Professional Craftsmen exhibit the Scrum Values of Courage, Focus, Openness, Respect and Commitment?

Our diverse panel of Professional Scrum Trainers will share their take on what lies at the intersection of Software Craftsmanship and Professional Scrum. They’ll dive into what software craftsmanship means to them and share guidance anyone can use on their journey toward Technical Excellence.

Register to Attend Webcast on Agile Transformations

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Enregistrer

Chef de projet, Manager, Leader… lisez pour enrichir vos compétences et élargir vos horizons

2 Déc

Vous êtes déjà chef de projet ou souhaitez le devenir. Vous voulez améliorer vos compétences en leadership, Agile, management, projets, soft skills, …

Voici quelques livres qui sauront vous être utiles ! Profitez de la période de Noël pour vous les (faire) offrir 🙂

Soft Skills

L’entreprise du vivre-ensemble de Yves Cavarec L’étroit chemin vers un meilleur vivre-ensemble.

C’est (vraiment ?) moi qui décide de Dan Ariely. Les raisons cachées de nos choix

Being Alone Sucks!

Une référence sur ce sujet

Une référence sur ce sujet

Riding the Waves of Culture: Understanding Diversity in Global Business de Fons Trompenaars et Charles Hampden-Turner. Une analyse les causes profondes des malentendus qu’on observe souvent au sein d’équipes multiculturelles et des propositions de solutions concrètes

Talent Making People Your Competitive Advantage

Booster l’intelligence collective La stratégie agile de transformation durable des organisations

Coaching for Emotional Intelligence The Secret to Developing the Star Potential in Your Employees

Storytelling about YourBrand Online & Offline de Bernadette Martin – Comment améliorer votre e-réputation

DARE : Straight Talk on Confidence, Courage, and Career for Women in Charge de Becky Blalock pour davantage de conseils pour booster votre confiance.

Eloge de la gentillesse de Emmanuel Jaffelin car « Les gens gentils sont en meilleure santé… »

People Styles at Work and Beyond par Robert Dorothy Bolton pour apprendre à reconnaitre la personnalité et les styles de comportement des gens et mieux travailler avec eux.

Managez dans la joie au bénéfice de la performance avec Paul-Hervé Vintrou

Son livre

Son livre

L’Auto-coaching efficace selon Yann Coirault, CSP Formations, Coach certifié, MBTI®

Les 5 clés pour prendre les bonnes décisions par Yann Coirault et Pia De Buchet, car loin d’être le seul fait de la raison, les décisions sont largement influencées par les émotions et l’intuition.

Sun Tzu : de l’art de la guerre à l’art de diriger une version française commentée par Germain Domitille

Aujourd’hui, j’arrête de tout remettre à demain par Patrice Ras, conférencier et formateur en développement personnel

Morphopsychologie : Le visage, miroir de la personnalité par Patrice Ras

Quiet: The Power of Introverts in a World That Can’t Stop Talking de Susan Cain pour changer son regard sur les introvertis

Liberté & Cie : Quand la liberté des salariés fait le succès des entreprises de Brian M. Carney et Isaac Getz, pour découvrir le concept de l’entreprise libérée

Political Dilemmas at Work de Gary Ranker, Mike Phipps, Colin Gautrey. Car, « Votre patron est parti et son successeur doit encore être nommé. Soudainement personne n’est tout à fait sûr de quoi faire », sauf VOUS.

Manager les e-comportements de Jean-Michel Rolland. Technopathe, technophile, technophobe… comment motiver les collaborateurs 2.0 ?

Right-Brain Project Management de Michael Aucouin qui explique comment nous prenons des décisions basées sur comment nous ressentons les résultats potentiels.

Techniques et innovation

PVaR – Project Value at Risk A new indicator for connecting risks to the most important questions in project management: when will the project be completed and at what cost?

L’innovation frugale Comment faire mieux avec moins?

Manage Your Job Search

Reinventing Communication de Mark Phillips avec des études de cas concrètes.

Ma bible pour préparer des présentations mémorables

Ma bible pour préparer des présentations mémorables

Presentation Zen Simple Ideas on Presentation Design and Delivery

Social Media for Project Managers

Faisabilité de projets Aspects oubliés de l’analyse

Agile Retrospectives Making Good Teams Great

Visuals Matter! Designing and Using Effective Visual Representations to Support Project and Portfolio Decisions

The Myths of Innovation de Scott Berkun parce que « La majeure partie de ce que nous savons de l’innovation est erronée »

4 leading publications on cloud computing de Bernard Golden dont “Amazon web services for dummies”

Project Management for competitive advantage du Dr Paul Gardiner (Directeur scientifique des MSc PPMBD de Lille)

Organizational Project Management de Rosemary Hossenlopp sur la cohérence entre stratégie et projets

Organizational Enablers for Project Governance How Governance drives business success and influence project work, efficiency, and profitability.

Le livre sur Amazon

Le livre sur Amazon

Illuminate Ignite Change Through Speeches, Stories, Ceremonies and Symbols

Real Project Management de l’incontourtable Peter Taylor

Lecteurs, à vos marques : lisez vite et bien, Stimulez la mémoire par Élisabeth Rochefort, Consultante spécialisée en Efficacité professionnelle et communication orale et écrite.

Mieux lire la presse et les livres : 70 exercices rapides et efficaces par Élisabeth Rochefort pour aiguiser son sens critique et sa réflexion personnelle.

Applied Software Measurement: Global Analysis of Productivity and Quality de Capers Jones à lire pour les chefs de projets dans le logiciel car la productivité chute pour tous les types de projets lorsqu’ils excèdent 1000 points de fonction.

Managing Software Debt de Chris Sterling car quand les délais sont trop compressés, ils seront néanmoins respectés mais au sacrifice du design, de la planification ou de la qualité, et il se peut alors que vous accumuliez une dette.

The Mythical Man-Month de Frederick Brooks. En général, les chefs de projets ont entendu parler de la loi de Brooks mais en connaissent-ils les détails.

Project Management Implementation as Management Innovation: A Closer Look de Janice Thomas, PhD er Svetlana Cicmil.

Project Workflow Management: A Business Process Approach de Dan Epstein, Richard Maltzman

The Resource Management and Capacity Planning Handbook de Jerry Manas

Sustaining and Developing Disciplinary Expertise in Project-Based Organizations de Cecilia Enberg and Karin Bredin

Références et référentiels

Guide Du Corpus de Connaissances de L’Analyse D’Affaires (Guide Babok)

The Standard for Program Management La 3ème édition du guide du Project Management Institute

Implementing Organizational Project Management: A Practice Guide

Le PMBOK guide en français

Le PMBOK guide en français

PMBOK: Les éditions imprimées

La méthode Prince2 par Christian Descheemaekere – Prince2 en Français !

structures de répartition de travail (Work Breakdown Structures Practice book : WBS)

Portfolio management the Standard by PMI®

PgMP® Exam Preparation Study Guide de Jean Gouix et Martial Bellec avec 220 Practice Questions & Answers

PMI-ACP Exam Prep Comme le nom l’indique, le livre du PMI pour préparer la certif en Agile du Project Management Institute

Pratiques du management de projet, 40 outils et techniques pour prendre la bonne décision par Vincent Drecq, une référence en français.

L'une des publications de Michael Porter

L’une des publications de Michael Porter

Competitive Advantage de Michael E. Porter

Critical Chain de Eliyahu M. Goldratt, le texte fondateur de la méthode de La Chaîne critique

Quality is Free de Philip B. Crosby affirme que gérer la qualité correctement ne coûte ni temps ni argent mais permet au contraire d’en sauver.

Outliers de Malcolm Gladwell avec la règle des 10,000 heures qui pourrait ne pas toujours aboutir au succès dans le domaine du management de projet.

To Sell is Human de Daniel Pink pour mieux preparer vos cas d’affaire / business cases.

Retours d’expérience

Les héros de la stratégie 250 conseils pratiques de cadres supérieurs de BT, Coca-Cola, Lockheed Martin, eBay et d autres.

the power of lessThe Power of Less de Leo Babauta How to know what you want, and what you need!

Makers and Takers The Rise of Finance and the Fall of American Business

Project Management demystified de Geoff Reiss An introduction to project management.

Sidestep Complexity Project Management for Small- and Medium-sized Organizations

A History of Murphy’s Law de Nick Spark

Winning in Business with Enterprise Project Management

Megaprojects and Risk: An Anatomy of Ambition de Bent Flyvbjerg

Piloter un projet comme Gustave Eiffel : Comment mener un projet contre vents et marées de Anne Vermès

La Chaîne Critique en Pratique par Isabelle ICORD, experte de la pratique de la Chaîne Critique et à l’origine des toutes premières implémentations pratiques de ce concept en France.

Un livre de référence sur ce sujet

Un livre de référence sur ce sujet

The Lean Startup How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

Project Management for the Non-Project Manager de David Ottenstein car cela pourrait être votre cas ou celui de l’un de vos proches.

Le plus petit pas de Nicolas Gouy pour l’histoire d’une transformation Agile, Scrum et XP à grande échelle.

Talent Is Overrated de Geoffrey Colvin. Parce qu’être capable d’exécuter une activité n’est en rien une garantie que vous la ferez bien, et encore moins que vous vous y améliorez.

The Travels and Adventures of Serendipity A Study in Sociological Semantics and the Sociology of Science

Leadership

The Strategic Project Leader Mastering Service-Based Project Leadership

Turn the Ship Around! A True Story of Building Leaders by Breaking the Rules

get the book

Superbosses How Exceptional Leaders Master the Flow of Talent

Taming Tigers Do things you never thought you could

Des étoiles brillantes aux étoiles… filantes Les talents de Maurice Thévenet

Advocates & Enemies How to Build Practical Strategies to Influence Your Stakeholders

Secrets of Great Leaders 50 Ways to Make a Difference

Committed Teams Three Steps to Inspiring Passion and Performance

A Project Manager’s Guide to Influence de Colin Gautrey

What to Ask the Person in the Mirror : Critical Questions for Becoming a More Effective Leader and Reaching Your Potential (Anglais)

Hidden Strengths de Milo et Thuy Sindel pour développer les gens qui délivrent les résultats en rendant leurs bonnes compétences excellentes.get the book

The Lazy Winner de Peter Taylor à lire après The Lazy Project Manager

Leadership Principles for Project Success de Thomas Juli, que j’ai eu le plaisir de rencontrer à plusieurs évènements du PMI.

The Power of Project Management Leadership de Laszlo A. Retfalvi car tous les projets, du plus petit au plus grand, nécessitent une forte dose de leadership.

The Energy Bus de Jon Gordon pour générer plus d’énergie dans l’équipe projet que vous n’en consommez.

L’accordeur de talents de Jean Pierre Doly, pour de nouvelles organisations et nouvelles façons de travailler.

Booster l’intelligence collective de Olivier D’Herbemont car tous les jours on nous parle de l’Intelligence Collective, qui en rassemblant toute une communauté de personnes autour de défis complexes, engendre des résultats étonnants et novateurs. Mais qu’est-ce que cela signifie réellement?

Agile

The Science of Successful Organizational Change How Leaders Set Strategy, Change Behavior, and Create an Agile Culture

Livre sur Amazon

Livre sur Amazon

Essential Scrum A Practical Guide to the Most Popular Agile Process de Kenneth S. Rubin

Du management au leadership agile de Cécile Dejoux

Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise

PMI-ACP Exam Prep Comme le nom l’indique, le livre du PMI pour préparer la certif en Agile du Project Management Institute

The PMI-ACP Exam How to Pass on Your First Try

Being Agile in a Waterfall World A practical guide for complex organizations

Booster l’intelligence collective La stratégie agile de transformation durable des organisations

Team of Teams New Rules of Engagement for a Complex World

Agile Retrospectives Making Good Teams Great

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

La certification agile version PMI®, PMI-ACP®: Mon retour d’expérience, par Martial Bellec

8 Nov

La certification agile version PMI®,  PMI-ACP®: Mon retour d’expérience, par Martial Bellec PMP, PgMP, PMI-ACP, C2MPC

Martial Bellec

Martial Bellec

Hello,

Le 25 Octobre, j’ai passé avec succès la certification PMI-ACP®, en candidat libre, c’était ma première tentative.

Pourquoi ?

Ce qui m’a motivé au départ, c’est que PMI a opté, non pas pour créer une méthodologie agile de plus, mais pour favoriser l’acquisition d’une bonne connaissance générale des méthodologies et une connaissance approfondie du fameux « mindset agile ».

Pour la préparation, j’ai passé environ 50 heures entre le 19 août et le 25 octobre

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Cours

J’ai suivi un cours Scrum de 3 jours mais je suis resté sur ma faim pour la certification car je connaissais déjà Scrum. Le bon point néanmoins est que cette formation ouvre droit aux 21 heures de formation nécessaires au dossier PMI.

Je n’ai pas suivi de cours de préparation PMI-ACP®, les dates étaient trop tardives par rapport à mon objectif de passer en 2 mois.

Dossier
Le livre sur AmazonConcernant le dossier d’éligibilité, étant déjà PMP®, cela a été facile à remplir en mentionnant mes 3 projets agiles au cours des 2 dernières années.

Comme je dirige un projet agile en même temps, j’étais toujours en interrogation entre la vraie vie et la théorie, c’est très efficace comme toujours !

 

Lectures
Révisions de dernière minute

J’ai passé le dimanche avant l’examen à faire des questions et à butiner toutes ces références qui se contredisent quelques fois…

L’examen

Il est moins important de bachoter que pour le PMP, car:

  • ACPPratiquement aucune question ne porte sur les définitions ou bonnes pratiques (les fameux ITTO « Inputs, Tools, Techniques and Outputs » du PMBOK Guide). Pour l’agile ça aurait pu être par exemple : dans une rétrospective, quel est l’agenda à suivre ? Data gathering, issues identification, prioritization and improvement plan. Mais rien de ça !
  • si vous voulez être testé sur vos connaissances des nombreux outils agiles : comment écrire un bon user story (INVEST), ou bien tenir votre backlog (DEEP), passez votre chemin ! Vous ne serez pas testé là-dessus non plus.

En revanche, pratiquement TOUTES les questions sont des questions situationnelles, ou les rôles sont (très habilement selon moi) intriqués.

Les situations décrivent n’importe qui concerné de près ou de loin par le projet agile
  • Agile 2Agile practitioner
  • Product owner
  • Sponsor
  • Stakeholder
  • Project manager, qui est, selon la question Scrum master ou relais avec les execs

Les « objets » agiles sont toujours les mêmes et assez basiques : product backlog, risk, priority, value, kanban, Ishikawa… attention cependant au risk-adjusted backlog.

Dans une situation particulière, cette personne concernée par le projet Agile doit choisir parmi 4 possibilités ce qui est le mieux à faire immédiatement.

entrepreneur globalComme tout est en anglais, chaque mot compte. Attention il faut avoir un bon niveau d’anglais, même si le vocabulaire est « globbish »… il faut savoir très rapidement en comprendre le sens.

Généralement, il reste 2 réponses entre lesquelles il est difficile de trancher mais en relisant patiemment, la bonne apparaît enfin et semble alors évidente.

J’ai répondu aux 120 questions en 2 heures 6. J’avais environ 30 questions marquées et j’ai pu également repasser en revue les 80 premières d’ici  la fin des 3 heures allouées.

Les facteurs clefs de succès

Selon moi, il faut très bien comprendre le Agile manifesto et l’agile mindset et l’avoir déjà pratiqué sur des projets difficiles est un plus.

Je me suis entraîné à un memory dump de 5 minutes (pour occuper utilement les 15 premières minutes de l’examen qui sont en fait une démonstration de l’interface utilisateur PROMETRIC):

  • writing notes learnmanifesto,
  • xp,
  • Kanban,
  • Scrum,
  • acronymes,
  • evm,
  • Dreyfus,
  • Shu ha ri,
  • lean principles

Mais ça a peu servi pendant l’examen, le seul avantage est que je vais désormais me servir de cette carte au quotidien !

En conclusion

Je recommande cette certification car elle complète très bien le PMP®. Elle est aussi plus exhaustive que la scrum alliance, car PMI a une approche GENERALISTE (très bonne culture agile et des méthodologies).

Je suis enfin intimement convaincu, dans un contexte client, que le chef de projet de demain devra fonctionner indifféremment en waterfall et/ou agile sans les opposer mais plutôt en comprenant finement les avantages et inconvénients des 2 dans la situation réelle.

Cette hybridation des méthodes est un vrai challenge pour notre profession et PMI-ACP® me semble être un incontournable sur cette route.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Note : PMI, PMP et PMI-ACP sont des marques déposées de Project Management Institute, Inc.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

%d blogueurs aiment cette page :