Archive | agile Flux RSS pour cette section

April 24 – Webinar (PMI) – in Agile, it’s the Goal, Not the Role

14 avr

The Work of Agile Project Management, Product Management, and Business Analysis

The goal of Agile teams is to continuously deliver high-value outcomes—as quickly as possible. To achieve this, these teams focus on skills, not titles or traditional role delineations.

So what does that mean for the experienced project manager, product manager, or business analyst?

Where do their planning and analysis skills fit into Agile’s fierce focus on frequent delivery?

Drawing on her insights from coaching Agile teams, Mary Gorman addresses these questions and outlines the dynamic relationships between agile work, disciplines, and skills.

Mary Gorman

Mary Gorman

Discover how re-positioning from role-based to skill-based work enables you to collaboratively contribute to any agile effort.

Mary Gorman, a recognized leader in business analysis and requirements, is Vice President of Quality and Delivery at EBG Consulting. Mary participated in shaping PMI’s Professional in Business Analysis certification.

24 April 2014 6:00 PM to 7:00 PM CET/France

Register for webinar

Management de Portefeuille de Projets et Agile : Réunir les Deux Mondes pour le Meilleur – par Vincent Coustillac

14 avr
Vincent Coustillac

Vincent Coustillac

Cet article est proposé par Vincent Coustillac, consultant Net’sFive – réseau d’experts en Management de Projets.

A propos du défi causé par l’intégration d’une méthode Agile dans le cadre du Management de Portefeuille de Projet (PPM), et de comment donner la visibilité nécessaire à la Direction d’entreprise sans perturber la culture et les pratiques des équipes Agile.

Cet article présente un ‘White Paper’ publié par Daptiv, – société américaine spécialisée dans les systèmes de management de portefeuille de projets (http://www.daptiv.com) qui peut être téléchargé dans son intégralité (en version originale anglaise) depuis ce lien.

SMPP

Partenaire de DantotsuPM

Ce ‘White Paper’ a particulièrement attiré notre attention car il montre comment, malgré les idées fausses associées aux méthodes Agile, les projets exécutés dans ce mode peuvent très bien être intégrés dans un management de portefeuille de projets. Cela bien-sûr en tenant compte des caractéristiques propres à la culture et aux pratiques des équipes Agile, et des exigences générées par leur intégration dans un portefeuille de projets.

Le ‘White Paper’ commence par une introduction du modèle Agile et ce qui le distingue du modèle de gestion de projet traditionnel, pour ensuite aborder le cœur du sujet.

Le défi : Intégrer les processus PPM et Agile

De nombreux portefeuilles de projets comprennent maintenant un mélange de types et de méthodologies projet, tels que les projets traditionnels en cascade, des projets en mode Agile, des projets Six Sigma et des projets «Stage-Gate» au cycle de vie déterminé pour le développement de nouveaux produits.

Cependant, même avec cette volonté d’adopter une méthode Agile, l’intégration de projets Agile dans un cadre PPM s’est avérée difficile pour de nombreuses organisations.

Les 3 Idées  Fausses sur l’association PPM et Agile

Le mouvement Agile a eu une influence significative sur les bonnes pratiques en gestion de projet. Cependant, quelques principes Agile tels que l’acceptation du changement, la planification "juste-à-temps", et la suppression de la prise de décision hiérarchique ont conduit à des idées fausses sur la compatibilité des projets en mode Agile avec les processus PPM.

Voici trois idées fausses communes (et pourquoi elles sont fausses) sur les principes Agile qui ont compromis l’intégration des projets Agile dans un portefeuille de projets.

Idée Fausse #1 : Les Projets Agile ne Donnent pas une Visibilité Suffisante à la Direction

Une grande partie de la popularité de la méthode Agile réside dans la croyance que les équipes doivent être habilitées à prendre des décisions business plutôt que de compter sur les parties prenantes dirigeantes pour approbation. Responsabiliser une équipe, cependant, ne signifie pas que des rapports d’avancement ne doivent pas être fournis en temps opportun à l’équipe dirigeante. La difficulté à laquelle les équipes sont confrontées est la nécessité de fournir des rapports d’avancement dont les dirigeants ont besoin, mais qui sont peu compatibles avec les pratiques Agile. Les dirigeants doivent apprendre à interpréter le statut de projet d’une équipe Agile plutôt que d’imposer des exigences de rapports d’avancement qui ne sont pas compatibles avec les pratiques Agile.

Idée Fausse #2 : Les Projets Agile n’ont pas de «Dates de Fin Prévues» Fiables

Bien que les équipes Agile évitent de fournir des dates de livraison garanties (étant donné le cône d’incertitude autour d’un projet), c’est une erreur de penser qu’un projet Agile ne puisse pas donner une date de fin prévue. Il est vrai que les équipes Agile fournissent des estimations «juste-à-temps» pour chacune des itérations et se concentrent sur la fourniture progressive de la valeur commerciale, cependant  un plan de réalisation et de livraison global doit pouvoir faire l’objet d’une estimation de haut niveau. L’utilisation d’«epics» (grandes «stories ») et «themes» (groupes de «stories») permet d’estimer le travail dont il convient de détailler le contenu.

Idée Fausse #3 : Les Pratiques Agile et Traditionnelles ne sont pas Compatibles

Certaines pratiques Agile ont des différences fondamentales avec des pratiques traditionnelles de gestion de projet. Cependant, il n’est pas vrai que les deux types de pratiques ne peuvent pas être combinés pour créer un cadre de gestion de projet efficace. Par exemple, les pratiques Agile ne couvrent généralement pas la consommation du projet ou le processus d’initiation du projet, et les pratiques traditionnelles concernant les coûts du projet, la communication et la gestion des risques sont souvent plus matures que les pratiques Agile correspondantes.

Intégration d’une méthodologie Agile dans un cadre PPM

Daptiv PPM 1L’intégration d’une méthodologie de projet Agile dans un cadre PPM n’est pas différente de l’intégration d’une méthodologie de projet plus traditionnel, à quatre exceptions près:

1. Les équipes Agile fonctionnent manifestement mieux lorsque les dirigeants et les chefs de projet n’étouffent pas les processus Agile. Imposer des revues inutiles des parties prenantes, des points de contrôle et des exigences de saisie de données sur un projet Agile réduira considérablement l’efficacité de l’équipe. Bien sûr, si des décisions importantes doivent être prises avec la participation de la Direction ou si un projet Agile a des dépendances avec d’autres projets, des réunions avec les parties prenantes seront nécessaires, mais celles-ci doivent être l’exception et non la règle.

2. Les projets Agile mesurent la progression des «story points» terminés et la valeur commerciale livrée. C’est un moyen fondamentalement différent de suivre les progrès réalisés plutôt que d’utiliser un plan des tâches et la mesure des heures consommées sur les tâches accomplies. En outre, le chef de projet assigne des responsables de tâches dans un projet traditionnel, tandis que les équipes Agile s’auto-organisent, de sorte que les tâches sont réaffectées à tout moment par l’équipe pour assurer une livraison optimale du projet. Cette différence exige que les mesures de "la santé de projet" et du "pourcentage d’avancement" soient établies différemment des projets traditionnellement basés sur les temps passés par tâche.

3. Du fait que les affectations de tâches au sein d’une équipe Agile sont dynamiques, il n’est pas recommandé d’attribuer des ressources à temps partiel dans une équipe Agile, car cela brise le modèle d’auto-organisation. Au lieu de cela, il est préférable de traiter les équipes Agile comme un tout et affecter des ressources à plein temps (à l’exception des ressources telles que les architectes, les administrateurs de bases de données, qui sont généralement réparties sur plusieurs projets).

4. Enfin, les revues régulières des projets Agile sont plus orientées sur «l’état du produit» plutôt que sur l’atteinte de jalons prédéterminés ou la livraison de la documentation du projet. Les revues doivent être adaptées au type de projet afin de s’assurer qu’elles apportent une valeur pour l’équipe.

Des mesures communes aux différents types de projets

Afin de les intégrer dans un cadre PPM, les cinq paramètres communs qui permettront aux dirigeants d’obtenir une visibilité de l’état des projets, quel que soit le mode d’exécution, sont les suivants :

  • La date de fin prévue : "La date de fin planifiée" est l’estimation faite lors de la création du projet pour la date de livraison prévue, alors que "la date de fin prévue" est l’estimation de la date de fin du projet réactualisée en fonction des données actuelles. Pour un projet traditionnel, ces dates sont basées sur le planning des tâches et le chemin critique du projet. Pour un projet Agile, elles sont basées sur le plan de livraison. Étant donné qu’un «cône d’incertitude» existe indépendamment de la méthodologie de projet, l’exactitude des dates de fin prévues devrait être comparable pour les deux types de projets traditionnels et Agile.
  • Le pourcentage d’avancement : Pour un projet traditionnel il est calculé en additionnant les heures des tâches accomplies et en divisant par le nombre d’heures total des tâches du projet. En revanche, le progrès d’un projet Agile est mesuré par les «story points» livrés, le pourcentage d’avancement est alors mesuré par rapport au nombre total de «story points» prévu du projet.
  • Les modifications du contenu : Pour les projets traditionnels, cela est représenté par le nombre de demandes de changement. Pour un projet Agile, cela est mesuré par la variation en «story points» totaux au fil du temps.
  • Coûts réels et budgétés : Ces mesures doivent être rapportées pour les deux types de projets traditionnels et Agile. Alors que sur les projets traditionnels ces mesures peuvent se faire sur la base des tâches et des temps passés, il n’est pas approprié de demander à une équipe Agile de suivre les temps au niveau des tâches pour calculer les coûts des ressources. Au lieu de cela, les ressources doivent être dédiées à une équipe Agile et les coûts calculés en conséquence.
  • Le statut du projet : Le statut du projet est une mesure qui résume si un projet est «sur la bonne voie", "a besoin d’attention" ou est "en difficulté". Son évaluation varie selon l’organisation et est calculée en utilisant la logique conditionnelle basée sur les quatre mesures ci-dessus, ainsi que d’autres données telles que les questions en suspens.

La fourniture de ces mesures dans un tableau de bord d’un système PPM permet aux dirigeants d’identifier rapidement les projets qui nécessitent une attention particulière ou une intervention, quelle que soit la méthodologie utilisée pour son exécution.

Le ‘White Paper’ se termine par deux points essentiels

La calibration des mesures des différents types de projets dans les programmes et les portefeuilles, ainsi que la nécessité de créer une source unique de référencesingle source of truth – pour la Direction.

-=-=-=-=-=-

NetsFive LogoNet’sFive accompagne les entreprises pour favoriser leur développement par la maîtrise des projets à tous les niveaux de l’entreprise : depuis la conduite des projets individuellement, le contrôle global des projets de l’entreprise, l’optimisation des ressources et jusqu’au management du portefeuille des projets pour une gestion priorisée des projets alignés avec la stratégie de l’entreprise.

April 23 – Webinar – A Modern Take on the Agile Manifesto for Today’s Business Analysts

2 avr

"How to truly adapt agile principles in today’s product-centric, customer-focused enterprise"

modern analystThe Agile Manifesto has been great for engineers, but has presented real challenges for business analysts and other stakeholders involved in the process of “define, build, test” for application development.

The problems addressed by the agile manifesto in 2001 still exist today, magnified by the changing landscape of product delivery:

  • Time to market has dramatically shortened and complexity has increased
  • Information is available and abundant but continues go undocumented and is lost
  • Communications gaps widen due to geographically dispersed teams and department differences
  • Customer needs require iterative communication yet continue go unmet
Check this past article and Video

Check this past article and Video

And yet, our interpretation of the manifesto hasn’t changed in over a decade, despite the major changes to how we work and the environment around us.

So what does today’s agile look like? Do the values of the manifesto still apply? When did Agile become more about process and less about the mindset? How can we merge the intention of the manifesto with the new way we work? How can we evolve agile concepts to tackle the challenges of today in a new way?

Register and join this webinar at 7PM CET/France for an opportunity to rethink yesterday’s manifesto in a new light and deconstruct which concepts were winners and which still need to evolve. We’ll cover the four key tenants of Agile and how to approach them based on new technologies and mindsets around collaboration, social integration and complex systems engineering to find balance for everyone involved and improve your enterprise agility.

** Eligible for PDUs, CDUs. **

9 Avril – Genève – Les Business Analysts face à l’agilité : de nouveaux challenges à relever

31 mar

Petit-déjeuner Octo gratuit mercredi 9 avril

octo_talksLe business analyst (BA) joue un rôle crucial dans nos organisations.

Lien essentiel entre les opérationnels et l’informatique, il identifie, analyse, valide et documente les besoins métiers et participe à la mise en place de solutions.

Dans un projet traditionnel (en cascade), son activité gravite naturellement autour de la rédaction des spécifications fonctionnelles, réalisées typiquement en amont des développements.

Dans un contexte plus agile par contre, dans lequel les besoins peuvent être raffinés,(re-)priorisés, réévalués, redéfinis continuellement et dans lequel la notion même de spécification telle qu’on la connaît est remise en cause, comment continuer à valoriser les compétences du BA ?

En abordant ces questions, c’est également le rôle des spécifications, de leur place au sein d’un projet agile et de leur lien étroit avec les tests que l’on clarifiera dans ce petit-déjeuner.

Small business - petite entrepriseOn abordera en particulier :

  • ses nouvelles relations avec le Product Owner, l’équipe QA, l’équipe de développement agile et le reste de l’organisation;
  • son implication dans l’écriture de spécifications sous la forme d’exemples et de tests d’acceptance (ATDD);
  • quelques nouveaux outils pour aider le BA à définir le produit de manière plus itérative et incrémentale;

Ces principes seront illustrés sur la base d’un cas et d’outils concrets. Avec l’avènement de l’agilité, le Business Analyst doit se renouveler. Venez découvrir les pistes qui lui permettront de travailler de manière plus agile.

1 Avril – Paris – vers l’entreprise Agile

28 mar

Petit-déjeuner Octo du mardi 1 avril 2014, Paris VIIIème à 9:00

octo AgileUne fois passées les premières expérimentations sur les méthodes agiles, une question s’impose de façon récurrente : comment changer d’échelle et devenir une entreprise Agile ?

Bien sûr, il ne s’agit pas de savoir lancer un énième projet en Scrum mais plutôt de répondre aux questions suivantes :

  • Qu’est ce qu’une entreprise Agile ?
  • L’entreprise Agile chez moi, est-ce que cela fait sens ? Jusqu’où dois-je ou puis-je aller ?
  • Comment assurer un pilotage de mon portefeuille projets et de mes budgets ?
  • Comment engager cette transformation? Quels sont les écueils à éviter ?

En répondant à ces questions, OCTO vous propose un chemin.

Les intervenants ne parleront pas directement de Scrum, Software Craftsmanship, Lean Startup, ou autre Devops, mais bien de la manière de créer une alchimie réunissant ces ingrédients au travers de la gouvernance, de l’organisation, des pratiques de management et de la culture d’entreprise.

Au delà du partage des bonnes pratiques et des Frameworks d’entreprise, ce petit déjeuner sera l’occasion confronter les retours d’expérience chez nos clients dans différents domaines (banque, eCommerce, télécoms, pure players du web).

La deuxième partie de ce petit déjeuner réunira  des acteurs de la transformation agile chez Société Générale et Viadeo autour d’une table ronde.

Avec ce petit déjeuner, Octo a l’ambition de vous fournir une base de réflexion et d’action pour transformer votre organisation en entreprise apprenante.

Inscriptions

Ce séminaire s’adresse à tous ceux qui ont envie d’aller plus loin sur l’agilité : marketing, chefs de produits, architectes, geeks, managers ou responsables DSI.

31 March – Webinar (PMI) – Get it Done! Applying Agile Methods to Life or Business

19 mar

PMI’s Agile Community of Practice webinar with Jesse Fewell

31 March 2014 • 12-1 PM EDT (18:00 CET/France)

For years now, agile methods have become the standard for software projects, helping companies deliver more product, faster, with higher quality.

Construction Worker TripletsBut what about the rest of us?

ACPWhat if I work in public utilities?

What if I work in manufacturing, or the automotive field, or marketing campaigns?

This cutting-edge webinar will reveal several case studies of unconventional uses of agile methods, along with some overarching principles and patterns to help you apply them to your own work, whether it be book publishing or personal fitness.

20 Mars – Caen – Seconde édition du Printemps Agile

10 mar

Le Club Agile Caen organise le jeudi 20 mars 2014 à partir de 8h30 au Campus 2 de l’Université la seconde édition du Printemps Agile.

Au programme cette année, trois cycles d’ateliers et de conférences pour tous les publics :

  1. sessions découverte pour les novices,
  2. sessions management agile pour les responsables d’équipes, dirigeants d’entreprises ou de services, et
  3. sessions développement agile pour les développeurs informatiques et chefs de projets.

club Agile CaenPlanning second printemps agile

pmifr Logo AtlantiqueCet événement est sponsorisé par la branche France Atlantique du PMI France.

L’événement est gratuit !

Pour en savoir plus et s’inscrire : http://www.club-agile-caen.fr/content/printemps-agile-2014.

22-23 Mai – Paris – Agile France 2014

7 mar

Agile France aura lieu les jeudi 22 et vendredi 23 mai 2014 au Chalet de la Porte Jaune

agile france 2014Objectif : permettre aux praticiens avancés de se réunir et d’échanger pour apprendre en dehors des sentiers battus.

A ce stade, vous avez 2 options :

  1. Vous êtes fan, sûr(e) de venir ? Prenez dès maintenant votre billet à prix ultra promotionnel
  2. Vous avez envie de monter sur scène ? Pour déposer un sujet, c’est trop tard ! L’appel à orateurs est fermé. Que cela ne vous empêche pas de prendre votre billet tout de suite : vous pourrez proposer votre sujet lors de l’open-space du jeudi après-midi.

Inscriptions

la certification PMI-ACP® (Agile) importe-t-elle ?

7 mar

Does PMI-ACP® (Agile) Certification Matter?

http://www.pmhut.com/does-pmi-acp-agile-certification-matter par Bruno Collet

J’ai fait du management de projet agile pendant des années puis ai passé PMI-ACP® (Agile Certified Pratitioner) l’année dernière. Plusieurs personnes m’ont demandé ce que j’ai pensé de PMI-ACP®, donc j’ai pensé que c’est le moment de partager mes impressions d’une façon plutôt informelle.

La certification PMI-ACP® signifie quelque chose parce que :

  1. ACPElle se concentre sur le management de projet, pas seulement le management d’équipe, c’est-à-dire qu’elle inclut la gestion des risques, le management des communications, etc.
  2. Elle n’est pas limitée au développement logiciel.
  3. Elle n’est pas facile à obtenir, contrairement à quelques certifications célèbres qui sont devenues tout à fait creuses – PMI-ACP® est un différenciateur.
  4. Elle complète PMP® dans le sens où PMBoK® Décrit *CE QUE* le PM devrait savoir et PMI-ACP® décrit *COMMENT* le faire de façon agile.
  5. C’est un assez bon tour d’horizon de l’état de l’art en la matière, car elle ne se limite pas à une unique approche agile.
  6. Elle va au-delà de l’abstraction fatigante de "mentalité agile"  en exigeant de comprendre les pratiques exploitables.
  7. Elle reconnaît le fait que le management de projet réussi est plus fait de compétences douces (« soft skills ») que de techniques de management de projet (comme le confirmera tout chef de projet expérimenté).
PMGS est partenaire de DantotsuPM depuis sa création

PMGS est partenaire de DantotsuPM depuis sa création

Côté inconvénients

J’estime qu’il n’est pas facile de se préparer parce que contrairement au PMBoK®, il n’y a aucun "AgilePMBoK" référencé.

PMI-ACP® se réfère à une liste de livres et exige souvent de répondre à des questions sur lesquelles il n’y a aucun consensus quant à la réponse correcte. Certains diraient que "la certification agile" est un paradoxe parce que l’approche agile décourage la standardisation. (Bien que j’ai eu la chance plus d’une fois de mettre en place des standards agiles dans des organisations – le truc est de trouver le niveau approprié de détail et de s’adapter au contexte – mais ceci est un autre sujet).

J’espère voir plus de chefs de projets bien informé sur Agile!

11 Mars – Lausanne – Mon projet est-il éligible pour une approche AGILE ?

5 mar

Avec la Société Suisse de Management de Projet, la SMP, le 11 mars 2014 de 18h30 à 20h00 à Lausanne, Hôtel Alpha-Palmiers

Laurent Gaille

Laurent Gaille

Mon projet est-il éligible pour une approche AGILE ? par Laurent Gaille

Force est de constater que tous les projets informatiques ne sont pas des succès. L’optimisation des budgets et la compression des délais mettent à mal le célèbre cycle en V et imposent une gestion plus souple et plus réactive pour cibler juste et livrer vite.

LogoSMPSi les approches AGILE bousculent les modèles traditionnels en proposant des itérations plus courtes et un mode de travail plus collaboratif, une fois l’enthousiasme émoussé la tentation est grande de revenir en arrière sans avoir pu comprendre les raisons des problèmes rencontrés. L’Agilité permet de faire face à bien des défis mais n’est pas infaillible. Il convient de savoir quand, et avec quel projet, tenter l’expérience pour maximiser les chances de réussite. L’organisation de l’entreprise doit, elle aussi, se préparer à un changement de paradigme et savoir mettre en place des passerelles entre ses projets AGILE et ses processus de livraison standards.

Un retour d’expérience sur les bonnes pratiques et pièges à éviter absolument.

Flyer  pour les détails et, pour vous inscrire, cliquer ici

Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 503 followers

%d bloggers like this: