Saviez-vous que 3 des termes de PRINCE2 sont agiles ?

En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet.

http://www.alctraining.com.au/4-prince2-terms-you-may-not-know-are-agile/ par ALC Group

Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.

3 termes Agile Prince2En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Premier terme Agile – Initiation

A few videos to get started on Agile, Scrum and Kanban
A few videos to get started on Agile, Scrum and Kanban

Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.

Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.

De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.

Second terme Agile – Work package (Lot de travail)

Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des  frontières comprises et communicables.

Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.

Troisième terme Agile – Tolérance

prioriser2Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.

Produit Viable Minimum (MVP)
Produit Viable Minimum (MVP)

La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.

Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.

Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Scrum… Vraiment

agile-on-the-beachScrum… Really

http://www.scrumexpert.com/videos/scrum-really par Amy Thompson à Agile on the Beach 2015

Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.

Amy Thompson
Amy Thompson

Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?

J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.

L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)

A few videos to get started on #Agile, #Scrum & #Kanban

Microsoft est Partenaire de DantotsuPM
Microsoft est Partenaire de DantotsuPM

Réussir des « standup » efficaces autour du tableau Kanban (repost)

Effective Standups around Kanban Board

http://blog.brodzinski.com/2011/12/effective-standups.html par Pawel Brodzinski

stand-up meetingsVous pouvez entendre ici et là que Kanban s’adapte plutôt bien aux grandes tailles. En réalité, un des problèmes de Scrum auquel je pense on ne s’est pas soigneusement attaqué, est que faire dans les projets qui nécessitent davantage de personnes qu’une unique équipe Scrum puisse rassembler. L’un des problèmes qui émerge très rapidement quand l’équipe Scrum grandit est la réunion « standup ».

Comme vous passez à travers l’équipe qui grossit avec vos trois questions standards cela nécessite naturellement de plus en plus de temps. Bientôt cela peut devenir un problème que de tenir dans le bref temps imparti pour de telles réunions.

Quand l’équipe adopte Kanban, elle commence d’habitude avec un standup inchangé. Cependant cela signifie que, à un certain point, ils font face au même problème que les équipes Scrum :  15 minutes ne sont désormais plus suffisantes.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Récemment, Jorn Hunskaar a partagé une telle histoire sur son blog. Il m’a incité à combiner une suite d’idées en une seule réponse qui peut servir de un guide sur comment améliorer les standups autour du tableau Kanban.

Au lieu d’exécuter le typique tour de table avec des réponses sur ce qui s’est produit hier, ce qui va être réalisé aujourd’hui et quels sont les problèmes, vous pouvez essayer de reconcevoir le modèle que vous suivez pour le standup.

comment améliorer les standups autour du tableau Kanban

  • kanban boardD’abord, passez à travers tous les points bloquants (s’il y en a). Ceux-ci sont certainement vos points de douleur actuels. Cela signifie que vous voulez certainement investir une partie du précieux temps de standup sur ces points bloquants. Cela est évident.
  • Deuxièmement, discutez des items urgents ou à expédier (de nouveau, s’il y en a). C’est le travail prioritaire du point de vue de l’équipe toute entière. C’est quelque chose que vous devez vraiment faire sous peine de retarder d’autres taches. De nouveau, ceci est une chose dans laquelle cela vaut la peine d’investir de rares ressources.
  • Troisièmement, passez en revue les items qui n’ont pas progressé depuis le dernier standup. Ceux-ci sont les points qui peuvent être à risque. Peut-être ne devaient-ils pas progresser mais dans ce cas ce serait revu rapidement, peu de discussion nécessaire. Autrement, cela vaut la peine d’avoir une brève analyse ce qui a empêché ces points d’avancer. À propos, cela signifie que vous devriez avoir un mécanisme pour marquer visuellement les fiches qui ne se déplacent pas, ce qui est souvent délicat.
  • Quatrièmement, passez à travers tout le reste. Encore un conseil : Vous pouvez avoir discuté les sujets selon  leur classe de service par priorités. Autrement dit, vous commencez par la classe la plus hautement prioritaire de service (des bogues, des fonctionnalités critiques ou autre) et discutez tous les items de cette classe de service. Puis vous vous déplacez sur une autre. Bien, au moins cela peut fonctionner tant est que vous puissiez dire quelle classe de service est plus importante qu’une autre.

Encore une règle raisonnable : dans chacun de ces groupes, utilisez le tableau Kanban de la droite vers la gauche. Cela indique que plus un article est proche d’être fini plus vous voulez en discuter pour le compléter, apportant ainsi de la valeur à vos utilisateurs, clients et parties prenantes.

OK, jusqu’à ce point il y a en fait peu de différences : vous passez toujours en revue chaque item de travail qui est sur le tableau. Il y a un focus différent sur les problèmes et vous pouvez passer sur les items évidents de travail complété, mais tout de même, toujours beaucoup de contenu à revoir.

deadlineCependant, étant donné que vous venez de trier les sujets à discuter selon leur priorité, vous pouvez utiliser un truc simple et stopper la discussion quand le temps de la réunion s’est écoulé, peu importe si vous avez pu ou pas couvrir toutes les choses. Cela signifie que vous avez probablement couvert tous les items des trois premiers groupes et certainement tous ceux des deux premiers, indépendamment du reste qui exige une moindre part de discussion ou aucune discussion du tout.

Cela signifie aussi que, dans un bon jour, vous pouvez couvrir tous les points, ou davantage de choses, et c’est parfait. Ce dont vous avez essentiellement besoin est de vous assurer que la substance la plus importante ne va pas passer inaperçue.

Un pas de plus serait de sauter une discussion sur un groupe ou sous-groupe spécifique  d’items, comme par exemple une classe spécifique de service, quand vous voyez que cela n’ajoute pas vraiment de valeur. Si vous n’êtes pas certain,  essayez de les couvrir pendant les standups et voyez quel résultat vous obtenez.  Vous pourrez alors commencer à essayer d’autres choses avec l’agenda de la réunion.

Idéalement, après quelque temps, vous finirez par discuter seulement des choses importantes, disons, les points bloquants, les items à expédier et bloqués, et peut-être d’autres qui sont amenés par n’importe quel membre de l’équipe pour une raison importante et sortent du travail habituel qui n’a pas besoin de plus d’attention qu’une confirmation silencieuse que tout est parfaitement en ordre.

les Apps en support du Management de Projet !

Cette semaine, Campana & Schott a profité de la MS Project Conférence pour présenter 4 nouvelles applications par Vincent Capitaine

Partenaire de DantotsuPM
Partenaire de DantotsuPM

La Project Conférence 2014 à Anaheim fut un brillant succès et notre partenaire Campana & Schott a profité de cette conférence pour présenter quatre nouvelle applications disponibles sur l’Office Store de Microsoft pour Project Online et SharePoint Online.

« What Apps can do to support Project Management?« 

Ces applications sont disponibles pour Project Server 2013 et SharePoint Server 2013 et des versions d’essai gratuites peuvent être téléchargées en ligne.

cs-task-boardCS Task Board

Ajouter une liste et un tableau KANBAN aux sites SharePoint Online ou Project Online. Elle permet de visualiser les tâches sous la forme de Post-IT® et de les actualiser par glisser-déposer. Les tâches peuvent être gérées, recherchées et filtrées efficacement avec des mots-clés.

cs-milestone-trend-analysisCS Milestone Trend Analysis

Historisation des données de Microsoft Project Online ou Microsoft Project Server 2013. L’application permet la création d’une « courbe à 45° », de contrôler les jalons d’un projet au fil du temps, d’analyser les tendances, d’identifier les dérives et donc, de mieux réagir !

cs-risk-matrixCS Risk Matrix

Ajouter une liste aux sites SharePoint Online ou Project Online permettant de gérer efficacement les risques. Ceux-ci s’affichent également dans une matrice à trois couleurs et peuvent être mis à jour par un simple glisser-déposer. Les risques peuvent être gérés et filtrés aisément via la définition de mots-clés.

cs-multi-project-editorCS Multi Project Editor

Cette application satisfera tous les utilisateurs et administrateurs de Project Server 2013 et Project Online désireux de gérer en masse les métadonnées des projets !

Pour en savoir davantage, visitez le site Campana & Schott.

Campana & Schott
Partenaire de DantotsuPM

pensons Produit Minimum Viable (MVP)

MVP Thinking

http://brodzinski.com/2013/06/mvp-thinking.html par Pawel Brodzinski

the lean startupUn des buts atteints par Eric Ries’ Lean Startup’ et porteur du plus de valeur est de populariser le terme de « Minimal Viable Product » (MVP), ou Produit Minimum Viable en français. Bien sûr le concept n’est pas nouveau. Nous utilisions l’idée de « Minimal Marketable Feature » (MMF) depuis les tous premiers jours de Kanban et elle était basée sur la même façon de penser. Il y a aussi davantage de concepts similaires.

La prémisse de base est que nous devrions construire la chose la plus petite possible ou faire fonctionner l’expérimentation la plus petite possible qui reste raisonnable et ajoute de la valeur. Selon le contexte la valeur peut être quelque chose qui aide des utilisateurs, mais peut aussi être simplement la découverte de nouvelles connaissances ou la vérification d’une hypothèse.

Une chose que j’ai réalisée récemment est à quel point j’applique largement cette pensée. Initialement, c’était simplement la façon de décomposer le contenu. J’ai voulu que mes équipes construisent des morceaux de logiciel probablement petits, mais toujours de valeur, et qu’un client puisse donc vérifier et nous donner un retour avec des informations utiles. Alors, après Lean Startup, il s’agissait de faire fonctionner un produit. Ce que nous voulons construire est quelque chose de nouveau qui frappe les esprits. Quelle est la fonctionnalité la plus petite qui peut prouver ou réfuter l’hypothèse que cela puisse fonctionner ?

D’une façon ou d’une autre j’utilise maintenant la même façon de penser, la pensée MVP si vous voulez, pour discuter des idées de marketing, définir des plans d’action pendant des rétrospectives, etc. Souvent il est difficile de définir un produit en soi, mais il y a toujours une idée des résultats attendus et un effort minimal définissable permettant d’obtenir ce résultat.

Ainsi comment définirais-je la pensée MVP ?

quelle est la cible à atteindre?1. Définir le plus petit prochain objectif de valeur que vous voulez réaliser.
2. Définir l’effort minimal qui vous permettra d’atteindre ce but.
3. Exécuter.
4. Analyser les résultats et apprendre.
5. Itérer.

Une partie potentiellement délicate est la définition de l’objectif parce que c’est totalement contextuel. C’est aussi quelque chose qui me plaît vraiment car je n’aime pas les recettes toutes prêtes. En fait, s’il y a quoi que ce soit de nouveau ici, c’est essentiellement l’application extrêmement large du modèle car l’idée elle-même n’est pas nouvelle. Je veux dire, nous limitons d’habitude notre contexte de travail au périmètre d’un projet, au management d’un produit, à faire tourner une affaire, etc. Alors, nous inventons un nouveau terme et s’il marche nous en faisons nos carrières de consultants excessivement bien payés.

Ce n’est pas du tout mon but. J’essaye juste d’élargir un contexte applicable d’idées que nous connaissons déjà et que j’ai personnellement trouvées utiles.

résolution de problème

Donc si mon problème est une fuite sous le toit près d’une lucarne, mon objectif minimal suivant peut être de vérifier si la fuite a un rapport avec un volet externe. Un tel objectif est acceptable parce que l’effort minimal peut être simplement d’attendre l’averse suivante avec le volet ouvert ou fermé. Je ne me précipite certainement pas pour réparer le toit.

marketing

shoutSi nous parlons de marketing ? Donnons un objectif général, disons: TechCrunch parlera de nous. Quelle serait l’expérimentation de valeur la plus petite qui pourrait nous rapprocher de la réalisation de cette sorte d’objectif ? Je suppose qu’étendre et manager son réseau peut être une première étape très raisonnable. Cela n’exige même pas d’avoir une idée, sans parler d’un produit, que nous voudrions voir couvert.

développement de produit

Que diriez-vous d’un produit ? Eh bien, celui-ci a été couvert pratiquement partout. Construire la fonction minimale, probablement même une simulation, qui permet de vérifier que l’idée pour le produit a du sens.

leçons apprises

Rétrospectives ? Quel est le simple, plus petit possible, changement qui aura un impact positif sur l’équipe ? Essayez-le. Vérifiez-le. Répétez.

achats

Zut, j’achète même mon équipement de marin de cette façon. Quel est le plus petit jeu d’équipements possible qui donne une chance de survie raisonnable ? Puis, j’utilise le résultat et je réitère, par exemple la prochaine fois j’aurai besoin de nouveaux gants, de caleçons longs  et de protection imperméable pour un téléphone.

kaizenQuand vous y pensez c’est essentiellement du Kaizen – faire systématiquement de petites expériences d’amélioration partout. Alors oui, il n’y a rien de nouveau. C’est seulement l’idée spécifique de Produit Viable Minimal qui me parle personnellement et m’a donné une contrainte agréable qui peut être utilisée dans les différents domaines de ma vie.

À propos, malgré sa définition très ouverte je trouve aussi que Kaizen est d’habitude appliqué dans un contexte très limité. Aussi, peu importe quelle idée marche pour vous, souvenez-vous juste que vous pouvez l’utiliser dans un contexte beaucoup plus large.

Réussir des « standup » efficaces autour du tableau Kanban

Effective Standups around Kanban Board

http://blog.brodzinski.com/2011/12/effective-standups.html par Pawel Brodzinski

stand-up meetingsVous pouvez entendre ici et là que Kanban s’adapte plutôt bien aux grandes tailles. En réalité, un des problèmes de Scrum auquel je pense on ne s’est pas soigneusement attaqué, est que faire dans les projets qui nécessitent davantage de personnes qu’une unique équipe Scrum puisse rassembler. L’un des problèmes qui émerge très rapidement quand l’équipe Scrum grandit est la réunion « standup ».

Comme vous passez à travers l’équipe qui grossit avec vos trois questions standards cela nécessite naturellement de plus en plus de temps. Bientôt cela peut devenir un problème que de tenir dans le bref temps imparti pour de telles réunions.

Quand l’équipe adopte Kanban, elle commence d’habitude avec un standup inchangé. Cependant cela signifie que, à un certain point, ils font face au même problème que les équipes Scrum :  15 minutes ne sont désormais plus suffisantes.

Récemment, Jorn Hunskaar a partagé une telle histoire sur son blog. Il m’a incité à combiner une suite d’idées en une seule réponse qui peut servir de un guide sur comment améliorer les standups autour du tableau Kanban.

Au lieu d’exécuter le typique tour de table avec des réponses sur ce qui s’est produit hier, ce qui va être réalisé aujourd’hui et quels sont les problèmes, vous pouvez essayer de reconcevoir le modèle que vous suivez pour le standup.

comment améliorer les standups autour du tableau Kanban

  • kanban boardD’abord, passez à travers tous les points bloquants (s’il y en a). Ceux-ci sont certainement vos points de douleur actuels. Cela signifie que vous voulez certainement investir une partie du précieux temps de standup sur ces points bloquants. Cela est évident.
  • Deuxièmement, discutez des items urgents ou à expédier (de nouveau, s’il y en a). C’est le travail prioritaire du point de vue de l’équipe toute entière. C’est quelque chose que vous devez vraiment faire sous peine de retarder d’autres taches. De nouveau, ceci est une chose dans laquelle cela vaut la peine d’investir de rares ressources.
  • Troisièmement, passez en revue les items qui n’ont pas progressé depuis le dernier standup. Ceux-ci sont les points qui peuvent être à risque. Peut-être ne devaient-ils pas progresser mais dans ce cas ce serait revu rapidement, peu de discussion nécessaire. Autrement, cela vaut la peine d’avoir une brève analyse ce qui a empêché ces points d’avancer. À propos, cela signifie que vous devriez avoir un mécanisme pour marquer visuellement les fiches qui ne se déplacent pas, ce qui est souvent délicat.
  • Quatrièmement, passez à travers tout le reste. Encore un conseil : Vous pouvez avoir discuté les sujets selon  leur classe de service par priorités. Autrement dit, vous commencez par la classe la plus hautement prioritaire de service (des bogues, des fonctionnalités critiques ou autre) et discutez tous les items de cette classe de service. Puis vous vous déplacez sur une autre. Bien, au moins cela peut fonctionner tant est que vous puissiez dire quelle classe de service est plus importante qu’une autre.

Encore une règle raisonnable : dans chacun de ces groupes, utilisez le tableau Kanban de la droite vers la gauche. Cela indique que plus un article est proche d’être fini plus vous voulez en discuter pour le compléter, apportant ainsi de la valeur à vos utilisateurs, clients et parties prenantes.

OK, jusqu’à ce point il y a en fait peu de différences : vous passez toujours en revue chaque item de travail qui est sur le tableau. Il y a un focus différent sur les problèmes et vous pouvez passer sur les items évidents de travail complété, mais tout de même, toujours beaucoup de contenu à revoir.

deadlineCependant, étant donné que vous venez de trier les sujets à discuter selon leur priorité, vous pouvez utiliser un truc simple et stopper la discussion quand le temps de la réunion s’est écoulé, peu importe si vous avez pu ou pas couvrir toutes les choses. Cela signifie que vous avez probablement couvert tous les items des trois premiers groupes et certainement tous ceux des deux premiers, indépendamment du reste qui exige une moindre part de discussion ou aucune discussion du tout.

Cela signifie aussi que, dans un bon jour, vous pouvez couvrir tous les points, ou davantage de choses, et c’est parfait. Ce dont vous avez essentiellement besoin est de vous assurer que la substance la plus importante ne va pas passer inaperçue.

Un pas de plus serait de sauter une discussion sur un groupe ou sous-groupe spécifique  d’items, comme par exemple une classe spécifique de service, quand vous voyez que cela n’ajoute pas vraiment de valeur. Si vous n’êtes pas certain,  essayez de les couvrir pendant les standups et voyez quel résultat vous obtenez.  Vous pourrez alors commencer à essayer d’autres choses avec l’agenda de la réunion.

Idéalement, après quelque temps, vous finirez par discuter seulement des choses importantes, disons, les points bloquants, les items à expédier et bloqués, et peut-être d’autres qui sont amenés par n’importe quel membre de l’équipe pour une raison importante et sortent du travail habituel qui n’a pas besoin de plus d’attention qu’une confirmation silencieuse que tout est parfaitement en ordre.