La gestion agile de votre projet d’innovation avec Claude Emond

Nouvel atelier de Claude Emond en Gestion de Projet Agile des projets d’innovation et de développement de produits, en collaboration avec L’IDP.

Une approche comme toujours originale de notre ami Claude Emond: Sur 3 journées (4, 9 et 16 nov 2015) incluant, pour chaque participant, 3 heures de coaching personnel sur un projet de leur choix, pendant, entre et après chaque jour de formation.

Inscriptions et Détails
Inscriptions et Détails

Objectif de cette formation-action

Outiller les gestionnaires de projets en développement de produits sur les techniques de gestion agile. Cette formation leur permettra d’accélérer leur projet, de mieux mobiliser leur équipe de développement et ainsi maximiser les bénéfices et le retour sur investissement.

Bénéfices pour les entreprises participantes

  • Claude Emond FormateurPréciser le rôle du chef de projets, en mode agile
  • Augmenter le taux de succès de vos projets de développement de produits
  • Maîtriser le savoir-faire qui permettra d’accroître votre efficacité en gestion de projets
  • Développer vos compétences pour mobiliser et guider les équipes de projets agiles vers le succès
  • Intégrer de nouvelles connaissances par la formation-action dans le cadre d’un projet en cours dans votre entreprise
  • Profiter de l’encadrement des formateurs entre les rencontres pour maîtriser les nouveaux outils et mener à bien votre projet ;
  • Développer les habiletés de leadership de vos chefs de projets implanter des outils de suivi pour livrer vos projets en respectant les coûts  et les délais.

Claude Emond formationQui devrait participer à ce programme de formation ?

Ce programme de formation spécialisé (voir la brochure détaillée) s’adresse aux personnes jouant le rôle de chefs de projets, ou membre d’équipe de projet, dans le cadre de projets de développement de produits et/ou de services.

Il est destiné à tous ceux qui désirent approfondir par l’action leurs connaissances en gestion de projets de développement de produits.

Une méthodologie ancrée dans l’action !

Ce programme unique de formation combine la présentation de notions théoriques et d’outils pratiques. Des exercices permettent d’appliquer les enseignements et d’utiliser les nouveaux outils dans le cadre d’un projet actuellement en cours dans votre entreprise. Entre les rencontres, vous devrez accomplir différentes tâches avec les membres de votre équipe de projet tout en bénéficiant d’une aide personnalisée de la part  du formateur.

De précédents billets de Claude sur l’Agilité:

un marshmallow, des spaghetti, quelques cm de ruban adhésif et de ficelle pour beaucoup de créativité et de teambuilding

Voici ce que nous propose Tom Wujec dans ce très simple exercice !

Plus surprenant encore, les résultats obtenus par diverses populations lorsqu’elles sont confrontés à ce challenge. Qui l’emporte entre des ingénieurs, architectes, PDGs, secrétaires, élèves de maternelle… ?

En fait, c’est la méthode qui importe le plus et dans le cas de cette exercice, une approche Agile basée sur des expérimentations rapides et répétées pour trouver la meilleure piste et l’exploiter pleinement.

CSP Formation
Partenaire de DantotsuPM

la certification PMI-ACP® en management de projets Agile du PMI® évolue en 2015

1,000 agilistes de 60 pays ont mis à jour la description du pratiquant de l’Agilité.

Comment la certification PMI-ACP® est-elle impactée ?

Pour tous les détails (en anglais)
Pour tous les détails (en anglais)

Un nouveau domaine est ajouté: Agile Principles and Mindset

62 tâches ont été validées dans le contexte des 7 domaines de pratiques:

  1. Agile Principles and Mindset (Nouveau)
  2. Value-driven Delivery
  3. Stakeholder Engagement
  4. Team Performance
  5. Adaptive Planning
  6. Problem Detection and Resolution
  7. Continuous Improvement (Product, Process, People)

Fin de la phase de test de cette mise à jour des tests le 15 Octobre.

Pour davantage de détails.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

le développement logiciel Agile du point de vue du métier

Voici une vidéo exceptionnelle de Henrik Kniberg 15 minutes expliquant et illustrant le développement logiciel Agile du point de vue du métier.

Certains d’entre vous connaissent sans doute déjà cette vidéo. Cependant, cette version a été doublée en Français par Florent Lothon qui trouvait difficile de lire la version originale sous titrée et apprécier les illustrations en même temps.

Une vidéo initialement produite par Henrik Kniberg.

Partenaire de DantotsuPM, LE blog du management de projet
Partenaire de DantotsuPM, LE blog du management de projet

adoptez une étoile de mer pour des rétrospectives Agile plus amusantes et productives

Starfish – http://www.funretrospectives.com/starfish/

L’ »étoile de mer » est une excellente activité lors de la collecte de données pour favoriser la réflexion autour des pratiques et de la valeur que l’équipe en retire. Elle aide des membres de l’équipe à comprendre la valeur perçue par chacun sur ces pratiques.

L’étoile de mer divise le tableau blanc en 5 zones :

  • Continuez à Faire – quelque chose que l’équipe réussit bien et dont vous reconnaissez la valeur.
  • Moins de – quelque chose de déjà fait; vous y constatez une certaine valeur, mais vous souhaitez le réduire un peu.
  • Plus de – quelque chose de déjà fait; et dont vous pensez qu’elle apportera encore plus de valeur si davantage utilisée.
  • Arrêter de Faire – quelque chose qui n’apporte pas de valeur, ou encore pire, qui empêche de progresser.
  • Commencer à Faire – une nouvelle idée, ou quelque chose vous avez vu marcher auparavant et que vous voudriez mettre sur la table de discussion.

Ci-dessous est un exemple d’étoile de mer (billet original de Coup Kua)

etoile 1Voici un exemple de rétrospective de Sprint d’une petite d’équipe. D’abord l’équipe écrit les notes: les billets bleus.

etoile 2Puis l’équipe discute vraiment de chaque note et ajoute les mesures à prendre: les billets jaunes.

etoile 3Simple et efficace ?

à vous d’en juger… et de laisser vos retours d’expérience dans les commentaires ci-dessous pour les autres lecteurs !

Partenaire de DantotsuPM
Partenaire de DantotsuPM

4 Agile values that changed the way software is developed !

The Agile Manifesto – 4 Agile Values Explained

See the Agile Manifesto’s 4 bold value statements that changed software development forever, and defined agile scrum as we know it today.

à quoi ressemble un management Agile de portefeuille de projet ?

What Agile Project Portfolio Management looks like

http://www.campana-schott.com/us/company/ceo-blog/blog-detail/what-agile-project-portfolio-management-looks-like/ par Christophe Campana

La conférence sur le Management de Portefeuille de projets informatiques (« IT Project Portfolio Management ») s’est tenue fin juin à Berlin. Rares sont les fois où j’ai ramené un message si clair après deux journées de conférences. Certes, il y avait plus de 20 présentations et ateliers qui ont partagé une variété d’expériences et de projets. Mais chaque présentation et discussion mettait en avant un même point critique : les entreprises et leurs portefeuilles de projet doivent devenir plus agiles.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Management de Projets Agile au niveau de l’entreprise

Les processus agiles pour les projets individuels sont devenus une banalité dans le management de projet.

Pour la plupart des grandes sociétés, c’est simplement une question de volume : chez certains, seulement 10 à 15 % des projets sont organisés utilisant des processus agiles, tandis que beaucoup d’autres gèrent déjà plus de 50 % de leurs projets de cette façon.

Au niveau stratégique il est important par contre de comprendre ce à quoi le Management Agile de portefeuille de projets peut ressembler au niveau de l’entreprise.

Selon Campana & Schott, on peut considérer les options suivantes:
  • portfolio
    Get the referential

    Aucune planification de A à Z des budgets et ressources (particulièrement en ce qui concerne les budgets annuels)

  • Des réajustements plus modestes mais plus fréquents des portefeuilles
  • Le passage d’une approche « Design to budget » au Management de portefeuille : moins de détails dans le cahier des charges du projet, au lieu de cela les budgets sont alloués à des thèmes spécifiques, des initiatives ou « des produits »
  • Au premier rang les bénéfices, c’est-à-dire quels budgets sont alloués à quels profits attendus ? Ceci peut être réalisé avec des cas d’affaires qui sont alors utilisés comme une base pour prioriser les budgets
  • Une considération est portée aux dépendances pas seulement dans les projets mais aussi entre les projets : comment ces dépendances sont-elles incluses dans la priorisation et des préparatifs de prise de décision ?
  • Plus d’accent sur la communication et les échanges d’informations entre projets

Des sociétés agiles ont besoin des bons collaborateurs

new skillsÉtonnamment, pratiquement toutes les présentations ont fini par souligner le même point : des compétences supplémentaires seront exigées des collaborateur dans le futur proche. Elles incluent de nouvelles qualifications pertinentes dans les projets, comme « Data Scientists » ces experts qui tirent des modèles économiques et des relations de travail de grands entrepôts de données.

Mais surtout, les sociétés agiles ont besoin des collaborateurs qui ont été familiarisés avec des environnements très exigeants. C’est une raison pour laquelle de grandes sociétés incluant Daimler et Microsoft investissent dans des startups, à savoir « injecter » les collaborateurs de ces startups dans leur propre main-d’œuvre.

Sans ces ‘perturbations’ externes, la culture d’entreprise de la société ne pourrait pas répondre assez rapidement aux nouvelles Meta Compétences comme l’orientation client systématique ou l’examen minutieux permanent et constructif de modèles économiques. L’exemple du « crowd-soucing interne » illustre la combinaison des deux mondes : une certaine partie du budget informatique est quasiment distribué aux collaborateurs. Ils peuvent alors assigner leur propre budget aux projets de leur choix et produisent ainsi le portefeuille qui est le plus prometteur de leur propre point de vue : celui-ci est porteur de très forte valeur.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Agile est le « nouveau normal »

Ce n’est pas seulement les projets qui sont agiles. Dans l’avenir, le focus sera sur la construction de management de portefeuille de projet plus agile au niveau de la société et donner davantage de pouvoir aux collaborateurs dans l’organisation qui implémenteront la transformation agile.

PS : Ceci vous donne-t-il matière à réflexion sur ce que pourrait être votre propre futur PPM ?
Partenaire de DantotsuPM, LE blog du management de projet
Partenaire de DantotsuPM, LE blog du management de projet

Scrum Alliance Report 2015 disponible gratuitement !

Tous les ans, la Scrum Alliance réalise une enquête sur l’utilisation et les évolutions de Scrum et en résume les résultats dans le State of Scrum report.

2015 State of Scrum ReportOn y trouve les taux d’adoption en entreprise (5000 réponses de 108 pays et 14 industries), les tendances actuelles, les prochaines évolutions telles que perçues par les pratiquants de la méthode.

Certaines statistiques sont révélatrices:

  • 87% estiment que Scrum améliore la qualité de vie au travail
  • 56% utilisent les cérémonies de Scrum avec discipline
  • 71% pensent que leur utilisation de Scrum crée des tensions avec d’autres parties de l’organisation qui ne l’utilisent pas
  • 59% of des ScrumMasters certifiés et 81% pensent que cela les aide à améliorer leurs pratiques
  • 93% des projets Scrum supervisés par un PMO réussissent

L’essayer c’est l’adopter puisque 95% vont continuer à utiliser Scrum

The report est téléchargeable gratuitement (en anglais) sur le site de la Scrum Alliance.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

l’examen PMI-ACP® change en 2015

Récemment, une revue de rôle avec plus d’un millier d’agilistes œuvrant dans 60 pays a permis de mettre à jour la description des pratiquant des méthodes Agiles. L’examen pour la certification PMI-ACP® est en cours d’adaptation très Agile.

En quoi le PMI-ACP® change-t-il?

ACPUn nouveau domaine apparait: Les principes et l’état d’esprit Agile (Agile Principles and Mindset). Ses concepts existaient bien sûr déjà dans les 6 domaines de bonnes pratiques (qui deviennent 7) mais était disséminé sur ceux-ci.

62 tâches ont été validées dans de contexte de ces 7 domaines:

  1. Check this past article and Video
    Check this past article and Video

    Agile Principles and Mindset Domain (NOUVEAU)

  2. Value-driven Delivery Domain
  3. Stakeholder Engagement Domain
  4. Team Performance Domain
  5. Adaptive Planning Domain
  6. Problem Detection and Resolution Domain
  7. Continuous Improvement (Product, Process, People)
