Archive | agile RSS feed for this section

ne soyez pas un zombie de Scrum

15 juil

ZombieDon’t be a Scrum Zombie

http://www.pmhut.com/dont-be-a-scrum-zombie par Marc Löffler

Toute équipe de Scrum connait les 3 questions les plus célèbres posées chaque jour pendant le « Daily Scrum » :

  • Qu’avez-vous réalisé hier ?
  • Que ferez-vous aujourd’hui ?
  • Quels sont les obstacles ?

Pour certaines équipes cette réunion est juste un devoir ennuyeux et à cause de cela on répond à ces questions sans passion. Une chose que j’ai observée dans les dernières semaines et mois est combien ces questions ont des poids différents. On répond à la première question sur le dernier jour de travail en grand détail tandis que la réponse à la deuxième question est très courte et si on répond la troisième question c’est seulement pour déclarer qu’il n’y a actuellement aucun problème. Donc la plus grande partie de la réunion est une discussion sur le passé. L’avenir et les obstacles sont tout simplement ignorés. A mon humble avis, ceci est un gros problème qui devrait être évité.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Qu’avez-vous réalisé hier ?

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

La réponse à cette question ne doit pas être une liste détaillée de toutes les tâches vous avez fait hier. De plus, il ne s’agit de découvrir qui a fini le grand nombre de tâches et était apparemment le membre de l’équipe le plus travailleur. Le point n’est pas de créer un rapport pour le ScrumMaster, le Propriétaire de Produit ou une partie prenante.

Au lieu de cela la réponse devrait seulement contenir les informations qui sont utiles à tous les membres de l’équipe et importantes pour le reste du sprint. De cette façon les informations sont intéressantes et de valeur pour tous les membres de l’équipe, tout le monde écoute et en bénéficie.

Que ferez-vous aujourd’hui ?

Today is a good daySouvent on répond cette question avec un simple "je continuerai à travailler sur …". Ceci n’a aucun rapport avec une approche tactique. Chaque membre de l’équipe devrait attentivement observer la réunion et considérer quelle est l’étape suivante raisonnable pour supporter l’équipe dans l’atteinte du but du sprint. En particulier, les membres de nouvelles équipes de Scrum ont tendance à penser à leurs propres tâches au lieu de penser et travailler comme une équipe.

Il n’est pas important de commencer à travailler sur toutes les tâches de l’Arriéré de Sprint, mais bosser ensemble sur les tâches une par une. Au mieux deux membres de l’équipe travaillent simultanément sur une tâche en utilisant des techniques comme la programmation de pairs. C’est pourquoi le Daily Scrum est aussi l’endroit parfait pour décider qui s’appariera avec qui. Le Daily Scrum est une petite réunion de planification et c’est pourquoi vous devriez l’utiliser comme tel.

Quels sont les obstacles ?

Cheval, ObstacleDe façon intéressante, ceci est la question la plus sans réponse des trois. À la fin, tous les problèmes cachés surgissent dans la Rétrospective de Sprint bien qu’ils auraient pu être résolus pendant le sprint. Mais pour pouvoir les résoudre quelqu’un doit les mentionner.

Les raisons de ce comportement sont variées. Quelques membres de l’équipe croient que leur ScrumMaster n’est pas capable de résoudre leur problème. Les autres membres de l’équipe sont habitués à résoudre leurs problèmes tout seuls. Mais ces problèmes et obstacles cachés sont souvent ceux qui sont la cause d’un but de sprint manqué. C’est seulement si tout le monde connaît tous les obstacles que l’équipe peut les balayer du chemin vers le but de sprint.

Ne vous comportez donc pas comme un zombie de Scrum. Le Daily Scrum Quotidien n’est pas un devoir ennuyeux, mais une chance de réussir la prochaine étape vers le but du sprint.
Partenaire de DantotsuPM

Partenaire de DantotsuPM

 

17 Juillet – Webinar – Two to Tango – Quality and Velocity in Large IT Set-up

7 juil
Image courtesy of ambro / FreeDigitalPhotos.net"

Image courtesy of ambro / FreeDigitalPhotos.net"

Dans la plupart des organisations, les équipes informatiques se sont séparées en deux groupes distincts : un groupe travaille en Scrum, suit le rythme imposé par les métiers, s’adapte aux nouvelles technologies et innove; l’autre groupe préfère ou a besoin de suivre un modèle de gestion traditionnel en waterfall.

Comment abordez-vous le compromis vitesse-qualité quand la cohabitation entre agilité et organisation traditionnelle entraine un manque de cohésion et donne lieu à des problèmes de qualité ?

Cast LogoLes pratiques observées par des experts du sujet peuvent surprendre : CAST a invité plusieurs experts pour ce webinaire gratuit en langue anglaise:

  • Diego LoGiudice, analyste principal chez Forrester Research et expert en méthodes agiles et en mesure de la qualité des logiciels
  • Dr Bill Curtis, directeur du Consortium for IT Software Quality
  • Suresh Bala, VP ‘Application Management‘ de Wipro

M. LoGiudice relatera les défis rencontrés en introduisant plus de vitesse dans l’IT traditionnel. M. Bala décrira une approche pour améliorer la réactivité et la qualité d’un grand parc applicatif en mesurant l’actif logiciel.

Pour assister à cette web-conférence en anglais le jeudi 17 juillet à 16h30, cliquez ici.

Ce lien vous permet également de vous inscrire pour recevoir l’enregistrement de la web-conférence si vous n’êtes pas en mesure d’y participer.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

June 26 – Webinar (APMG) – Why it’s time to become Agile ?

17 juin
Melanie Franklin

Melanie Franklin

A one hour APMG Webinar with Melanie Franklin, AgileChangeManagement Ltd, at 2PM CET/FRANCE

Do you know what agile really means? When your colleagues talk about ‘going agile’ do you know what is involved and how it might affect you?

This webinar is packed with facts and practical experience of adopting an agile approach to project management. It will help you understand how agile is different to other methods including PRINCE2 and what the benefits and the challenges of agile really are.

Melanie is an experienced project and programme manager and is currently supporting several high profile organisations through their transition from traditional to agile project management.

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

Click Here To Register

Partenaire de DantotsuPM

Partenaire de DantotsuPM

20 Novembre – Agile Grenoble 2014

16 mai
Visitez le site

Visitez le site

Les méthodes agiles sont devenues incontournables. Elles ont prouvé leur efficacité et l’heure n’est plus aux questions mais à l’action !

La conférence Agile Grenoble sera encore cette année l’événement agile incontournable de la région. C’est le rendez-vous pour tous les professionnels qui souhaitent savoir comment s’y prendre, découvrir, échanger, apprendre, expérimenter, tester, approfondir leurs connaissances, ou simplement discuter autour de l’agilité.

Deux personnes (ou devrait-on dire "personnages") qui sont à la fois influenceurs, passionnés et changeurs de monde. Alexandre GERARD et François BEAUREGARD seront au rendez-vous le 20 novembre 2014 pour votre plus grand plaisir !

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.

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 079 autres abonnés

%d bloggers like this: