Posté par jc-Qualitystreet le 5 juin 2009
Product Owner c’est l’un des 3 rôles (avec le ScrumMaster et l’Equipe) proposé par Scrum; c’est aussi un vrai point de vigilance pour moi en tant que Coach Agile.
Le Product Owner est le responsable du produit, le représentant du client et des utilisateurs et donc à ce titre l’interlocuteur privilégié de l’Equipe.
Le rôle est essentiel; son importance est primordiale:
être Product Owner sur un projet Agile, c’est déjà pas mal de responsabilités (LA DECISION), c’est aussi:
- s’impliquer
- savoir communiquer
- savoir collaborer
- se rendre un minimum disponible
- disposer d’un certain savoir-faire…
Autant d’éléments, autant de risques que les choses dérapent…
Product Owner
Quant à l’activité du product Owner, même si son profil peut varier, elle est plutôt bien cadrée :
- Partager la Vision
- Définir et Alimenter un Backlog
- Fixer les priorités
- Décrire les fonctionnalités
- Ajuster les fonctionnalités et les priorités à chaque sprint
- Accepter ou rejeter les résultats (sur la base des critères d’acceptation)
Autant d’activités (et des registres différents), autant de risques que les choses ne dérapent… Backlog incomplet, exigences déconnectées de la réalité, de la valeur, Vision non partagée voire obscure, Absence de décision, Imprécision des critères d’acceptation, inéfficacité des échanges avec l’équipe, des ateliers de travail, manque de disponibilité et de présence à des RDV clés.
Seul, le Product Owner, peut il y arriver ? LA REPONSE EST NON!
mais il peut compter sur l’équipe me dire-vous?
OK mais pas suffisant…
Le Product Owner doit d’abord être accompagné.
Ensuite, même si le Product Owner doit parler d’une seul voix (vis à vis de l’équipe notamment, c’est un fondamental), constituer autour de lui une ”Team Product Owner” est trés souvent une pratique gagnante.
De ce point de vue, l’Ergonome est ce partenaire privilègié qui va appuyer le travail d’estimation et de priorisation du Product Owner, Il est aussi celui qui peut l’aider à clarifier et communiquer sa Vision, à recueillir et définir les besoins au travers de multiples ateliers de travail et d’une approche Personas. Associer trés vite Product Owner et testeurs est aussi un facteur clé de réussite
Mon Challenge :
- Faire adhérer aux valeurs Agiles
- Former à la pratique du SCRUM: les règles à respecter, le déroulé, l’attitude et les points de vigilance
- Définir précisément les rôles et responsabilités de chacun
- Diagnostiquer et dimensionner le rôle Product Owner sur le projet
- Construire le Team Product Owner si nécessaire
- Coacher le Product Owner sur 1 ou 2 sprints, avec un fort accompagnement en Sprint O
Mes autres Alertes:
Posté par jc-Qualitystreet le 4 juin 2009
Les slides de ma session donnée à la conférence XPDay France 2009 (la conférence agile sur les Méthodes Agiles)
Posté par jc-Qualitystreet le 12 mai 2009
La seconde édition de l’ouvrage de référence sur les
Méthodes Agiles vient tout juste de paraître.
Veronique Messager Rota nous livre là une
seconde édition enrichie (notamment sur les aspects Lean, Changement, Coaching et Ergonomie), un ouvrage complet et surtout
très OPERATIONNEL.
Pour avoir eu le privilège de le découvrir en avant première, je peux vous assurer que vous ne regretterez pas votre investissement. A consulter d’urgence et sans modération …
Au sommaire:
- Introduction - Chef de projet : un métier complexe
- Diagnostiquer sa gestion de projet
- Méthodes traditionnelles ou méthodes agiles ?
- Recueillir efficacement les besoins
- Planifier son projet
- Suivre et piloter son projet
- Gérer les hommes
- Adopter une approche agile
- Annexes
Posté par jc-Qualitystreet le 2 mai 2009
“Coach Agile“, c’était il n’y a pas si longtemps avec “Consultant Experience Utilisateur”, une ligne sur ma carte de visite, c’est aujourd’hui une bonne partie de mon activité …
Vous avez dit Coach Agile?
C’est simple, mon travail consiste à accompagner pour une durée déterminée une organisation, une équipe, une personne dans son parcours vers l’agilité pour des résultats concrets et mesurables. Plus qu’un consultant je suis avant tout un partenaire et le tiers indispensable qui soutient le CHANGEMENT.
Dans mon esprit, le coaching est donc toujours temporaire puisque mon but est de favoriser l’autonomie de mes Clients et de faire en sorte que très vite on n’ait plus besoin de moi !
C’est notamment, cette posture qui me permet de distinguer ce nouveau rôle de Coach Agile de celui de ScrumMaster (un chef de projet Agile, à la fois facilitateur et protecteur, un rôleque je peux aussi endosser) présent sur le projet de A à Z au même titre que l’Equipe et le Product Owner. LE SCRUMMASTER N’EST PAS UN COACH AGILE !
Le coaching, une affaire d’expertise et d’excellence…
Au travers de mon expérience et de mes compétences, je permets à mes clients d’atteindre avec efficacité, efficience et satisfaction, les objectifs qu’ils se fixent.
Je les aide à introduire l’agilité, à approfondir leurs connaissances et à améliorer leurs performances grâce aux méthodes & pratiques Agiles.
Faciliter, poser des questions, écouter, observer mais aussi explorer, guider, clarifier, rassurer et proposer un cadre méthodologique adapté, font le quotidien de mes interventions. Des styles qui se chevauchent : enseigner, accompagner, conseiller…
Car, l’adoption de l’agilité par une organisation ou par une personne (Décideur - Chef de projet- Maîtrise d’ouvrage) nécessite un changement culturel majeur qui doit être préparé et accompagné par un processus de coaching efficace…
Le coaching, une question de déontologie aussi…
Et une Vision que j’espère partager avec d’autres ! Une mission de coaching est une mission de confiance qui nécessite engagement et responsabilisation de la part du coach. S’appuyer sur quelques principes déontologiques majeurs m’est vite apparu primordial pour construire une collaboration sans failles.
Voici donc rien que pour vous, les 5 règles déontologiques auxquelles j’obéis:
- Respect des personnes,
- Respect du but assigné,
- Confidentialité,
- Indépendance Professionnelle
- Amélioration continue de mes propres compétences.
Posté par jc-Qualitystreet le 4 avril 2009
ou comment faire une gestion des risques vraiment efficace dans un projet Agile ?
Vous vouliez des réponses, en voilà ! …
Risk Board Agile Jc Grosjean
- c’est une activité essentielle de la gestion de projets informatiques
- c’est aussi une brique incontournable du référentiel AGILE-CMMI que quelques clients (conscients du potentiel énorme de la double approche dans certains contextes) commencent à me réclamer
- c’est enfin un ÉNORME point fort de l’Agilité (quand on s’y prend bien), point fort le plus souvent et étonnamment passé sous silence
En quoi la gestion Agile des risques est-elle différente ? Qu’est ce qui la rend extrêmement efficace (bien plus que ….) ?
- Ma gestion Agile des risques est MOINS FORMELLE et se fait dans un esprit “LEAN” (en jouant sur le juste ce qu’il faut et en éliminant les sources de gaspillage potentielles)
- Ma gestion Agile des risques est l’AFFAIRE DE TOUS, PLUS COLLECTIVE (portée par l’équipe du début à la fin du projet)
- Ma gestion Agile des risques est FACILITEE (seulement) par le chef de projet Agile (ou ScrumMaster)
- Ma gestion Agile des risques est avant tout QUALITATIVE
- Ma gestion des risques est OMNIPRÉSENTE
- Ma gestion Agile des risques propose des points de contrôle et de surveillance beaucoup PLUS NOMBREUX et beaucoup PLUS FRÉQUENTS
ET concrètement comment ça se passe ? ce qui nous intéresse c’est l’opérationnel 
Contextes pur Agile (SCRUM, XP) ou Agile-CMMI, peu importe… dans les deux cas il y a nécessairement un changement culturel important : la gestion des risques doit appartenir à l’équipe; elle est portée par l’équipe et va s’appuyer (fortement) sur un important travail de facilitation du Chef de Projet Agile.
Dans les grandes lignes, voilà à quoi ressemble une gestion Agile des risques:
- Un travail de planification de la gestion des risques est nécessaire au démarrage (ou à la signature) du projet Agile; ce court exercice relève selon moi d’un Process AGILE et insiste sur le caractère la fois ORGANIQUE (intégrée) et SPÉCIFIQUE (au travers de nombreux RDV) de la gestion Agile des risques. Il s’accompagne d’un petit guide prêt à l’emploi décrivant catégories, paramètres de risque, divers conseils peuvent aider notre chef de projet agile dans son activité de facilitation.
- En sprint 0, les risques seront identifiés et priorisés selon les paramètres classiques (probabilité d’occurrence et impact potentiel), c’est classique mais fait en équipe
- Ensuite à chaque sprint:
- les risques sont identifiés à tous les RDV du sprint (réunion de planification, Daily SCRUM, revue de sprint, rétrospective)
- les risques sont analysés et gèrés (recherche de diminution ou autre stratégie contenir, accepter, éviter) à tous les RDV du sprint (réunion de planification, Daily SCRUM, revue de sprint, rétrospective)
- les risques sont surveillés en permanence grâce au RISK BOARD présent sur le radiateur d’informations, et grâce au Burndown Chart
- Plus formellement, chaque début (réunion de planification) et chaque fin de sprint marquent des jalons plus formels pour la gestion Agile des risques: volet dédié dans l’ordre du jour, fiche de synthèse à chaque fin de sprint incluant une partie risque (ce point est d’ailleurs une exigence remontée par quelques chefs de projet à notre groupe de travail Agile-CMMI)
- Le RISK BOARD devient le support collectif de la gestion des risques, support aux vertus incroyables ! Tester votre gestion des risques avec ou sans, vous comprendrez la différence; c’est encore plus fort que les pilules rouges de Jeff Sutherland :) . On me demande souvent quoi placer sur un radiateur d’informations, et bien voilà quelque chose d’essentiel !
Et le Mapping avec CMMI / PMI ?
Vous avez là véritablement la première brique d’un référentiel AgileCMMI…
Même si les risques sont abordés dans d’autres domaines de processus CMMI (PP notamment), RSKM (”Gestion des risques”) est le domaine de processus que le SEI (Software Engeneering Institute) dédie aux risques. L’intention de RSKM est “d’identifier des problèmes potentiels avant qu’ils surviennent de telle sorte que les activités pour traiter les risques puissent être planifiées et déclenchées au besoin tout au long de la vie du produit ou du projet afin que les impacts nuisibles à l’atteinte des objectifs soient atténués.”
CMMI exige dans RSKM que vous répondiez à trois objectifs spécifiques:
- Se préparer à la gestion des risques = OK
- Identifier et analyser les risques = OK
- Atténuer les risques = OK
La gestion Agile des risques (telle que décrite ci-dessus) vous permet clairement de répondre aisément à ces trois objectifs et de bénéficier le cas échéant de toute une somme de preuves directes et indirectes tout à fait pertinentes dans un contexte de certification (SCAMPI A). Pour un mapping plus complet, vous pouvez vous référez à cet article :
AgileCMMI- Voyage d’un coach Agile au coeur de la gestion des risques - RSKMSur la question des risques
PMI et
CMMI marchent de concert, et notre gestion Agile des risques s’y retrouve donc aussi plutôt bien… Le
PMBOK décrit 5 grandes activités dans son domaine de connaissance “Management des risques du projet”, il suffit de regarder si ça colle …
- Planification de la gestion des risques = Oui
- Identification des risques = Oui et en mieux dans une dynamique plus collective
- Analyse quantitative et qualitative = Oui mais en mettant l’accent sur le qualitatif
- Planification des réponses aux risques = Oui et en mieux (collectif, fréquence et RISK board)
- Surveillance et maîtrise des risques = Oui et en mieux: les risques sont revus tous les jours et sont l’affaire de tous !
Bon, tout est dit. A vous de jouer.