Partenaire de DantotsuPM
Partenaire de DantotsuPM

Dates

Un pilote est en place du 15 Juillet au 15 Octobre pendant lequel vous pouvez obtenir 20% de réduction sur votre inscription
Tous les détails sur le site du PMI, ici.
 

quelles sont les contraintes dans l’utilisation du Nombre de Dunbar ?

Constraints on the use of Dunbar’s Number

https://tcagley.wordpress.com/2015/05/21/constraints-on-dunbars-number/ Par T Cagley

Robin Dunbar
Robin Dunbar

Le nombre de Dunbar représente une limite théorique au nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Des relations sociales stables sont nécessaires pour supporter l’application des valeurs, principes et techniques Agile. Le nombre de Dunbar est souvent cité comme étant de 150 personnes. Cependant, la limite pour n’importe quel groupe est non seulement le reflet d’une limite comme le nombre de Dunbar, mais aussi dépendante du contexte. Si nous acceptons qu’il y a une certaine limite théorique que nous ne pouvons pas dépasser comme le nombre de Dunbar, nous devons nous demander comment d’autres projets ou facteurs exogènes contraignent encore davantage le nombre maximum de personnes travaillant sur un problème. Pourquoi se donner tant de mal pour augmenter le nombre de personnes travaillant sur un problème ? Beaucoup d’Agilistes suggéreraient qu’une unique petite équipe est optimale. Cependant, beaucoup de problèmes exigeront une plus grande collation d’équipes pour délivrer la valeur et la fonctionnalité.

Dunbar NumberLes éléments contextuels supplémentaires qui modifient le nombre maximum théorique de personnes dans un groupe ou une équipe d’équipes incluent au moins quatre facteurs:

1. Cohésion

Ou dans quelle mesure les gens restent ensemble. Il y a beaucoup d’attributs qui peuvent produire la cohésion.

cohesionLes exemples incluent : grandes idées, objectifs, nationalités, religions et même identité d’entreprise.

La cohésion favorise une relation commune qui entraine les groupes à investir volontairement davantage d’efforts pour atteindre un but. Par exemple, il est souvent difficile de réaliser un groupe cohésif quand les membres viennent de multiples et externes entités de conseil. Chaque organisation impliquée dans le groupe a un jeu différent de buts organisationnels qui réduisent la cohésion à moins qu’ils ne soient subjugués par l’objectif du projet. La réduction du nombre de personnes en-dessous du nombre de Dunbar rend plus facile l’utilisation de techniques comme la pression entre pairs pour institutionnaliser une vision de projet qui augmente la cohésion.

2. Complexité

Est une mesure du nombre de propriétés d’un projet qui sortent de la norme.

sketchingLa complexité d’un problème réduit le nombre maximum optimal de personnes qui peuvent être impliquées parce que la complexité exige généralement plus de contrôle et de coordination ou des équipes plus petites pour assurer la collaboration.

3. Incertitude

Survient quand les équipes cherchent une réponse à un problème business ou technique.

small teamQuand une équipe doit aborder un problème métier inconnu ou une nouvelle technologie, de la recherche est souvent nécessaire. La recherche est généralement contrainte à de petites équipes avec des compétences spécialisées ce qui réduit la taille de groupe maximale optimale pour ce type d’effort bien en dessous du nombre de Dunbar.

Comme on découvre des concepts et des idées, certains peuvent être déployés plus largement pour être étoffés, prototypés et implémentés en augmentant le groupe travaillant sur le projet en direction du nombre de Dunbar.

4. Dépendances

Quand elles existent entre des composants, cela signifie souvent que le travail doit être concentré (ou du moins s’étendre moins largement).

effet domino dans les dérivesLes dépendances réduisent le nombre de personnes et d’équipes qui peuvent être efficacement utilisées.

L’idée d’augmenter le nombre de personnes et d’équipes travaillant sur un projet semble souvent être un mécanisme pour délivrer de la valeur plus rapidement. En ajoutant des personnes, il est suggéré de se souvenir que le nombre de personnes travaillant sur un problème est une contrainte qui ne peut pas être traitée en augmentant linéairement le nombre de personnes impliquées sur un problème jusqu’à atteindre une limite comme le nombre de Dunbar.

Le contexte a un impact direct sur la taille que tout groupe peut atteindre avant que l’administration et autres contraintes en réduisent l’efficacité. Il est souvent dit que neuf femmes ne peuvent pas faire un bébé en un mois. En plus du nombre de Dunbar, le contexte joue un rôle important dans la définition de la taille totale de l’équipe.

Précédent billet sur ce sujet: montée en volume d’Agile : le nombre de Dunbar

montée en volume d’Agile : le nombre de Dunbar

Scaling Agile: Dunbar’s Number

https://tcagley.wordpress.com/2015/05/19/scaling-agile-dunbars-number/ par T Cagley

Robin Dunbar
Robin Dunbar

En déterminant de quelle taille un programme Agile pourrait être, un des « faits » souvent cité est que le nombre de personnes impliqué dans un programme Agile est soumis au nombre de Dunbar. Le nombre de Dunbar est la limite du nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Le terme, relation sociale est le reflet d’interactions régulières, la capacité de reconnaître un autre membre dans le cadre du groupe ou d’être engagés sur un but commun. Ces attributs sont importants pour tout projet et sont peut-être plus importants dans les projets Agile parce que ceux-ci comptent sur la cohésion d’équipe pour minimiser les mécanismes de contrôle et la bureaucratie.

Le concept du nombre de Dunbar est basé sur de la recherche à l’origine exécutée par les observations de primates et étendue ensuite aux humains au début des années 1990. En juin 1992, Robin Dunbar publié « La taille du néocortex comme contrainte de la taille de groupe chez les primates » dans le Journal of Human Evolution (Volume 22, Edition 6, juin 1992, pages 469-493). Dans ce papier, Dunbar a mis en évidence une corrélation entre la taille du cerveau d’un primate et la taille moyenne de groupe social.

En résumé, Dunbar a écrit :

