Catégorie : agile

Méthodes, retours d’expérience, bonnes pratiques

Le Chef de Projet Agile : « Échouer MAINTENANT » pour stratégie

Le par mopertodans agile, experience sharingLaisser un commentaire
Robert ‘Bob’ Galen

The Agile Project Manager—Fail NOW as a Strategy

http://www.projecttimes.com/robert-galen/the-agile-project-managerfail-now-as-a-strategy.html

Par Robert ‘Bob’ Galen

J’étais à une conférence il y a peu de temps parlant et partageant sur divers sujets agiles. Comme il arrive souvent, un jeune homme m’a arrêté afin de me poser quelques questions après ma présentation. Nous avons entamé une conversation agréable qui a finalement débordé jusqu’au corridor de l’hôtel.

Nous avons commencé à parler de la dynamique de sprint dans des équipes Scrum et je suis arrivé de mentionner que je coache souvent des équipes vers la déclaration de leurs sprints en tant que succès ou… (pause pour plus d’effet) échec. Que nous faisons ceci comme partie intégrante de la revue de Sprint avec les équipes, le Propriétaire de Produit étant le décisionnaire final en se basant sur selon que l’équipe a atteint les Objectifs de Sprint ou pas.

échecIl a été visiblement énervé par mon avis. Il a dit qu’ils (il travaillait dans une société bien connue d’Atlanta) n’avaient jamais échoué de sprint. Jamais! Ils ne pouvaient pas, ni n’utilisaient ce MOT dans leur culture. Je lui ai demandé catégoriquement : n’avez-vous jamais échoué un sprint ? Il a dit bien sûr qu’ils l’avaient. Plusieurs fois. Mais au lieu d’utiliser le terme échec, ils ont utilisé le terme ‘challenge’. De cette façon, les parties prenantes ne se feraient pas de fausse idée et ne mettraient pas en doute les compétences ou la motivation de l’équipe.

Nous avons tourné en rond pendant 10 à 15 minutes de plus dans notre discussion, mais nous n’avons jamais vraiment réglé nos différences. Nous avons simplement consenti à être en désaccord. Bien que ce ne soit pas un terriblement large abîme entre nous, je me rappelle distinctement revenir vers ma chambre en secouant la tête. Je n’avais tout simplement pas compris le grand cas fait de l’échec. De l’utilisation du mot. D’une équipe disant…nous avons échoué. Dans mon job de coach et dans mes « tâches journalières », j’ai pu diriger et développer nos idées pour que l’échec ne soit pas un gros mot. C’est-à-dire l’échec est bon. L’échec est ok. L’échec mène à l’amélioration. L’échec fait partie de la vie.

Aussi, dans ce billet, je veux discuter de l’échec depuis quelques perspectives différentes. La discussion n’est pas destinée à être complète. Au lieu de cela, je veux juste partager quelques pensées avec vous et vous faire réfléchir sur l’échec… sur comment vous le percevez dans votre organisation, quelle est votre tolérance à l’échec et reconsidérer vos réactions normales face à lui. Je pense que cela vous mènera aussi à considérer votre management de risque, parce que je pense que les deux sont inextricablement liés.

Coacher pour éviter l’échec

chuteDans son blog du 20 juin 2011, s’intitulant Coaching is Not Letting Your Teams Fail (Coacher c’est ne pas laisser vos équipes échouer), Giora Morein justifie que des coach agiles devraient amener ou guider leurs équipes loin de l’échec. Il donne l’analogie d’un Sherpa guidant des alpinistes. Et oui, dans l’exemple de l’alpinisme en montagne, je dois reconnaître que l’échec n’est probablement pas le résultat que nous voulons.

Cependant, dans les environnements qui ne mettent pas la vie en danger, je pense que je ne suis pas d’accord avec Giora. Je crois de tout cœur que l’échec peut en réalité être bon pour une équipe. Je pense aussi que le rôle du coach est d’aider une équipe à regarder sa performance de deux perspectives. La plus facile des deux est la perspective de succès. C’est la perspective où vous donnez un retour d’information positif à l’équipe; où vous leur dites qu’ils ont besoin de répéter les pratiques qui marchent pour eux. En fait, quelles pratiques ils doivent amplifier et faire « davantage » afin d’atteindre des résultats de plus en plus importants.

Ces conversations sont clairement plus faciles.

Mais en ce qui concerne la perspective d’échec ? Comme coach, fournissez-vous une critique constructive ? Montrez-vous à une équipe où ils ont trébuché ? Tant individuellement que comme une équipe ? Je pense que vous le devez. Mais certainement pas de façon malveillante ou maladroite. Je pense si vous coachez efficacement une équipe vous devez explorer leurs erreurs et faux pas avec la même passion et énergie que quand vous traitez leurs succès.

Et je ne pense pas que vous le faites tranquillement, en vous cachant derrière des portes et sans reconnaître de leurs challenges. Non. Je pense que vous l’approchez de façon totalement transparente et pratique. En établissant au départ que l’échec est apprécié et bien accueilli. Que depuis l’échec, vos équipes cherchent des possibilités d’amélioration et avancent rapidement vers l’atteinte de meilleurs résultats.

Exposition Agile

retrospectiveDans des équipes agiles, il y a deux cérémonies clés qui sont concentrées sur les résultats réussis ou pas de l’équipe. Dans Scrum, c’est la Revue de Sprint (la démonstration) et la Rétrospective de Sprint (les leçons apprises). Typiquement la revue de sprint est exposée au monde, donc vous pourriez vouloir être prudents sur comment vous énoncez vos échecs – pour que les parties prenantes n’interprètent pas mal l’impact ou l’effort consenti par l’équipe. Néanmoins, je crois que vous devriez déclarer des sprints succès ou échecs pendant l’introduction à la revue d’équipes.

Dans Scrum, c’est le rôle des Propriétaires de Produit de déterminer cela. Et c’est relatif aux objectifs sur lesquels l’équipe s’est engagée au début du sprint. On espère que ces objectifs étaient assez flexibles pour permettre à l’équipe d’ajuster leur travail pour les atteindre avec créativité.

Par exemple, je pense qu’un très mauvais objectif de sprint est quelque chose autour de l’équipe livrant un nombre d’histoires utilisateur – ou autres indicateurs d’exécution par cœur. Je pense que cela mène à un en-sablage potentiel de la part de l’équipe pour atteindre un but numérique plutôt que de penser au vrai problème qu’ils essayent de résoudre. Au lieu de cela, je pense que de meilleurs buts tournent autour de la réalisation d’une sorte de démonstration d’un comportement qui résout un jeu spécifique de problèmes clients. Donc le succès est mesuré sur comment l’équipe a respecté l’esprit de l’objectif et combien ils ont appliqué les principes agiles dans leur exécution.

Par exemple, j’ai vu des équipes qui s’engagent sur 10 histoires utilisateur, mais qui avaient 3 jours de temps mort à la fin de leur sprint, rater leur sprint. Pour sûr, ils ont bien livré par rapport à leur engagement, mais leur engagement était faussé. Ils s’étaient protégés et avait surestimé. De plus, ils n’ont pas fait part de leur capacité supplémentaire disponible à leur Propriétaire de Produit ni demandé davantage de travail dans leur sprint. Au lieu de cela ils ont planifié d’avance ou « plaqué or » leurs produits.

J’ai aussi vu des équipes qui s’engagent sur 10 histoires, mais en livrent 7 et ont un sprint très réussi. En cela qu’ils travaillent dur dans la complexité et l’adversité. Ils sont incroyablement transparents et engagent leur Propriétaire de Produit à faire des ajustements quotidiens sur les priorités en fonction de leur actuelle compréhension de leur capacité. Et en tant qu’équipe, bien qu’ils n’aient pas livré la quantité prévue à l’origine, ce qu’ils ont vraiment livré est aligné sur leurs objectifs et respecte l’esprit et l’intention du Propriétaire de Produit.

Ces deux cas devraient être discutés pendant la rétrospective des équipes et les façons de s’améliorer discutées. Pas de petite façon et sans ignorer les premiers troubles du comportement de l’équipe. Non. Tout cela, le bon, le mauvais (erreurs et échecs) et idées d’amélioration significatives, sera discuté pour que l’équipe décide de quels points sont dignes de leur attention pour amélioration dans le sprint suivant.

Mais l’échec est-il apprécié ?

scrum methodologie agileEn continuant sur mon exemple de coaching précédent, je me souviens qu’il n’y a pas longtemps je parlais à un groupe de nos Scrum Masters dans mon « travail de jour » chez iContact. Si vous ne connaissez pas Scrum, le Scrum Master est le coach et le guide principal et la voix du leadership agile dans l’équipe Scrum agile. Il est aussi responsable d’entretenir des valeurs agiles clés dans l’équipe et e la performance générale des équipes. Ce que j’entends par cela est qu’il guide les équipes vers une performance qui s’améliore dans la durée. Posant continuellement des questions comme : son équipe s’améliore-t-elle dans sa performance globale ? Sa vitesse s’améliore-t-elle ? Sa qualité de travail s’améliore-t-elle ? La collaboration et le travail en équipe s’améliorent-ils ? Et, leur focus est-il sur l’amélioration de la valeur livrée pour le client ?

Donc mon point auprès des Scrum Masters était que  j’estimais que nous n’avions pas échoué depuis quelque temps. J’ai défini l’échec dans ce cas comme un échec de sprint ou un incident dans lequel une équipe s’est essentiellement heurtée à un obstacle et a eu besoin de re-planifier ou revoir l’alignement son sprint.

Ils ont tous été d’accord avec moi que les choses s’étaient déroulées sans à-coups. Et j’ai reçu plus que quelques regards interrogateurs fixes quant à pourquoi c’était un problème. J’ai essayé d’être prudent dans ma réponse, mais ma préoccupation était qu’il se pourrait que nous la jouions un peu trop sûrs. Que nous devenions complaisants dans nos pratiques agiles et que nous ne nous challengions pas assez. Que nous ne tentions rien. Et ne courrions pas de risques.

J’ai expliqué que ces caractéristiques sont fondamentales pour la croissance et la progression d’équipes agiles. Et le fait que nous ne rencontrions pas d’échecs indique que nous avons atteint un plateau dans notre croissance et notre performance. J’ai estimé que c’était un problème…et pour lequel j’ai demandé s’ils pourraient obtenir davantage d’échecs des équipes.

Pouvez-vous imaginer le reste de cette discussion ?

Me voilà le Directeur de R&D dans une société qui réussit en train de parler à mon équipe de Scrum Masters et leur demander d’amener plus d’échecs, pour inciter leurs équipes à davantage de prise de risques et inspirer des objectifs plus agressifs. Le point que j’essaye de faire passer est que j’apprécie vraiment l’échec. Que j’ai appris à le voir comme un critère critique de succès et que son absence est un problème pour moi. Je me demande combien d’organisations et de leaders ont la même position.

La notion de « Chuter en avant »

Un de mes auteurs préférés est John C. Maxwell. Il est relativement bien connu comme un coach en leadership et un prolifique auteur avec plus de 50 livres sur divers sujets de leadership. Il a un fort contexte Chrétien dans sa vie et dans son écriture, mais si vous n’êtes pas aussi enclins, ne laissez pas cela vous rebuter. Il maîtrise pleinement l’art du leadership.

risques de succèsIl y a quelques années il a publié un livre : Failing Forward—Turning Mistakes Into Stepping Stones to Success. Dans celui-ci, il souligne l’échec comme un facteur de réelle transformation dans nos vies personnelles, professionnelles et en équipes. Mais il place soigneusement l’échec dans une position d’avancée. Au lieu de voir l’échec comme un état final négatif et nous en plaindre, nous devrions l’embrasser comme une expérience à portée pédagogique positive. Que nous nous « penchions en avant » en démultipliant les leçons apprises pour nous améliorer.

Je ne pense pas que Maxwell souffle simplement un nuage de fumée positive dans notre direction. L’histoire est clairement encombrée d’exemples de succès qui ont été inspirés, forgés et durcis par le feu de l’échec. Thomas Edison en est un exemple célèbre quand il a persévéré pour inventer l’ampoule électrique.

Dans mon coaching agile j’utilise de manière consistante la terminologie « chuter en avant » quand je discute des échecs d’équipes. Oui, je veux qu’une équipe soit honnête avec elle-même et reconnaisse qu’elle a échoué. Mais je veux aussi que ses membres embrassent leurs erreurs au lieu de devenir défensifs, blâmer d’autres personnes ou être dans le plein déni. Et je veux que leur position les fasse se « pencher vers l’avant ». Désireux d’essayer quelque chose de nouveau qui amènera des résultats différents. Sans avoir peur de l’échec.

Je constate qu’en utilisant cette terminologie, j’aide des équipes à comprendre la nature de l’échec et à se comporter convenablement. Mais au-delà de la terminologie, les leaderships de projet et fonctionnel doivent aussi pleinement supporter l’idée. CE qui signifie que l’équipe de direction toute entière doit supporter l’échec. Voilà…je l’ai dit.

En conclusion – Mais, je suis un peu étrange …


Tout ceci étant dit, je me demande si j’ai une vue étrange et largement minoritaire envers l’échec ? Je me demande si la bonne réponse doit en effet de le craindre, de nier son existence, de passer d’innombrables heures à essayer de le prévoir, de ne jamais le mentionner en public. Est-ce que de telles actions sont les bonnes réponses ?

À cette fin, je ferme ce billet avec une requête auprès de tous les lecteurs. J’ai préparé une brève enquête, que je voudrais vous proposer. Je sais, je sais, vous êtes occupés. Mais je pense vraiment que vos idées seront ici utiles. L’enquête est centrée sur la construction d’une vue sur l’acceptation organisationnelle, de groupe/équipe et individuelle de l’échec et du risque. J’essaye d’obtenir à une compréhension profonde de cette acceptation et aussi de ses causes racines. Même si je suis particulièrement intéressé par les équipes agiles, ne laissez pas votre manque d’expérience agile vous empêcher de répondre.

Enter Survey Here…

Mises à jour de la certification PMI-ACP :

Le par mopertodans agile, formations et certificationsLaisser un commentaire

PMI-ACPSM Mises à jour de Certification

Suite au retour d’informations reçu par le programme pilote et le Comité de pilotage PMI-ACP, le Conseil de Gouvernance de Certification a approuvé 3 mises à jour aux critères d’éligibilité pour la certification Agile Certified Practitioner de PMI (PMI-ACP). Cette certification reconnaît la connaissance d’un praticien des principes agiles, des pratiques, des outils et des techniques à travers les méthodologies agiles.

Le tableau suivant détaille les mises à jour qui sont entrées en vigueur le 26 mars 2012. Les candidats à la certification PMI-ACP devront respecter les critères d’éligibilité suivants :

Expérience Générale en Management de Projet
  • 2,000 Heures Travail Sur des Équipes Projet
  • Ces heures doivent être cumulées sur les 5 dernières années
  • Tout PMP® et PgMP® actif satisfera ce pré-requis
Expérience en Management de Projet Agile
  • 1,500 heures de travail sur équipes projet agiles ou avec méthodologies agiles
  • Ces heures viennent en supplément des 2,000 heures exigées dans « Expérience Générale en Management de Projet »
  • Ces heures doivent être cumulées sur les derniers 2 3 ans
Formation de Management de projet Agile Formation aux Pratiques Agiles
  • 21 Heures
  • Les heures doivent être gagnées dans des pratiques agiles de chef de projet