La taille de groupe se révèle être une fonction de volume néocortical relatif, mais les variables écologiques ne le sont pas. Ceci est interprété comme l’évidence en faveur de la théorie d’intellect social et à l’encontre des théories écologiques. Il est suggéré que le nombre de neurones du néocortex limite la capacité de traitement de l’information de l’organisme et que ceci limite alors le nombre de relations qu’un individu peut contrôler simultanément. Quand la taille d’un groupe excède cette limite, le groupe devient instable et commence à se fragmenter. Ceci situe alors une limite supérieure pour la taille des groupes que n’importe quelle espèce donnée peut entretenir comme des unités sociales cohésives dans la durée.

Dunbar Number

Bien que la taille de groupe de 150 soit souvent citée comme le nombre de Dunbar, 150 est une approximation.

Comme indiqué dans le « Les limites d’Amitié » (Limits of Friendship) par Maria Konnikova (7 octobre 2014) le nombre de Dunbar peut aller de 100 à 200 personnes selon des facteurs comme le fait d’être sociable. D’autres limites de taille de groupe ont aussi été publiées par d’autres docteurs comme Peter Killworth et Russell Bernard qui indiquent plus de 200 personnes.

Selon le nombre de Dunbar, le Scaled Agile Framework Enterprise (SAFe) suggère que les plus grandes Releases Agile (ART) pourraient inclure environ 150 personnes. L’ART est supporté par un cadre (le framework SAFe), une hiérarchie ( des ingénieurs de Release et des ScrumMasters) et une bureaucratie (un management de produit et des propriétaires de produits). Quand Agile est pratiqué par une équipe de 5 à 9 personnes cette « surcharge administrative » ne serait pas nécessaire pour assurer la coordination.

croire en soi et ses capacitésLa mise à l’échelle d’Agile est un numéro d’équilibriste entre efficacité des techniques Agiles au niveau de l’équipe et les concessions faites pour contrôler quand Agile est utilisé sur de plus grands efforts.

Historiquement, les très grands projets ont tendance à être moins efficaces. Capers Jones dans Applied Software Measurement, Third Edition (P295) indique que la productivité chute pour tous les types de projets lorsqu’ils excèdent 1000 points de fonction. Les points de fonction sont une méthode du standard ISO pour mesurer la taille du logiciel basée sur un ensemble de règles standard. Tout simplement, plus un projet est grand en points de fonction et plus grande sera l’équipe (ou l’équipe d’équipes) qui devra livrer le projet. D’où le besoin de plus de contrôle toutes choses égales par ailleurs. Il met en exergue (p 307) le fait que comme la taille de projet augmente, la probabilité d’annulation croit pareillement.

Le livre référence
Le livre référence

La montée en volume d’Agile nécessite beaucoup de techniques utilisées au niveau d’une équipe Agile, comme la petite taille d’équipe, le travail par petits lots de fonctionnalités et Scrum. Ces techniques sont très « Lean », mais limitées par la quantité de valeur qui peut être délivrée dans une période spécifique de temps. Comme les projets Agiles grandissent en taille, des techniques supplémentaires sont nécessaires pour maintenir le contrôle. Le nombre de Dunbar (ou des idées similaires) fournit une limite pour essayer d’éviter de laisser un travail devenir trop important pour être gérable. Le nombre agit comme une limite au nombre de personnes impliquées dans un travail. L’application de contraintes supplémentaires, comme des releases ou des incréments de programme SAFe, ajoutent la dimension de temporalité comme contrainte. La combinaison des contraintes sur le nombre de personnes et combien de temps ces personnes travailleront fournit une contrainte explicite de combien de travail peut être livré.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Why use Agile when PRINCE2 is what you know? FREE download

QRP International France
Partenaire de DantotsuPM
Agile expalined for Prince2 Practitioners
Get the ebook

This FREE download follows on from Melanie Franklin’s last one on how to explain Agile to your organisation.

Here Melanie talks about how Big Design Up Front can be replaced, the value of Feedback Loops, how agile delegation works and the importance of networking.

AGILE AND THE EFFICIENT ORGANISATION Part 2

Partenaire de DantotsuPM
Partenaire de DantotsuPM

à propos de Scrum par QRP International

scrum methodologie agile
Voici le diagramme du Modèle Scrum

Scrum est une méthode Agile pour la réalisation de projets complexes. A l’origine, la méthodologie Scrum a été élaborée pour le développement de projets IT, mais la méthode s’avère aussi très efficace pour régir tout environnement de travail complexe et innovant. Les possibilités sont donc sans fin. La structure simple de Scrum peut être appliquée à tout type de projet ou développement produit. Scrum peut ainsi fournir une base et une méthode collaborative, saine et agréable pour atteindre les objectifs de l’entreprise.

Scrum est la première méthodologie de développement Agile, utilisée par les Fortune 500 entreprises mondiales. C’est une structure de travail solide et agile qui a déjà prouvé son application à une grande variété de projet et d’équipe. Ainsi la raison d’être de la Scrum Alliance est d’apporter de nouvelles solutions en matière de gestion de projets complexes, et d’ouvrir la méthodologie Scrum et les principes agile au-delà du secteur IT, vers tous les secteurs d’activités.

LES AVANTAGES DE SCRUM

  • Scrum est une approche basée sur l’équipe, comme un moyen pour créer de la valeur pour l’entreprise. Les membres de l’équipe travaillent ensemble pour atteindre un but commun. La méthodologie Scrum vise à encourager les échanges entre les membres de l’équipe pour qu’elle puisse apporter de la valeur à l’entreprise.
  • Scrum exige une avancée du travail de conception du produit fini au début de chaque « Sprint ». Peu importe les activités engagées pendant le « sprint », l’attention est portée la réalisation du produit.
  • Scrum est une méthodologie élaborée de manière à promouvoir et faciliter la collaboration. Les membres de l’équipe collaborent entre eux pour trouver la meilleure solution pour construire et livrer le logiciel, ou autres sortes de livrable, à l’entreprise.
  • Les équipes Scrum font des plans fréquents. Ces plans aident les équipes et l’entreprise à prendre des décisions. Cependant, le but n’est pas que l’équipe suive le plan aveuglément mais de permettre la création de valeur et l’adoption des changements dans l’organisation.

LES FAITS MARQUANTS SCRUM

  • scrum user group francePlus de 368 000 certifiés Scrum Alliance
  • Utilisé dans plus de 175 pays à travers le monde
  • La Scrum Alliance possède approximativement 275 groupes d’utilisateurs à travers le monde. 
  • Utiliser dans de nombreuses industries à travers le monde : développement de logiciel, enseignement, marketing, opération, militaire, automobile et plus encore.

LE ROLE DE SCRUM

cliquez sur l'image pour télécharger ce guide gratuit en français
cliquez sur l’image pour télécharger ce guide gratuit en français

Une équipe Scrum à trois rôles :

  • Le Scrum Master – Soutient l’équipe pour utiliser au mieux Scrum dans l’élaboration du produit.
  • Le Propriétaire du produit (Product Owner) – Maintient la vision du produit.
  • Le Développeur (Development Team) – Construit/élabore le produit.

PARCOURS DE QUALIFICATION SCRUM

La formation et la certification Scrum remplissent la vision du manifeste Agile en favorisant de meilleures collaborations, productivité et succès parmi les membres de l’équipe.

  • La formation Certified Scrum Master® est sur les fondamentaux et s’adresse aux membres de l’équipe Scrum ou les professionnels Scrum Master.
  • La formation Certified Scrum Product owner® expose aux participants les fondamentaux de la méthodologie mais cette fois du point de vue du Product Owner.
  • La formation Certified product Developer® forme les membres de l’équipe Scrum avec des techniques avancées d’ingénierie Agile et d’autres techniques Agile, qu’il est nécessaire de posséder pour la création de logiciels, en complément des fondamentaux Scrum developer.
  • La reconnaissance ultime pour tous les praticiens Scrum, est l’obtention de l’accréditation Certified Scrum Professional® qui permet de prouver sa véritable connaissance et son expérience Scrum.

Pourquoi adopter Scrum avec QRP International