PMGS Formations en Management de Projet
Partenaire de DantotsuPM

Le changement « de l’expérience en management de projet » pour « expérience projet » clarifie le type d’expérience exigée. Alors que la description déclare que la certification n’est pas limitée aux chefs de projet, « l’expérience en management de projet » créait un peu de confusion en impliquant que nous exigions de l’expérience à manager des projets plutôt qu’à travailler sur des équipes projet.

La recherche PMI Pulse of the Profession indique que beaucoup d’organisations n’ont pas encore implémenté largement les pratiques agiles. Donc, pour encourager autant ‘d’adopteurs précoces’ que possible à atteindre l’expérience exigée, PMI met à jour le critère d’éligibilité aux 3 dernières années au lieu de 2.

Pour commencer à répondre à toute question et commentaire sur la mise à jour des critères d’éligibilité, nous avons préparé une Foire aux Questions en Anglais FAQ qui peut être trouvée sur la page PMI-ACP de PMI.ORG.

Si vous avez des questions supplémentaires, envoyez les s’il vous plaît par courrier électronique à Customercare@pmi.org.

Et voici un rappel en vidéo de ce qu’est Scrum en seulement 7 minutes.

aidez le PMBOK à devenir plus agile

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Par Jesse Fewell, Fondateur, Communauté de Pratique PMI Agile – Comité de pilotage, Extension Logicielle au PMBOK Guide

Beaucoup de personnes demandent si le PMI lancera un Corpus des connaissances Agile PMI. La réponse est « Non ». D’une part, il serait presque impossible de se mettre d’accord sur ce qui y entrerait, particulièrement en considérant le désaccord sur ce qui constitue une déclaration officielle sur les structures Agile elles-mêmes (par exemple. Scrum, XP, Kanban). D’autre part, nombreux sont ceux qui pensent qu’un standard officiel Agile serait trop restrictif et irait même à l’encontre de l’intention « adaptative et itérative » du mouvement Agile. Cependant, un Corpus des connaissances Agile PMI n’est pas la seule façon d’avancer. À la place, il y a deux projets passionnants en voie de réalisation qui promettent une nouvelle avancée des techniques Agiles dans la communauté PMI.

D’abord, la 5ème Édition du Guide PMBOK est en revue publique. Pour la première fois dans l’histoire du PMBOK, les termes « le développement progressif itératif » et « Agile » sont explicitement définis.

Deuxièmement, PMI collabore avec l’IEEE pour développer « l’Extension Logicielle au Guide de PMBOK » (the « Software Extension to the PMBOK Guide »). Comme pour les extensions aux domaines de la Construction et des organisations Gouvernementales réalisées auparavant, l’Extension Logicielle fournira des outils et des techniques pour implémenter le Guide de PMBOK dans un environnement spécifique au développement logiciel. Étant donné qu’Agile est devenu une approche dominante pour les projets logiciels, ce document donnera des détails sur les approches « itératives-incrémentales » et « Agiles » brièvement mentionnées dans le nouveau Guide PMBOK. Aussi, vers le troisième trimestre de cette année, PMI vous donnera l’occasion de soumettre votre propre retour d’information sur ce document. Pour plus d’informations, vous pouvez lire un billet de blog de Mike Griffiths qui est membre de ce comité: http://leadinganswers.typepad.com/leading_answers/2011/09/the-new-software-extension-to-the-pmbok-guide.html

Bien qu’il n’y aura pas de Corpus des connaissances Agile PMI officiel dans un avenir proche, ces deux projets fourniront beaucoup de valeur à ceux qui les attendent avec impatience.

Et n’oubliez pas que Agile tient davantage de la philosophie que de la méthode et peut donc être appliquée à bien d’autres domaines que le développement logiciel. Dans cette vidéo, Joe Justice applique les principes Agile qu’il a embrassés dans le développement logiciel à la construction automobile et crée ainsi une nouvelle voiture à la fois performante et efficiente en un temps record.

le site de microsoft projet en français
Partenaire de DantotsuPM

jouer aux dominos, est-ce bien sérieux pour que des chefs de projets appréhendent l’Agilité ?

Le par mopertodans agile1 commentaire

Et bien OUI !

Lors d’une session organisée par Eurogiciel, un groupe d’une vingtaine de chefs de projet et développeurs ont pu mieux appréhender les méthodes Agile grâce à une approche ludique et fort éducative. Cette session de travail de 3 heures commença par une introduction des concepts Agile par Yves Schneider et Fabien Massol.

Les principes de base de Scrum :

  • Adaptatif vs. déterministe
    • Temps limité : création d’un planning détaillé impossible dans le temps imparti
    • Nécessité de démarrer l’activité au plus vite pour montrer un résultat
    • Planification limitée à l’itération en cours
  • Souplesse et stabilité
    • Le Product Owner peut changer le Contenu comme il le souhaite sauf celui de l’itération en cours
    • L’équipe a un objectif figé pour l’itération en cours
  • Inspection et adaptation
    • Augmente les chances d’atteindre l’objectif dans un environnement empirique
    • Amélioration continue en cours de projet
  • Itératif et timeboxé
  • Équipe autogérée
  • Transparence

Un rappel des rôles clés:

1. Le Product Owner

  • les maitres du jeuDéfinit les fonctionnalités du produit
  • Est responsable de l’ordonnancement des fonctionnalités du produit
  • S’assure que l’équipe va travailler sur les fonctionnalités à plus forte valeur ajoutée
  • Maintient le Product Backlog

2. Le Scrum Master

  • Est garant des règles de fonctionnement
  • Protège l’équipe des interférences extérieures
  • Est garant de la stabilité du sprint en cours
  • Supprime les obstacles
  • Conduit les réunions
  • Est responsable du « temps »

3. La Scrum Team

  • S’engage sur une itération
  • Définit les tâches et les assignations
  • Est auto-organisée et autogérée
  • Implémente les fonctionnalités

Petit rappel des réunions et des objets :

scrum methodologie agilea. Sprint Planning Meeting

  • L’équipe clarifie les exigences des entrées prioritaires du Product Backlog
  • L’équipe sélectionne les entrées prioritaires du Product Backlog sur lesquelles elle s’engage pour le Sprint
  • L’équipe définit son Sprint Backlog (todo list du Sprint)

b. Sprint Review

  • L’équipe présente le résultat au Product Owner
  • Le Product Owner accepte ou pas le résultat

c. Sprint Rétrospective

  • Qu’est-ce qui s’est bien passé ?
  • Qu’est-ce qui peut être amélioré ?

d. Product backlog

  • Liste des fonctionnalités désirées
  • Ordonnancé
  • N’importe qui peut ajouter des entrées à tout instant
  • Chaque entrée doit avoir une valeur métier

e. Sprint backlog

  • Todo list du sprint
  • Créé par l’équipe
  • À partir des fonctionnalités définies comme les plus importantes par le Product Owner

f. Task board

  • Visible
  • Objectif du sprint
  • Contient les activités du sprint
  • Activités à réaliser, en cours, et faites
  • Points de blocage

Les dominos !

Puis commença la partie pratique pour les participants répartis en équipes de 5 personnes avec 1 Product Owner, 1 Scrum Master et 3 membres.

Sprint zéro

À partir de la priorisation par le product owner d’une série de figures à réaliser comportant des nombres variables de dominos et divers degrés de difficulté. Chaque figure (besoin du client) rapportera un certain nombre de points à l’équipe fonction de sa valeur pour le client. Le Scrum Master aida les membres de l’équipe à comprendre le Product Backlog avec le Product Owner. Puis vint la détermination de l’objectif collectif que l’équipe allait décider de se donner pour un premier sprint. Les membres de l’équipe Scrum sélectionnèrent certains items de la liste de besoins (le Product Backlog) qui seraient embarqués sur ce Sprint zéro. Puis, les 3 équipiers se répartirent le travail à réaliser et bossèrent pour une durée prédéterminée (celle du Sprint) afin d’atteindre les objectifs agréés : Analyse, construction/réalisation et tests devaient être compris et intégrés dans le cycle de temps imposé pour le Sprint. À la fin du Sprint se tint une rétrospective pour voir ce qui avait bien et moins bien fonctionné pui tests d’acceptation du livrable par le client !

Un nombre de points atteints pour ce Sprint pu alors être facilement calculé pour chaque équipe, mettant en évidence les écarts entre les ambitions de chacune et le réalisé.

Sprint 1

Puis, un deuxième Sprint fut organisé dans la foulée avec les mêmes équipes qui commençaient déjà à mieux appréhender la difficulté de réalisation des besoins exprimés. Besoins qui bien sûr avaient évolués depuis le Sprint zéro.

Un enseignement qui devint rapidement très visible pour les participants est que l’équipe avait non seulement gagné une meilleure appréciation de la difficulté technique, mais aussi des compétences de chacun des membres de l’équipe, de la vitesse d’exécution, des procédures de sécurité et de tests à mettre en place… Bien que novices dans la méthode, les bénéfices étaient évidents.

Et d’ailleurs nos résultats le prouvèrent lors de ce second Sprint où nous atteignirent parfaitement les objectifs que nous nous étions fixés tout en respectant les délais.

Et, enseignement supplémentaire de cette seconde rétrospective : notre vélocité ayant crû, nous aurions pu être plus agressifs. À envisager pour les sprints suivants…

…mais c’était déjà la fin de cette belle introduction pratique à Scrum.

Merci  beaucoup aux coaches et membres d’Eurogiciel qui nous recevaient et à Muriel Janel, directrice de l’agence de Sophia Antipolis, pour son invitation et la qualité de cette session. Muriel répondra comme toujours à vos demandes d’information avec plaisir, en particulier si vous souhaitez bénéficier de l’expérience de ses équipes pour appréhender et développer votre agilité.

J’invite les autres participants à cette session ou autres exercices similaires à poster leurs commentaires à ce billet.

SCRUM est ouvert à modifications et extensions

Le par mopertodans agileLaisser un commentaire

Scrum is Open for Modification and Extension

http://www.scrum.org/news/2011/10/6/scrum-is-open-for-modification-and-extension.html

Scrum.org et Scrum Inc. ont annoncé en Octobre dernier un modèle formel pour modifier et étendre Scrum. Les créateurs de Scrum, Jeff Sutherland et Ken Schwaber, invitent les pratiquants du monde entier à contribuer à l’avenir de Scrum.

Scrum a été créé il y a plus de 15 ans et développé et adapté depuis. En se basant sur leurs expériences et de celles de la communauté Scrum, Jeff et Ken ont soigneusement codifié la structure dans le « Scrum Guide », qui documente les règles de base, les artefacts et les événements de Scrum.

Cette annonce marque une nouvelle ère dans l’évolution de Scrum en donnant un mécanisme à tous de fournir un retour d’information sur le Guide Scrum et un modèle pour proposer des extensions à la structure de base.

Le processus formel pour proposer et intégrer des changements dans Scrum est disponible en ligne sur Scrum.org. Pour en apprendre davantage sur Scrum ou soumettre votre propre contribution à Scrum, vous pouvez utiliser les liens suivants :

Soumettez vos suggestions.

pourquoi les chefs de projet luttent-ils en permanence contre la loi universelle de la gravité ?

Le par mopertodans agileLaisser un commentaire

Lyssa Adkins est une chef de projet expérimentée, certifiée PMP, qui a mené des projets pendant 15 ans de manière « traditionnelle », basée sur les plans et l’exécution rigoureuse de ces plans avant de découvrir l’approche Agile.

EscaladeSelon son expérience, certaines choses dans notre environnement de travail sont aussi immuables que la loi de la gravité dans notre environnement physique :

  • Les besoins des clients changent
  • Ce que l’équipe est capable de faire n’est connue que d’elle-même et cette capacité évolue avec le temps.
  • L’environnement du projet évolue de manière imprévisible.
  • Il est impossible de prendre des engagements pour une autre personne et de s’attendre raisonnablement à ce que cette personne les respecte.

Hors, le problème est que la méthode traditionnelle de conduite de projet par la planification lutte en permanence contre ces lois naturelles alors que l’approche pratique d’Agile s’en accommode et en fait même une partie intégrante de la méthode.

Alors, comment adapter certains des principes fondamentaux de l’approche par les plans de la plupart des chefs de projet pour qu’ils puissent utiliser la réalité au lieu de la combattre ?

Agile dans le métro

Le par mopertodans agile, pointeurs utiles3 commentaires

Voici un plan du métro de la « cité » Agile avec les principes, définitions, concepts et méthodes Agile à chaque station.

après le célèbre PMBOK, voici l’Agile Body of Knowledge (AgileBOK) disponible gratuitement en ligne

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Agile Body of Knowledge

From « Active Listening » to « Wireframes », the table of contents provides pointers to articles on major Agile concepts and techniques.

http://www.agilebok.org

PMI félicite les 500 premiers détenteurs de la certification Agile

Le par mopertodans agile, formations et certificationsLaisser un commentaire

Félicitations aux premiers PMI Agile Certified Practitioner (PMI-ACP) !

La Certification PMI-ACP a été lancée en mai et maintenant un premier contingent de plus de 500 professionnels détient la certification PMI-ACP après avoir réussi l’examen.

Ces personnes se sont inscrites et ont étudié pour obtenir la certification et ont passé et réussi l’examen. Elles sont maintenant les premières à devenir professionnellement certifiées et reconnues pour leur connaissance des principes agiles, des pratiques et des outils et des techniques à travers les méthodologies agiles. Elles proviennent de toutes les régions du monde.

Agile est une philosophie qui utilise des modèles organisationnels basés sur les personnes, la collaboration et des valeurs partagées. Elle utilise la planification récurrente; la livraison itérative et progressive; la réponse rapide et flexible aux changements; et une communication ouverte entre équipes, parties prenantes et clients.

L’utilisation d’Agile comme une approche au management de projets a augmenté radicalement dans les dernières années.

Gartner prévoit que vers la fin 2012, des méthodes de développement agiles seront utilisées sur 80 pour cent de tous les projets de développement logiciels.

La recherche du PMI a montré que l’utilisation d’Agile a triplé entre décembre 2008 et mai 2011.

La certification PMI-ACP reconnaît et valide votre connaissance des pratiques et des techniques agiles tout en démontrant votre compréhension de concepts généraux de management de projet.

Rafael Prikladnicki, PhD, PMI-ACP, PMP, Directeur Recherche et Développement et Professeur d’Informatique au Brésil, est dans le premier groupe à avoir réussi la certification. « À cause de mon engagement avec des approches agiles depuis 2002, j’ai décidé d’essayer le PMI-ACP, » a dit Dr Prikladnicki. « De plus, j’ai pensé qu’était important de contribuer au pilote de cette nouvelle certification ». Dr Prikladnick gère actuellement des projets de R&D et d’innovation dans son Université en utilisant des approches agiles. Il utilise aussi des approches agiles dans des projets de génie logiciel. « J’utilise des approches agiles pour superviser mes étudiants et doctorants » a-t-il dit. « Une thèse de maîtrise ou de doctorat sont de  la recherche qui implique innovation, flexibilité, adaptation et incertitude. C’est pourquoi des approches agiles semblent tout à fait convenir pour gérer ces sortes de projets et mon expérience a été positive jusqu’ici ».

Edgar Green, PMI-ACP, PMP, un cadre supérieur dans l’informatique impliqué dans le développement logiciel pour le transport aérien, en Floride, est aussi dans ce premier groupe à avoir gagné la nouvelle certification. Il a dit qu’il a voulu la certification pour prouver sa compréhension des pratiques généralement admises et se différencier des autres chefs de projet. « Dans ce marché de l’emploi compétitif, ces certifications peuvent aider à sortir du lot« . Les employeurs ont confiance dans les détenteurs de certifications PMI car ils possédent des compétences, la connaissance et l’expérience qui contribue directement au succès des projets et des résultats business.

Découvrez de les Qualifications pour le PMI-ACP. Ou, examinez les offres du Programme de Certifications de PMI et évaluez laquelle est la bonne pour vous.

PMGS Formations en management de projet
Partenaire de DantotsuPM

un guide de planification de sprint

Le par mopertodans agile, outils et méthodesLaisser un commentaire

A Guide to Sprint Planning de Derek Huether

http://thecriticalpath.info/2011/07/22/a-guide-to-sprint-planning

En réalisant une évaluation de Agile, l’autre jour, j’ai pris place dans une réunion de planification de sprint. Bien que nombreux soient  projets Agile qui en aient au début de chaque sprint, obtiennent-ils le meilleur du temps et des efforts investis ? En tant que partie intégrante du service fourni à mon client, je lui fournirai une petite antisèche pour la planification de sprint. Ce sera à la fois un guide et un ordre du jour, pour les aider à rester concentrés.

Qu’est-ce que la planification de Sprint (d’itération) ?

Le but de la réunion de planification de sprint est pour que l’équipe s’accorde à compléter un ensemble d’articles de plus forte valeur du «product backlog» (l’arriéré de produit ou liste des articles demandés pour un produit). Cet accord définit le contenu du sprint et est basé sur la vélocité ou la capacité de l’équipe et la longueur du sprint qui est limité dans le temps.

Qui le fait ?

scrum methodologie agileLa planification de sprint est un effort collaboratif impliquant :

  • ScrumMaster – Facilite la réunion
  • Propriétaire de Produit (Product Owner) – Présente le détail des items du product backlog et leurs critères d’acceptation
  • Équipe Agile – Définit les tâches et l’effort nécessaire pour accomplir l’engagement

Avant que vous ne commenciez

Avant de commencer nous ne devons assurer que :

  • Les items dans le product backlog ont été estimés par l’équipe qui leur a assigné une valeur de points d’histoire relative
  • Le product backlog est trié pour refléter les priorités du Product Owner
  • Il y a une compréhension générale des critères d’acceptation pour ces items

Les Backlogs

Le product backlog peut adresser aussi bien une nouvelle fonction que des corrections à une fonctionnalité existante. Pour la planification de sprint, les items du product backlog doivent être assez petits pour être achevés dans le sprint et que l’on puisse vérifier qu’ils ont été implémentés correctement. Cette liste d’item du product backlog deviendra le sprint backlog.

Bien calibrer les items du backlog

Les items de product backlog trop grands pour être complétés dans un sprint doivent être divisés en morceaux plus petits. La meilleure façon de les diviser est de se baser sur leur valeur et non pas sur le processus.

Plan basé sur la capacité

Des équipes matures peuvent utiliser la vélocité pour déterminer sur quels items du product backlog s’engager pour le sprint. Des équipes récentes ne peuvent pas connaître leur vélocité ou celle-ci peut ne pas être suffisamment stable pour l’utiliser comme une base de calcul dans la planification du sprint. Une approche pour de nouvelles équipes est de prendre des engagements basés sur la capacité de l’équipe.

Détermination de la capacité

La capacité d’une équipe est tirée de trois mesures simples pour chaque membre de l’équipe :

  • Nombre d’heures idéales dans un jour ouvrable
  • Nombre de jours pendant le sprint où la personne sera disponible
  • Le pourcentage de temps que la personne dédiera à cette équipe

Les étapes de planification

  1. Le Product Owner décrit l’item du product backlog de plus forte valeur
  2. L’équipe détermine les tâches nécessaires de compléter cet item du product baclog
  3. Les membres de l’équipe se portent volontaire pour être propriétaire de certaines tâches
  4. Les propriétaires de tâche évaluent les heures dont ils ont idéalement besoin pour réaliser leur tâche
  5. La planification continue tant que l’équipe peut s’engager à délivrer sans excéder sa capacité
le site de microsoft projet en français
Partenaire de DantotsuPM

Social Media Revolution 3

Le par mopertodans agileLaisser un commentaire

Un couple d’amis (merci Éric et Gwena !) m’a recommandé de voir cette courte vidéo sur la montée des réseaux sociaux. Attachez vos ceintures et ouvrez bien les oreilles car les statistiques d’usage défilent vite et sont parfois surprenantes.

Et si vous cherchez d’autres chiffres, en voici quelques uns.

management de projet Agile : « où est le steak » ?

Le par mopertodans agile, outils et méthodes2 commentaires

Agile Project Management—Driving Value or Where’s the Beef?

http://www.projecttimes.com/robert-galen/agile-project-managementdriving-value-or-wheres-the-beef.html par Robert ‘Bob’ Galen

Il y a des années il y avait une merveilleuse publicité dont je me rappelle où une matrone nommée Clara Peller jugeait des hamburgers par la quantité de bœuf qu’elle y trouvait. Souvent elle était déçue dans sa recherche et, de frustration, criait « Où est le steak ? ». Wendy’s était la chaîne de restauration qui a inventé cette idée publicitaire et à ce jour la phrase est devenue une accroche pour délivrer de la valeur et répondre aux attentes des clients.

Je pense que Clara était sur quelque chose de vraiment important. Dans mon expérience, les business loupent souvent le « steak » quand ils essayent de délivrer de la valeur à leurs clients particulièrement dans le domaine du logiciel. Je ne sais pas exactement pourquoi. Parfois je pense que les développeurs sont trop distants de leurs clients. Ils peuvent rarement les toucher ou les observer. Ou comprendre leurs vrais défis. Donc ils font des suppositions quand on en vient à la priorisation des besoins puis jettent le logiciel « par-dessus le mur » pour un retour d’information.

Assez souvent ils sont sous pression pour livrer un maelström de fonctionnalités. Même si quasiment personne ne sait ce que sont les besoins clients, donc ils fournissent des solutions en ratissant large espérant atteindre les besoins. En croisant les doigts. Même si cela peut connaître certaines réussites, on aboutit aussi à la livraison de fonctionnalités de faible valeur qui diluent la concentration de l’équipe et augmentent les coûts de développement.

Ne serait-ce pas merveilleux si nous pouvions nous concentrer entièrement sur le « Steak » dans le développement d’application ? Dépenser la majorité de notre énergie, en nous concentrant sur la livraison de solutions à forte valeur et répondant aux plus forts besoins de nos clients. Éliminer le désordre de la déception et de l’ambiguïté et travailler simplement sur qui compte le plus ?

Même si cela ressemble à un conte de fées, les méthodes agiles aspirent justement à atteindre ce but. Mais il n’est pas facile de l’atteindre et le Chef de projet Agile efficace joue un rôle merveilleux dans cette quête. Dans ce billet, je veux partager quelques idées sur la façon de concentrer l’équipe sur la livraison de vraie valeur.

Un « backlog » priorisé !

Un des premiers mécanismes qui pilotent la valeur est le « Backlog de Produit » – la liste priorisée des besoins qui pilote ce que les équipes agiles vont construire. Chaque équipe devrait être focalisée comme un laser sur la priorisation de leur « backlog » de 1 à N. Il ne peut pas y avoir trois ou quatre fonctionnalités de priorité 1, seulement une; puis une seule deuxième, une seule troisième, et cetera.

Croyez-moi, vos clients et parties prenantes voudront jouer indéfiniment avec les priorités. J’ai vu des cas où ils avaient fait des regroupements dans un tableur qui donnaient la priorité de chaque fonctionnalité, puis des sous-fonctionnalités de chacune d’entre elles également priorisées. Ils insisteront pour dire qu’ils ne peuvent pas décomposer davantage la valeur quand ils essaieront d’augmenter la priorité. Cette approche (1.a, 1.b..1.z) leur permet d’échapper à la vraie priorisation et à la sélection. Elle indique aussi leur incapacité innée à faire des choix difficiles quant à ce qui est réellement le plus important. Ne les laissez pas le faire!

Un backlog de produit efficace est toujours dans un ordre linéaire et priorisé. L’équipe délivrera toujours les fonctionnalités de priorité les plus hautes en premier. Ils travailleront d’abord sur celles-ci, les finiront en premier, et s’assureront que le client est bien engagé.

Et, puisque le client est l’arbitre final des priorités, il ne devrait pas vraiment se plaindre de cette approche. Il est vrai qu’historiquement nous leur avons permis de nous donner de longues listes de fonctionnalités sans faire cette distinction et ils sont devenus un peu paresseux.

Quand encouragée à prioriser, je n’ai jamais vu de partie prenante qui en soit incapable.

Valeur Pilotée par le client

La priorisation peut aussi être pilotée par la valeur perçue, le changement, qui devrait être conduit. Une technique utilisée par beaucoup d’équipes agiles est la notion de Poker de valeur. C’est une variation de la populaire technique de Poker de Planification (Planning Poker) qui est utilisée pour l’évaluation de la taille d’une « User Story ». Mais au lieu de déterminer la taille des « User Stories » en points d’histoire, nous utilisons des Points de Valeur comme déterminant.

Dans ce cas vous utilisez un jeu de cartes étiquetées de 1-10, un étant la valeur la plus basse et dix la plus haute. Pour chaque « User Story » ou thème d’histoires vous demandez à un groupe mixte de clients et de parties prenantes ‘de voter’ sur la valeur de l’Histoire. Vous prenez une approche tournante et discutez ‘le pourquoi’ derrière la valeur la plus haute et la valeur la plus basse et vous laissez les membres de l’équipe exprimer leurs avis sur la nuance de valeur.

Une fois que la discussion est finie, vous faîtes un second vote et rediscutez jusqu’à ce que vous rétrécissiez la fourchette de valeurs autant que possible. Parfois vous atteignez un accord sur une valeur de l’ensemble de l’équipe. Parfois vous obtenez simplement une fourchette.

Vous pourriez même compartimenter les valeurs selon les différentes perspectives de l’équipe. Par exemple, les personnes de la qualité et des tests estiment une histoire particulière à cinq, tandis que la valeur des gens du métier cela la valorise à trois et les développeurs ou les gens de la technologie à un. Toutes leurs estimations fournissent des données importantes sur combien vous estimez transversalement la fonctionnalité.

Cette logique pourrait aussi être appliquée à de multiples parties prenantes. Par exemple, les parties prenantes Nord-Américaines pourraient estimer une fonctionnalité à six, tandis que les parties prenantes EMEA la jugent seulement à trois. Dans tous ces cas, discuter de la VALEUR comme d’un attribut distinct aide l’équipe dans la priorisation et dans la décision de combien de finition il faut apporter aux fonctionnalités individuelles.

Une Variation

Une variation vraiment efficace sur la technique de Poker de Valeur est de donner à chaque votant ou contributeur associé un montant de financement à dépenser pour leur vote. Alors, non seulement ils votent sur une valeur, mais ils doivent aussi investir une partie d’un montant fixe de dollars sur la fonctionnalité.

Très souvent de l’argent de Monopoly ou un équivalent amusant sont utilisés à cette fin. Disons que chacun possède 5,000 $ à dépenser sur leurs fonctionnalités pendant le Poker de priorisation. Dans un cas spécifique, une partie prenante vote neuf sur une caractéristique.

Pour souligner l’importance, ils déposent 1,500 $ sur la caractéristique soit environ 30% de leurs fonds disponibles. En fait, ils dépensent leurs fonds sur un total de seulement sept fonctionnalités. Pendant qu’ils continuent à prioriser les fonctionnalités ultérieures, ils ont clairement communiqué leurs avis sur la valeur. En fait, cette caractéristique à 1,500 $ finit en première priorité avec une valeur totale de 12,000 $ à travers l’équipe de vote entière soit 25% des fonds disponibles.

Aussi, voici une question intéressante. Si vous implémentez cette approche, que transmet Priorité n°1 par rapport à Priorité n°1 ET 25% de la valeur ? Selon moi, il y a une grande différence. Cette fonctionnalité représente une part beaucoup plus significative de la valeur et exige un soin particulier dans l’exécution. J’espère que vous voyez la différence.

Fonctionnalité Minimale Commercialisable (Minimal Marketable Feature : MMF)

Souvent dans les équipes agiles, des « User Stories » singulières n’ont pas la masse ou l’impact suffisant pour être estimées efficacement par le client. Plus tôt, j’ai parlé en termes de thème d’histoires. C’est une façon commune de grouper ensemble des histoires qui ont une valeur et de la signification en tant que groupe. Non seulement cela aide dans le développement des jeux de fonctionnalités significatives, mais si vous priorisez au niveau des thèmes, cela simplifie votre priorisation. Cela a aussi plus de signification du point de vue des clients.

Une variation sur ce thème est la Fonctionnalité Minimale Commercialisable (Minimal Marketable Feature : MMF). Ce concept est originaire de Kanban et de LEAN. Essentiellement, c’est comme un thème, mais il apporte les notions de faisabilité, possibilité de commercialisation et l’utilisation d’ensemble client.

Très souvent un MMF est plus grand qu’un thème. Cela pourrait être équivalent à une épopée d’histoires d’utilisateur et exiger que plusieurs sprints soient achevés. Cependant, une fois réalisé, l’équipe délivrera d’habitude physiquement le MMF au client, par exemple, le faisant passer dans l’environnement de production.

Suivi de Valeur

Un des merveilleux ajouts à votre ensemble d’outils de Chef de projet Agile est de brûler complètement la valeur d’histoires, de thèmes, ou MMFs. Vous voudrez installer le graphique de « Burndown Chart » dans un emplacement bien visible qui mette en évidence la valeur livrée par l’équipe. Comme avec tout graphiques « Burndown » vous voudrez garder les yeux de chacun sur le progrès et interagir avec l’équipe sur le progrès et le flux.

Vous voudrez calculer la valeur totale pour une version ou un projet. Alors configurez votre « Burndown » sur une base itération-par-itération.

Si vous obtenez un comportement agile sain dans votre équipe, vous verrez que la valeur est livrée d’une façon chargée sur l’amont. Vous devriez aussi voir les fonctionnalités de forte valeur livrées très tôt. En fait, je m’attends habituellement à ce que des équipes factorisent la valeur dans la qualité globale et dans les stratégies de test.

stop arrêt de projet "no go"Savoir conclure

Les chefs de projet Agiles ne se soucient pas juste d’exécuter par cœur de tâches ou des « user stories ». Non! Au lieu de cela ils concentrent leurs équipes sur une vue nuancée et à multiples facettes et vers une exécution orientée client et pilotée par la valeur.

Non seulement espèrent-ils en premier délivrer de la valeur, mais ils espèrent aussi qu’en ce faisant, le client peut atteindre un niveau « assez bon » avec les incréments de produit livrés de façon incrémentale et permettre ainsi à l’équipe d’arrêter le projet plus tôt que prévu.

S’arrêter après la livraison des fonctionnalités et de la fonction qui leur importe vraiment le plus. En quelque sorte atteindre leur valeur et se déplacer ensuite vers le projet suivant de valeur la plus haute. C’est cette sorte de recherche de valeur qui peut vraiment faire qu’une équipe agile se détache de ses homologues traditionnelles et se déplace tellement plus rapidement.

le site de microsoft projet en français
Partenaire de DantotsuPM

INVEST(issez) dans vos User Stories

Le par mopertodans agile, outils et méthodes1 commentaire

Le modèle INVEST est décrit sur Wikipedia

Letter Meaning Description
I Independent The user story should be self contained, in a way that there is no inherent dependency on another user story.
N Negotiable User stories, up until they are part of a Sprint, can always be changed and rewritten.
V Valuable A user story must deliver value to the end user.
E Estimable You must always be able to estimate the size of a user story.
S Sized appropriately or Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable The user story or its related description must provide the necessary information to make test development possible.

Et cette vidéo en décrit les grands principes.

le site de microsoft projet en français
Partenaire de DantotsuPM

have you heard of IBM’s DAD process?

Le par mopertodans agile, outils et méthodesLaisser un commentaire

In a white paper available free of charge IBM proposes a Disciplined Agile Delivery (DAD) process to make the best use of existing Agile methodologies (Scrum, RUP, XP..) while scaling up and putting them in the context of a complete solution life-cycle.

I invite you to read the full introductory document. PMs will find there a terminology they recognize and can easily relate with rather than the sometimes hermetic one of Agile for new comers with its scrums, sprints, poker planning… Through inception, construction and transition phases, the authors position along the DAD Process the tasks to be done, of course in an Agile way and using many of the scrum and RUP techniques .

So, if you’re still Agile adverse, read this white paper, and you may well see some of these approaches like Scrum, XP, RUP in a new and brighter light.

le site de microsoft projet en français
Partenaire de DantotsuPM

Scrum Guide 2011 – une version non officielle en français de Pierre Neis

Le par mopertodans agile, outils et méthodesLaisser un commentaire

En juillet 2011, Ken Schwaber et Jeff Sutherland ont édité une nouvelle version du Scrum Guide. Ce “Scrum Body of Kowledge” a l’air anodin, mais du point de vue de Pierre Neis, il annonce de profonds changements dans le “framework”.

« Scrum est en amélioration permanente, pourquoi cette version serait-elle différente des autres? »

Voici une traduction non-officielle que Pierre nous invite à découvrir.

le site de microsoft projet en français
Partenaire de DantotsuPM

le manifeste Agile pour les chefs de projet – The Agile Manifesto for PMs par Cornelius Fichtner

Le par mopertodans agile, outils et méthodes1 commentaire

Cornelius Fichtner, PMP, host of The Project Management Podcast™, reads out the Agile Manifesto for us and sheds light on each sentence based on his own very rich project management experience.

MS Quotidien
Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

apprends moi à dessiner Scrum

Le par mopertodans agile, outils et méthodes1 commentaire

The Scrum Framework
Lyssa Adkins qui se présente comme une coach de Coach Agile (les ScrumMasters par exemple), montre dans cette vidéo comment expliquer Scrum à quiconque en reprenant dans un graphique les principes clés de cette approche. Lyssa est l’auteur du livre Coaching Agile Teams.

The Wedding Cake
Elle va plus loin avec cette démonstration de comment expliquer très simplement les différences et les bénéfices qu’il y a à adopter une approche Agile.

le site de microsoft projet en français
Partenaire de DantotsuPM

l’empirisme ou l’acte de prendre des décisions basé sur ce qui est

Le par mopertodans agile, outils et méthodes1 commentaire

Empiricism, the act of making decisions based on what is

http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/

Par Ken Schwaber

L’empirisme est l’acte de prendre des décisions basé sur ce qui est. Scrum est un processus empirique, parfois décrit comme “l’art du possible.” Par cela, je veux dire que nous faisons du mieux nous pouvons avec ce que nous avons.

Un Propriétaire de Produit (« Product Owner ») planifie une version (« release ») basée sur toutes les informations actuellement disponibles. Il ou elle définisse les objectifs, les fonctionnalités et les capacités qui délivreront ces buts ainsi que le coût probable et la date de livraison. À partir de ce moment-là, le travail du Propriétaire de Produit est d’évaluer ce qui est possible vu les capacités de l’Équipe et de prendre les meilleures décisions pour atteindre l’objectif souhaité. Étant donné la nature de la technologie, des marchés, des besoins et des personnes, des compromis sont faits. Parfois le but ne peut pas être atteint pour un prix raisonnable. Parfois le but sera atteint, mais d’une manière différente de ce que le Propriétaire de Produit pensait initialement. C’est l’empirisme en pleine action.

L’Équipe (de développeurs) sur l’Équipe Scrum fait de même. Elle rencontre le Propriétaire de Produit et évalue ce que le Propriétaire de Produit voit comme les choses les plus importantes à faire ensuite. Si réalisées, celles-ci dirigeront le produit émergent dans la meilleure direction vers le but désiré. L’équipe choisit autant de choses qu’elle croit pouvoir en faire pendant le prochain Sprint. Le coût de l’équipe et la longueur de Sprint est fixe. Seule la quantité d’items du « Product Backlog » choisie peut varier. Le Propriétaire de Produit et l’Équipe définissent souvent un objectif pour le Sprint. C’est un sous-ensemble des objectifs de la version (« release »).

Quand l’équipe choisit des items lors d’une réunion de Planification de Sprint, elle s’engage à le faire pendant le Sprint.

Une définition « s’engager » est : « Se lier moralement par une promesse : Il s’est engagé à payer ses dettes dans les huit jours. » selon le Larousse. (ndlt)

Cela correspond à ma compréhension du mot s’engager, qui est une promesse, un engagement à un plan d’action.

Cependant, beaucoup d’équipes Scrum utilisent le mot « s’engager » comme si c’était « une garantie ». C’est un reste des méthodes en cascade, où une évaluation était un contrat. Cependant, cela résonne toujours dans les têtes de propriétaires de produit et des développeurs. J’ai trouvé équipes après équipes qui estiment qu’elles doivent tout faire pour respecter leur engagement. La victime est habituellement la qualité.

prédire l'avenirJe me demande si nous devrions échanger le mot « s’engager » pour celui de “prédire” ?

Ceci pourrait donner la même impression que la présentatrice météo essayant de nous fournir les meilleures informations possibles. Elle fait avec que l’on connaît et avec la science de la météorologie. Elle ne fournit pas de garantie, mais quelque chose que nous pouvons utiliser pour prendre des décisions. Les prévisions sont également utilisées par les organisations de ventes. Peut-être cette clarification nous aidera-t-elle à comprendre qu’ « un engagement » dans Scrum est une promesse de faire de notre mieux avec ce que nous avons.

le site de microsoft projet en français
Partenaire de DantotsuPM

articles les plus lus de DantotsuPM en janvier 2011

Le par mopertodans agileLaisser un commentaire

2 articles sur les WBS :

la structure de découpage du projet (Work Breakdown Structure: WBS)

Work Breakdown StructureSi Philip Diab (former PMI Chair Person) devait identifier un seul outil, méthode ou processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS).

Astuce pour l’examen PMP: la Structure de Découpage du Projet (Work Breakdown Structure : WBS)

J’ai plusieurs fois abordé ce sujet critique de la construction du WBS en management de projet, notamment dans les billets: « conseils pratiques sur le WBS/practical tips on WBS »; « 20 erreurs courantes faites par les chefs de projet nouveaux ou inexpérimentés Par Harold Kerzner, Ph. D., PMP » et « Dix Choses à regarder lors d’une revue de planning (d’échéancier) de projet ».

Cornelius Fichtner nous fournit ici un éclairage personnel et insiste sur la règle des 100% qui est trop souvent oubliée.

Plusieurs articles sur les compétences et attitudes ont également été appréciés par les lecteurs.

protectionun chef de projet devrait-il se soucier de Politique de Bureau ?

La « politique politicienne » qui n’a pour intérêt que de servir quelques personnes qui en usent et en abusent est elle négative et c’est souvent dans ce sens que l’on se réfère à la « politique de bureau » qui ne sert que quelques individus dans l’entreprise à des fins personnelles.