Institut International de Conseil et de Formation Accrédité aux Bonnes Pratiques PRINCE2® (Gestion de Projet), ITIL® (Gouvernance du SI), P3O® (Management d'un PMO) et MSP® (Management de Programme).
Partenaire de DantotsuPM

ne vous précipitez pas sur la dette (technique) par Jeff Ball

Bien faire ou faire vite? Il y a parfois un prix à payer quand on “fait vite”. C’est ce qu’on appelle la Dette Technique.

facturesMS-DOS est probablement l’exemple le plus connu de Dette Technique. En 1981, IBM demanda à Bill Gates de développer un système opératif pour son nouveau PC. Pour respecter les délais, il prit le QDOS (Quick and Dirty Operating System, Système Opératif Vite fait Mal fait) et le renomma MS-DOS. Bâclé et grossier, MS-DOS a été alourdi par une dette dès sa conception, il était doté d’un ensemble de commandes qui laissaient à désirer et de caractéristiques limitées.

Dans le monde de la gestion de projet, le respect des délais est un point clé pour mesurer la réussite de la plupart des projets. En vous pressant pour respecter les délais, il se peut que vous accumuliez une dette sans vous en rendre compte, silencieusement… mais de manière constante.

La Dette Technique peut prendre les formes suivantes:

  • developer womanDocumentation ou manuel d’utilisation inexistants
  • Programmation de mauvaise qualité (non structurée, avec peu de commentaires, codage en dur)
  • Bases de données mal structurées (données redondantes, erreurs de données)
  • Mauvaise conception (mauvaise architecture, non modulable)
  • Mauvais processus (inefficaces, entraînant une perte de temps, sujets à erreurs)

Habituellement, on parle de dette pour des projets de développement de logiciels, mais elle ne s’applique pas uniquement au software – toutes sortes de projets peuvent générer une dette.

Souvent, la Dette Technique est issue de la pression exercée pour respecter les délais, mais ce n’est pas seulement une question de précipitation.

Plusieurs facteurs peuvent être source de dette :

  • Image courtesy of ambro / FreeDigitalPhotos.net
    Image courtesy of ambro / FreeDigitalPhotos.net

    La vitesse: la précipitation est probablement la première cause de Dette Technique

  • Vision à court terme: rapiéçage et raccommodage. Solutions dénuées d’architectures
  • Contre-la-montre: efforts concentrés sur le retard accumulé (au lieu de penser au futur)
  • Innovation de pointe : apprentissage sur le tas
  • Manque de compétences: assignation de personnel n’ayant pas les bonnes compétences (ou pas de compétences du tout) à des tâches complexes.

Pourquoi s’en inquiéter?

La Dette Technique est comme la dette financière… vous pouvez l’ignorer pendant un temps, mais l’accumulation de dette reviendra vous hanter. En présence de dette, le résultat final sera chaotique – un patchwork ou un sac de nœuds difficile à comprendre ou à changer.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Ce sera une surcharge potentielle pour tout ce qui sera entrepris par la suite – la Dette Technique peut ralentir et compliquer des projets futurs. Elle peut aussi engendrer un vieillissement prématuré – l’accumulation de dette peut raccourcir la durée de vie de votre solution.

Ne vous précipitez pas sur la dette.

le livre de Chris Sterling
le livre de Chris Sterling

La principale source de dette est la précipitation. Certaines méthodes de gestion de projet se basent sur la rapidité ; c’est le cas de la plupart des variantes légères d’Agile. Ces dernières, comme Scrum, généreront nécessairement une dette si l’on se focalise trop sur la rapidité. Les délais seront peut-être respectés, mais si c’est au prix d’autres facteurs de bonnes pratiques, tels que le design, la planification ou la qualité, alors il se peut que vous accumuliez une dette.

Il existe deux façons de contourner ce problème pour les projets Agile : essayer de rendre cette méthode légère plus robuste (comme décrit dans le livre « Managing Software Debt » de Chris Sterling) ou utiliser une solution Agile.

Pourquoi utiliser Agile?

APMG-AgilePMLes méthodes Agile telles que DSDM Atern (parfois appelée AgilePM) permettent de combiner agilité avec architecture et design. Atern possède également un ensemble d’outils assurant une approche à long terme (plans, étude de rentabilité, etc.) – qui aident aussi à établir le compromis entre rapidité et dette (et par conséquent à éliminer ou réduire la dette).

Quelle que soit la solution que vous choisissiez, que vous utilisiez Agile ou non, vous devez garder cette notion de dette à l’esprit.

Jeff Ball
Jeff Ball

Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :

  1. Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
  2. Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
  3. Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
Institut International de Conseil et de Formation Accrédité aux Bonnes Pratiques PRINCE2® (Gestion de Projet), ITIL® (Gouvernance du SI), P3O® (Management d'un PMO) et MSP® (Management de Programme).
Partenaire de DantotsuPM

© Copyright QRP International 2011. Reproduction in full or part is prohibited without prior consent from QRP International

Pour aller plus loin:

May 7 – Geneva – Lean Projects Start with a Lean Backlog

In order to stay competitive, product development organizations must deliver more valuable products to the market faster.

wikipedia leanThe failure of some organizations to get the right product fast enough has sparked (a much needed and long lasting) debate to find a « perfect » innovation process that could develop any product faster and better than anyone else. New project management methods such as the lean startup, SCRUM, lean product development and so fourth make fairly similar promises to fix very difficult challenges.

The truth is rather that there is no quick fix to deliver great products in such a short time. Instead, successful companies use pragmatic approaches where the solution varies greatly depending on their specific context. One trend places the backlog in the center. It has been proven that, if properly adapted to the context, lean backlog management together with actionable metrics can make a major impact on project success.

The presentation Lean Projects start with Lean Backlog will have three parts:

a summary of some theory behind a great backlog, a walkthrough of two cases from very different organizations with similar lessons learned and finally our suggestions on how to get started with lean backlog management and actionable metrics.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Migrer vers l’agilité, c’est migrer vers une nouvelle culture «plus performante» par Claude Emond

«Le contexte conditionne le comportement.» Charles Pellerin

L’agilité organisationnelle, peu importe son application en projet ou ailleurs dans une entreprise, nécessite un changement de culture.

Une entreprise agile est basée sur une culture :

  1. culturecollaborative, par opposition à directive et contrôlante;
  2. qui aime, accueille activement et s’adapte facilement au changement;
  3. qui est centrée sur l’humain et le respect mutuel;
  4. dont la raison d’être est la production de valeur optimale pour l’ensemble de ses parties prenantes (fournisseurs,   partenaires, employés, clients, actionnaires,   la société).

Ces quatre «valeurs» lui permettent de mieux fonctionner que d’autres types de cultures dans un environnement turbulent, tel que celui qui caractérise ce début de 21e siècle.

L’organisation agile utilise des approches et des pratiques spécifiques qui visent à vivre et matérialiser ces valeurs :

  • former, entrainer, nourrir
    nourrissez l’agilité

    elle a une vision et une mission claires, partagées par l’ensemble de ses employés et partenaires;

  • elle tient compte des intérêts de chacun et en favorise l’alignement;
  • elle favorise l’engagement de tous pour la réussite autant collective qu’individuelle;
  • elle favorise le réseautage entre les silos spécialisés et le travail transversal;
  • elle favorise la décentralisation dans la prise de décision et l’autonomie d’action des individus et des équipes;
  • elle favorise la responsabilisation individuelle et l’imputabilité collective;
  • elle favorise la collaboration et l’entraide entre ses employés plutôt que la compétition;
  • elle favorise   la transparence,   ainsi que la communication  et le partage d’information en continu;
  • elle valorise et favorise la proactivité, la créativité et la réactivité autant individuelles que collectives.

Elle appuie ces approches et pratiques en mettant en place des structures, des processus et des outils de support réactifs, flexibles et adaptables ET en fournissant les ressources suffisantes pour leur bon fonctionnement.

Enfin, l’organisation agile utilise un système de reconnaissances (incitatifs et autres) qui renforce le maintien et l’amélioration de l’ensemble de ses attributs agiles :

caractéristiques organisation Agile

Serez-vous les premiers à adopter une culture agile dans votre industrie?

Winston Churchill
Winston Churchill

«Mieux vaut prendre le changement par la main avant qu’il ne nous prenne par la gorge.»

Winston Churchill

La gestion de projet agile est encore très peu répandue dans les secteurs autres que le développement   logiciel. Elle progresse de plus en plus vite dans d’autres domaines, comme le développement de nouveaux produits, en réponse aux pressions de plus en plus grandes de maximiser les bénéfices dans un monde où les ressources naturelles, humaines et autres se font de plus en plus rares.

La marche, sinon la course vers l’agilité organisationnelle s’accélère et ceux qui suivront ce chemin assureront plus que tous les autres leur viabilité et leur pérennité à plus ou moins moyen terme[i].

[i] Cet article est un extrait mis à jour du document «Quelques précisions sur l’agilité organisationnelle», Claude Emond, 2012, http://fr.slideshare.net/claudee/agilit-organisationnelle

Cet article est le troisième et dernier d’une courte série produite par Claude:

  1. La Gestion de Projet «traditionnelle» et ses réalisations
  2. la Gestion de Projet Agile

la Gestion de Projet Agile par Claude Emond

«Rien n’est permanent, sauf le changement.» Héraclite

La firme TOP (Totally Optimised Projects), un des leaders mondiaux en réalisation des bénéfices, a évalué le pourcentage de bénéfices réalisés pour chacun des 7 niveaux de livraison en mode projet, résultats très souvent confirmés dans les faits. La figure suivante présente cette évaluation sous forme graphique[i].

Pourcentage de bénéfices possibles réalisés selon le niveau de livraison d'un projet
Pourcentage de bénéfices possibles réalisés selon le niveau de livraison d’un projet

Nous pouvons voir qu’un projet qui livre «dans les temps et dans les coûts», comme unique préoccupation, ne livre pas plus que 30% des bénéfices possibles. Si les «spécifications ‘initiales’ sont respectées», ces spécifications n’étant pas ajustées en cours de réalisation de projet pour tenir compte de l’évolution des besoins, un tel projet peut livrer entre   30 et 50 % des bénéfices possibles… ce en ne respectant pas nécessairement les délais et coûts initialement prévus.

Atteindre les niveaux 6 et 7 passe obligatoirement par une gestion de projet épousant les valeurs et appliquant les principes et ayant les caractéristiques d’une organisation agile de haut niveau.

La figure suivante présente un cadre conceptuel adaptant les éléments de l’agilité à la réalisation des projets.

Claude Emond - Qualiscope management Agile
Cadre conceptuel de la gestion de projet en mode «agile»

Cadre conceptuel de la gestion de projet en mode «agile»

Ce cadre résume en 4 valeurs, 4 pratiques et 10 principes , l’état d’esprit et les pratiques spécifiques observés dans les applications de l’agilité en projet, notamment :

  • la gestion «agile» des projets d’innovation et de développement de nouveaux produits (informatiques et autres), et
  • la gestion «LEAN» utilisée par les spécialistes du Lean Construction Management.

En intégrant ces éléments avec ceux d’une «organisation agile», nous obtenons l’équation suivante, qui présente l’ensemble des caractéristiques de la gestion de projet agile.

PRODUCTIVITÉ = A1 + A2 + V = PERFORMANCE OPTIMALE

Une organisation AGILE c’est, dans un contexte d’affaires turbulent, (très complexe, hautement compétitif, incertain, en changement constant, exigeant une grande vélocité et un haut niveau de créativité afin d’innover et s’adapter sans cesse) où nous avons :

trust confianceA1 / Alignement du QUI

Un ensemble de personnes COLLECTIVEMENT ENGAGÉES où toutes les parties prenantes sont alignées, parce qu’elles ont:

  • des valeurs partagées (même culture)
  • une vision partagée
  • des intérêts convergents
  • une mesure commune du succès
  • les connaissances requises
  • des comportements collaboratifs
  • et sont engagées à réussir ensemble
A2/ Agilité du Comment, Quand, Combien

AVEC PROACTIVITÉ, CRÉATIVITÉ, GRANDE RÉACTIVITÉ, FLEXIBILITÉ ET ADAPTABILITÉ

Ces personnes font très bien, en utilisant des approches et outils AGILES (COMMENT, QUAND, COMBIEN), notamment:

  • Agile 2une ouverture et une capacité de s’adapter au changement
    • une structure, une organisation, des technologies flexibles et adaptables
    • des ressources SUFFISANTES flexibles et adaptables
    • l’apprentissage et la capitalisation des leçons apprises en continu
  • des pratiques de veille et d’innovation (créativité) axées sur la création optimale de valeur (bénéfices)
  • des pratiques valorisant les RH et encourageant la collaboration
V/ Valeur Optimale

BÉNÉFICES «QUOI, POURQUOI», POUR TOUS

Ces personnes font LES bonnes choses, CELLES OPTIMISANT LA VALEUR POUR TOUS

selectionLES bonnes choses, soit la raison d’être de l’organisation et des parties prenantes

  • des livrables négociés (QUOI)
  • maximisant les bénéfices et la valeur (POURQUOI)
  • pour toutes les parties prenantes (POUR QUI)

Résultat : PRODUCTIVITÉ = A1 + A2 + V = PERFORMANCE OPTIMALE

Caractéristiques de la gestion de projet agile

Visitez le nouveau site web de Claude !
Visitez le nouveau site web de Claude !

En quelques mots, la gestion de projet en mode «agile» c’est, dans un environnement d’affaires turbulent:

  • l’ensemble des parties prenantes d’un projet, COLLECTIVEMENT ENGAGÉES,
  • qui réalisent très bien, en respectant les attentes quotidiennes de chacun, AVEC PROACTIVITÉ, CRÉATIVITÉ, GRANDE RÉACTIVITÉ, FLEXIBILITÉ ET ADAPTABILITÉ
  • LES bonnes choses, soit LES LIVRABLES OPTIMISANT LA VALEUR POUR TOUS

Et c’est de cette façon qu’on atteint une performance exceptionnelle et qu’on réalise des projets donnant les meilleurs résultats possible[ii].

Cet article est le second d’une courte série de 3 billets produite par Claude :

  1. La Gestion de Projet «traditionnelle» et ses réalisations

[i] THE CHOICE, Jed Simms et Alex Chapman, 2011, maintenant disponible sur Kindle, http://www.amazon.fr/Choice-English-Jed-Simms-ebook/dp/B00KEK26GM

[ii] Cet article est un extrait mis à jour du document «Quelques précisions sur l’agilité organisationnelle», Claude Emond, 2012, http://fr.slideshare.net/claudee/agilit-organisationnelle

La Gestion de Projet «traditionnelle» et ses réalisations par Claude Emond

Voici le premier d’une série de 3 articles qui nous mèneront de la gestion de projet « traditionnelle » à l’Agilité !

«Aucun problème ne peut être résolu sans changer le niveau de conscience qui l’a engendré.»

Albert Einstein

La gestion de projet «traditionnelle» n’est pas nécessairement celle documentée dans le PMBoK, le Project Management Body of Knowledge,   du PMI (Project Management Institute). Bien que ce document ne soit pas parfait, il est en évolution constante et inclut maintenant dans sa dernière édition plusieurs des principes de l’agilité.

Le guide en français
Le guide en français

Dans les faits, tout ce qui est documenté dans le PMBoK est utilisable en gestion de projet «agile».

Il suffit d’utiliser ces pratiques et outils dans un état d’esprit   collaboratif «gagnant-gagnant», plutôt que dans un état d’esprit conflictuel, contrôlant et compétitif «gagnant-perdant».

De plus, très peu d’organisations   prétendant appliquer le PMBoK, ont vraiment des processus et des pratiques couvrant l’ensemble des volets de la gestion de projet (parties- prenantes, contenu, qualité, bénéfices, changements, risques, communications, intégration, etc.).

La plupart ne se préoccupent que du triangle «contenu-délais-coûts», en considérant les délais et les coûts comme des livrables, plutôt que comme des contraintes à respecter OU À REDÉFINIR AU BESOIN SELON L’ÉVOLUTION DU PROJET, en réponse à des événements imprévus, des ajouts de contenu ou tout simplement pour saisir de   nouvelles opportunités. Pour ces organisations, le coût d’un projet est plus important que le retour sur l’investissement (les bénéfices qu’on retirera de l’utilisation des livrables). Et, pour ces organisations, le tout se réalise dans un état d’esprit de compétition et à travers de nombreux conflits et litiges qui perdureront longtemps après l’achèvement des livrables des projets et leur transfert contractuel aux «clients».

En quelques mots, la   gestion de projet en mode «traditionnel», celle qui est encore pratiquée par la majorité des entreprises réalisant des projets et «subie» par leurs clients, leurs partenaires, employés et fournisseurs, c’est, dans un environnement d’affaires turbulent :

  • un ensemble limité de personnes,
  • qui font de façon conflictuelle, plus souvent en s’affrontant qu’en collaborant,des choses (activités ou tâches, souvent pas les bonnes),
  • devant respecter à tout prix un délai et un budget pas toujours réalistes.

En termes de bénéfices réalisés, les résultats sont alors très variables, sinon décevants.

La figure suivante [i] résume les 7 types de résultats qu’un projet peut livrer «en termes de bénéfices»

7 types de bénéficesLa firme TOP (Totally Optimised Projects), un des leaders mondiaux en réalisation des bénéfices, a évalué le pourcentage de bénéfices réalisés pour chacun des 7 niveaux de livraison, résultats très souvent confirmés dans les faits. La figure suivante présente cette évaluation sous forme graphique.

%benef possibles projet
Pourcentage de bénéfices possibles réalisés selon le niveau de livraison d’un projet.

Nous pouvons voir qu’un projet qui livre «dans les temps et dans les coûts», comme unique préoccupation, ne livre pas plus que 30% des bénéfices possibles.

Si les «spécifications ‘initiales’ sont respectées», ces spécifications n’étant pas ajustées en cours de réalisation de projet pour tenir compte de l’évolution des besoins, un tel projet peut livrer entre   30 et 50 % des bénéfices possibles… ce en ne respectant pas nécessairement les délais et coûts initialement prévus.

the choice
The Choice

Comme nous le verrons dans un prochain article[ii], l’objectif de la mise en place d’un nouveau processus de gestion de projet est de faire mieux que cela, et même, à moyenne échéance, de permettre à l’entreprise adoptant ce nouveau processus et à ses clients d’atteindre des résultats de niveaux 6 ou 7 le plus souvent possible.

[i] THE CHOICE, Jed Simms et Alex Chapman, 2011, maintenant disponible sur Kindle.

[ii] Cet article est un extrait mis à jour du document «Quelques précisions sur l’agilité organisationnelle», Claude Emond, 2012.

Free ebook – Waterfall to Agile: Making the Transition to Agile or a Mixed Methodology Approach

20 Agile and project management practitioners and authors share some of their experience on the topic.

at task waterfall to Agile
Go to the download page

It’s a 45 pages wide-ranging collection of testimonials addressing a wide range of aspects:

  • Agile state of mind
  • Is Agile right for you?
  • Lean Startup
  • Empowering Agile teams
  • Easing your transition to Agile
  • Selling Agile
  • ….

You can download it for free, here.

« Peut-on améliorer la performance des projets par l’Agilité organisationnelle ? » par Meta Projets Management et PMI France branche Rhône-Alpes

« Peut-on améliorer la performance des projets par l’Agilité organisationnelle ?  »

Lisez l’article complet relatant cet événement sur le site du PMI France

Invités par l’école ENSIMAG du groupe Grenoble-INP et la Branche Rhône-Alpes du PMI France, Agnès LAVILLE fondatrice de Méta Projets Management et Frédéric RODRIGUEZ, Consultant, Coach et Formateur Indépendant,  ont animé avec une grande agilité le 27 Novembre, pour un public de plus de 120 industriels, enseignants et étudiants, une conférence et des ateliers  pour  expérimenter comment améliorer la performance des projets par l’agilité organisationnelle.

Agnès Lavigne
Agnès Lavigne

La philosophie Agile utilise des modèles organisationnels basés sur les personnes, la collaboration et des valeurs partagées. Elle met en œuvre une planification récurrente, des livraisons itératives et progressives, 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 de management de projets a augmenté radicalement dans les dernières années. Mais:

  • Comment se définit l’Agilité organisationnelle ?
  • Quelles pratiques mènent à plus d’Agilité ?
  • L’Agilité permet-elle aux organisations d’augmenter le taux de réussite de leurs projets ?

Plutôt que de réaliser un exposé formel, la dynamique équipe de Méta Projets Management invite les participants à se regrouper en ateliers de 9 ou 10 personnes autour de plaques disposées dans l’amphi.

A chaque atelier est proposé un scénario de plusieurs projets à réaliser par une entreprise en fonction des demandes de plusieurs clients tout en en tenant compte des tâches successives à réaliser, de leurs coûts de réalisation, des ressources limitées de la production, des gains escomptés, de la facturation à fourniture du produit demandé et bien entendu de la satisfaction des clients.

Les cartes posées sur la table correspondent aux différentes « user stories » mises en production par les participants afin de satisfaire les demandes clients.
Les cartes posées sur la table correspondent aux différentes « user stories » mises en production par les participants afin de satisfaire les demandes clients.

Rapidement chaque atelier au moyen des cartes descriptives de tous les besoins s’attelle à prioriser l’enchainement des travaux à faire afin de satisfaire au mieux l’ensemble des exigences naturellement contradictoires.

Comme dans la vraie vie, au fil du temps, des changements arrivent à travers de nouveaux besoins clients ou de nouveaux clients. Agnès au micro cadence plusieurs itérations invitant chaque groupe à découvrir les changements distribués dans de nouvelles enveloppes. La petite équipe de Méta Projets Managements passe d’ateliers en ateliers pour prodiguer les conseils et récompenser chaque mise en production par un paquet de bonbons au chocolat.

Au bout d’une heure et de trois itérations, Agnès en conclusion de la soirée invite les rapporteurs de chacun des groupes d’annoncer leurs résultats en terme de nombre de mises en production (satisfaction client) et de facturation (bénéfices pour l’entreprise) puis de faire un bilan sur comment le groupe a vécu cette expérience d’agilité.

Le Jeu de la Business Value © a été créé par Vera Peeters et Pascal Van Cauwenberghe et vous pouvez le télécharger sur http://www.xp.be.

MPM Calendrier formations