à propos de différences inter culturelles…

La sensibilité aux cultures et à la communication inter cultures est un élément clé de réussite des chefs de projet qui travaillent à l’international. Je pense que cette petite vidéo amusante vous rappellera des souvenirs de situations similaires qui vous sont arrivées. Lesquelles ?

je retiens - team buildingcomposer des équipes comme si les personnes importaient

Les projets sont avant tout une affaire de personnes. Alors que cette affirmation semble tomber sous l’évidence, elle est souvent incroyablement oubliée. L’homo economicus a longtemps été discrédité et a prouvé être beaucoup moins rationnel que beaucoup de philosophes le voudraient. Les gens ne sont pas universellement interchangeables et on ne peut pas s’attendre à ce qu’ils se comportent dans les limites logiques et prévisibles de leur intérêt personnel étroit, mais nous continuons à faire comme si c’était le cas. Comment nous fonctionnons dans une équipe est critique. La raison même d’existence des équipes est que nous ne pouvons pas réussir tout seul; nous avons besoin d’un peu d’aide, nous avons besoin de l’expertise de spécialistes et nous avons besoin des gens pour soulever des montagnes. Cependant, mettez plusieurs personnes dans une même pièce et les défis de communication, de collaboration, de confusion et de conflit adviennent rapidement.

Une bonne dose d’agilité également…

spécialistes et généralistes dans une équipe projet

La spécialisation dans Scrum est un sujet chaud depuis de nombreuses années. Les questions sur la spécialisation arrivent quand j’explique aux gens que d’après la définition de Scrum, une équipe doit être cross-fonctionnelle. Je recommande aussi aux membres d’être à 100 % dédiés à une équipe (ne pas être membres de multiples équipes). La plupart des personnes qui sont nouvelles sur Scrum l’acceptent sans considérer les implications. Parfois quelqu’un demandera : « mais alors, que fera la personne des tests au début du Sprint ? »

Vélocité (dans le développement logiciel)

La Vélocité est une mesure de productivité souvent utilisée dans le développement de logiciel, en particulier avec les méthodes Agile.

Des nouvelles du management de projet au niveau international.

PMI a créé une nouvelle liste de questions/réponses sur les certifications

Bonjour, je pense que vous trouverez cette page « Certifications FAQs » fort utile si vous vous posez des questions sur les certifications proposées par le Project Management Institute.

10 tendances principales du management de projet pour 2011 selon ESI : les Qualités de leader sont en tête de liste

Le 4 janvier, ESI International, a révélé ses 10 Premières Tendances Mondiales de Management de projet pour 2011. Des thèmes clefs qui incluent construire l’influence du chef de projet, l’accélération d’un nouveau leadership et des compétences de communication et l’utilisation accrue d’approches d’étude informelles comme des médias sociaux et la formation résultant de l’expérience.

le management de projet reçoit enfin un réel respect

Selon cet article, des bonnes priorités aux salaires plus élevés, le management de projet et les PMOs reçoivent enfin plus qu’un intérêt de pure forme dans beaucoup de sociétés.

Et pour terminer, quelques meilleures pratiques.

ordre du jour de la session de lancement du projet

Il est à noter qu’il y a diverses réunions de lancement de projet. Celle à laquelle se réfère cet article est interne à l’équipe projet. Elle a pour objectif principal d’établir les normes, partager la même vision des livrables, comprendre les rôles et responsabilités de chacun, avec un clair focus sur le mode de communication que l’on souhaite utiliser entre membres de cette équipe.

quelles sont les clés du succès des leaders ?

J’ai bien aimé dans cet article les cinq compétences que McKinsey a identifié comme étant au cœur du leadership:

1. trouver et donner une signification dans le travail
2. convertir des émotions telles que le stress et la peur en opportunités
3. savoir tirer partie de ses connections et de sa communauté
4. agir face aux risques
5. soutenir l’énergie qui est la force vive du changement

La réflexion disant que toute personne maîtrisant au moins une de ses compétences double sa capacité à conduire le changement me semble un peu excessive et l’autosatisfaction de ceux qui posséderaient les 5 tout autant. Pourtant….

Agile est-il le bon choix pour vous? Les cinq points les plus importants à considérer lorsqu’on souhaite implémenter la méthode Agile

Le par mopertodans agile, outils et méthodes2 commentaires

Is agile right for you? Top 5 considerations when implementing Agile Methodology

http://pmbox.geniusinside.com/information-technology/is-agile-right-for-you-top-5-considerations-when-implementing-agile-methodology/

écrit par Neil Stolovitsky de Genius Inside

Agile fait beaucoup de bruit actuellement dans les milieux de développement de logiciels. La méthode a été créée par des développeurs pour des développeurs. Son origine remonte à 10 ans lorsqu’un groupe de développeurs ont mis en place  l’Agile Manifesto  dans une station de ski dans l’Utah. Ce manifeste visait à établir pour les projets de développement de logiciels un système plus inclusif, démocratique et efficace. Il en a résulté plusieurs méthodologies Agile dont notamment Crystal Clear, Scrum et Extreme Programming, toutes créées afin de mettre en place des équipes de projet autonomes qui placent la responsabilité dans les mains de chaque personne qui touche le projet.

Ceci est une toute nouvelle approche de gestion des équipes de projet. Les groupes de développement de logiciels doivent être très prudents lorsqu’ils déploient Agile dans leur organisation, car les équipes sont en général habituées à être surveillées et guidées tout au long du projet.  En réalité, il y a de nombreux points à considérer avant d’implémenter Agile afin d’être sûr que les changements proposés par Agile soient positifs et non négatifs par rapport au processus existant. Voici les cinq points les plus importants pour vous aider à déterminer si la méthode Agile est la bonne pour vos développeurs:

1)    Culture adéquate

Une culture trop différente est l’une des raisons principales à l’échec d’un environnement de travail de gestion de projet. Les environnements Agile sont autonomes, ils font face aux clients et sont démocratiques par nature. Tous les groupes de développement cherchant à adopter Agile doivent avant tout se demander si ces principes sont en accord avec la culture et les valeurs de la société ? S’ils sont en complète opposition, les chances de réussite sont minimes. La dernière chose à faire est de démarrer du mauvais pied!

2)    Adhésion

La plupart des environnements de travail en management de projet réussissent simplement avec une bonne adhésion du leadership.  Même si la culture de la société est adéquate, Agile nécessite une adhésion complète depuis la base dès le départ. Chaque personne a un rôle à jouer: des clients aux développeurs, étant donné que chaque personne a sa part de responsabilité avec Agile.

3)    Management du changement

Est-ce que votre société est prête pour un changement? Étant donné qu’Agile requiert un changement d’envergure, il est primordial qu’une stratégie de gestion du changement soit en place afin de minimiser les risques et d’assurer une transition en douceur entre l’ancienne et la nouvelle manière de faire les choses.
former, entrainer, nourrir

4)    Formation

La méthodologie Agile nécessite une compréhension complète de sa philosophie et de son environnement de travail dès le début. Cette méthodologie nécessite la participation de tous les membres de l’équipe, il est important que chacun connaisse l’ensemble du processus ainsi que sa propre contribution. Toute autre approche risque de faire échouer son implémentation.

5)    Collaboration

La base de l’efficacité des projets Agile est l’effort concerté de mise en place d’un système qui permette une collaboration efficace entre les parties prenantes internes et externes. Vous devez vous non seulement vous demander s’il existe dans votre société une stratégie de communication efficace, mais surtout vous devez être sûr que vos clients seront prêts à s’investir lourdement dans le développement de leurs projets.

Pour en savoir plus au sujet de la méthodologie Agile, regardez ce bref (6′) et récent web cast (ci-dessous en anglais) et livre blanc (en anglais également).

le site de microsoft projet en français
Partenaire de DantotsuPM