Catégorie : agile

Méthodes, retours d’expérience, bonnes pratiques

Jeu d’introduction de pairs pour les retrospectives #Agile

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Peer Introduction Game

http://www.funretrospectives.com/peer-introduction-game/

Le jeu d’introduction de pairs est une activité de développement de l’esprit d’équipe pour que les nouveaux membres de l’équipe en apprennent davantage les uns des autres. Une conversation rapide suivie par introduction par un pair fournit un mécanisme rapide de présenter chaque personne dans un grand groupe.

Passengers on an Icebreaker Watching Pack Ice
Avez-vous également expérimenté cet exercice « brise-glace » ?

Comment diriger l’activité

  1. Divisez le grand groupe par paires. Demandez aux gens de se mettre avec quelqu’un qu’ils ne connaissent pas bien.
  2. Demandez aux paires d’avoir une conversation rapide l’un de l’autre et informez-les que plus tard ils présenteront leur partenaire. Vous pouvez laisser la conversation ouverte, ou choisir quelques questions auxquelles répondre (comme : nom, lieu de naissance, rôle actuel, nourriture préférée, lieu de voyage préféré).
  3. Faites le tour du grand groupe et laissez tout le monde présenter son alter-ego.
Microsoft est partenaire de DantotsuPM
Microsoft est partenaire de DantotsuPM
Exemple

Paulo dit: « Je vous présente Amit. Il est né au Canada, mais sa famille est en Inde. Il aime la samba brésilienne et sa nourriture préférée est le hot-dog, plus particulièrement en assistant à une partie de base-ball. Il travaille actuellement comme … »

Essayez Bubble Plan !
Essayez Bubble Plan !

Note: J’ai été surpris la première fois que l’on m’a invité à faire cet exercice dans le cadre d’une réorganisation et de la mise en place d’une nouvelle équipe de management.

Questions: Avez-vous également expérimenté cet exercice « brise-glace » ? En connaissez-vous d’autres ?

Enregistrer

Enregistrer

Enregistrer

les mythes d’Agile : « il n’y a aucune planification dans #Agile »

Le par mopertodans agile1 commentaire

« Il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression »

http://trainings24x7.com/2015/06/22/list-of-free-pmp-sample-questions-websites/ par Leontranter

Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.

En fait, je vais aller plus loin et poser une affirmation audacieuse :

Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.

En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.

Il ne s’agit pas de plans mais de planification

Une de mes citations favorites est celle de Dwight Eisenhower :

« Les plans ne sont rien. La planification est tout. »

protectionCeci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.

Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.

Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :

  • Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
  • documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.

Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?

Pourquoi les projets entrent-ils dans une telle spirale ?

Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information

aveugleLes projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :

  • Peu ou pas d’informations sur le travail qui a besoin d’être fait
  • Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
  • Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)

Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).

Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:

« Aucun plan ne survit au contact avec l’ennemi. »

Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.

Les projets agiles planifient à plusieurs reprises par petits morceaux

Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).

Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :

  • Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
  • Pouvant être achevé en un sprint (qui est souvent de deux semaines).

Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.

Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.

Un si petit plan apporte-t-il vraiment de la valeur ?

Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».

Bien sûr, mais deux points :

  1. Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
  2. Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.

Une grande partie de la valeur réside  dans la Planification, pas dans le Plan.

Rappelez-vous la précédente citation de Eisenhower.

plans are nothingLes membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.

  • Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
  • Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?

Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.

Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

un mot et un seul pour démarrer vos rétrospectives #Agile…

Le par mopertodans agile, outils et méthodes2 commentaires

One Word

post ithttp://www.funretrospectives.com/one-word/

La technique « Un Mot » est un contrôle simple dans l’activité qui permet aux participants de partager leurs sentiments avant d’entrer dans les données et détails de la réunion en elle-même. C’est une bonne ouverture pour une réunion car elle reconnaît les sentiments des personnes et les fait parler dès le début.

Get the book on Amazon
Get the book on Amazon

Déroulé de l’activité

  1. Donnez à chaque participant un marqueur et un post-it
  2. Demandez-leur de décrire leur sentiment (dans le contexte de la réunion) en un mot
  3. Groupez les notes sur une grande page
  4. Optionnellement, demandez si quelqu’un veut en dire plus sur leur mot choisi

Décrivez s’il vous plaît < le dernier sprint ou le mois passé ou vos sentiments sur XYZ > en un mot !

Cette activité est décrite comme un Activité de Checkin par Esther Derby Et Diana Larsen dans leur remarquable livre Agile Retrospectives book.

à la lecture de ce billet, quel mot écririez-vous sur votre post-it, quel sentiment vous inspire-t-il ?

Microsoft est partenaire de DantotsuPM
Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Great International Agility survey: une enquête sur la culture #Agile, ses valeurs et principes

Le par mopertodans agileLaisser un commentaire

Ce sondage auquel je vous propose de participer couvre les 22 points mentionnés dans la présentation de Claude Emond « Culture agile – 4 valeurs, 8 techniques, 10 principes« 

La présentation de Claude: http://fr.slideshare.net/claudee/culture-agile-4-valeurs-8-techniques-10-principes

Sont également couverts dans cette enquête 12 points sur les «facteurs humains» et 8 points sur la résilience.

Take the survey
Take the survey

Enregistrer

Enregistrer

12 questions pour répondre à cette question : faites-vous du Développement Logiciel #Agile ?

Le par mopertodans agile, best practicesLaisser un commentaire

12 questions to find out: Are you doing Agile Software Development?

http://neilkillick.com/2015/07/26/12-questions-to-find-out-are-you-doing-agile-software-development/ Par Neil Killick

Voulez-vous faire Développement Logiciel Agile ? Non ==>
 AU REVOIR !

Oui

|

v
Votre équipe réfléchit-elle régulièrement comment s’améliorer ? Non ==> Rencontrez régulièrement votre équipe pour réfléchir à comment vous améliorer et rebouclez sur cette question.

Oui

|

v
Pouvez-vous livrer un logiciel utilisable fréquemment, au moins toutes les 2 semaines ? Non ==> Éliminez les obstacles à la livraison d’un incrément expédiable toutes les 2 semaines, rebouclez sur cette question.

Oui

|

v
Travaillez-vous quotidiennement avec votre client ? Non ==> Commencez à rencontrer quotidiennement votre client, rebouclez sur cette question.

Oui

|

v
Satisfaites-vous systématiquement votre client ? Non ==> Découvrez pourquoi votre client n’est pas content, corrigez cela, puis rebouclez sur cette question.

Oui

|

v
Vous sentez-vous motivés ? Non ==> Allez travailler pour quelqu’un qui a confiance en vous et qui vous apporte tout son support, rebouclez sur cette question.

Oui

|

v
Parlez-vous chaque jour avec votre équipe et vos parties prenantes? Non ==> Commencez à le faire puis rebouclez sur cette question.

Oui

|

v
Mesurez-vous principalement le progrès en fonction du logiciel livré qui marche? Non ==> Commencez à le faire puis rebouclez sur cette question.

Oui

|

v
Pouvez-vous maintenir indéfiniment votre allure de développement? Non ==> Embarquez moins de choses dans l’itération suivante, rebouclez sur cette question.

Oui

|

v
Prêtez-vous attention continue à l’excellence technique et à une bonne conception ? Non ==> Commencez à le faire puis rebouclez sur cette question.

Oui

|

v
Gardez-vous les choses simples et maximisez-vous la quantité de travail non faite ? Non ==> Commencez à garder des choses simples et écrire aussi peu de code que possible pour satisfaire le client, rebouclez sur cette question.

Oui

|

v
Votre équipe est-elle auto-organisée ? Non ==> N’assignez pas de tâches aux personnes et laissez l’équipe comprendre ensemble comment satisfaire le client au mieux, rebouclez sur cette question.

Oui

|

v
VOUS FAITES DU DÉVELOPPEMENT LOGICIEL AGILE!!

comment découper vos « User Stories » #Agile (Histoires Utilisateur) avec la méthode INVEST

Le par mopertodans agile, outils et méthodes2 commentaires

Splitting User Stories

http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari

Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.

Microsoft est partenaire de DantotsuPM
Microsoft est partenaire de DantotsuPM

I.N.V.E.S.T.

  • I – Indépendante
  • N– Négociable
  • V– de Valeur
  • E – Estimable
  • S – Suffisamment petite
  • T – Testable

Indépendante

Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.

Négociable

Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.

de Valeur

Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.

Estimable

Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».

Suffisamment petite

Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.

Testable

Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.

Découpage vertical ou horizontal

Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.

Des exemples de découpe de « User Stories »

Trop grosse User Story:
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits

Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…

  • En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.

Et/ou

  • En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.

Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.

Découpage par flux de travail

revoir mon panier de courses
revoir mon panier de courses

Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :

  • Fournir mes informations bancaires
    Fournir mes informations bancaires

    En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.

  • En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
  • Recevoir une notification par SMS
    Recevoir une notification par SMS

    En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.

D’autres méthodes

Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :

Visitez le blog Agilistic
Visitez le blog Agilistic
  • par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
  • par options d’interaction / par plate-forme
  • par types de données ou paramètres
  • par scénarios de test
  • par rôles
  • par ‘j’optimise maintenant ‘ contre ‘ j’optimise plus tard ‘
  • par compatibilité de navigateur

la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

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

Le par mopertodans agileLaisser un commentaire

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

Agile est le nouveau « normal »

Le par mopertodans agile2 commentaires

HP vient de publier les résultats d’une recherche qui tend à confirmer que Agile est devenue la norme dans les développements informatiques !

Les jeunes sont moteurs…

…et les plus âgés sont également favorables aux approches Agile car ils y voient un moyen de décloisonner les organisations et de mieux collaborer sur les projets.

Agile benefitsLes uns comme les autres n’oublient pas en adoptant Agile les objectifs business que cette approche permet d’atteindre en matière de satisfaction client, délais de mise en production (« Time To Market ») et coûts totaux de développement.

En effet, cette étude conduite auprès de plus de 600 professionnels de l’informatique indique que bien que l’adoption de Agile n’est réellement débutée que depuis 5 ans, elle s’est répandue « à la vitesse grand V » comme le montre la courbe ci-dessous que vous trouverez dans le rapport complet.

HP Report Agile Adoption

Enregistrer

Enregistrer

The AgileBA® Handbook

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

The Agile Business Analysis (AgileBA®) Handbook – published by DSDM Consortium – offers useful, practical and comprehensive guidance on the role of the business analyst working in an Agile way.

AgileBA HandbookIt also aims to give context to the business analyst role beyond the individual project, in relation to organisational mission and strategy, and to give additional depth and guidance for the business analyst role.

AgileBA highlights techniques that can help the Agile business analyst support the organization in the formulation and reviewing of its strategies. Even if the project-level Agile BA is not directly involved in defining the organization’s strategies, they need to understand the way strategy is formulated and the factors and forces which affect it. This will give them the perspective to ensure that the projects they are involved in have objectives that align with, and support, the organization’s strategic goals.

Business Analysis is crucial to the success and competitiveness of organizations in today’s rapidly-changing environment, enabling the timely delivery of high value, cost-effective solutions. As the project world continues to change, the BA role will continue to be an evolutionary role: embracing Agile is a significant part of this evolution.

The guidance is aimed at aspiring, new and existing Business Analysts, whether new to working in an agile environment or experienced in agile practices. It will also support project managers and product owners working with (or within) agile project teams and other practitioners looking to understand the value and role of business analysts on agile projects.

The handbook is also the official reference material for those undertaking accredited AgileBA training and Foundation & Practitioner level certification.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

mises à jour du « Scrum Guide »

Le par mopertodans agile, outils et méthodes2 commentaires

5 Valeurs : Courage, Focus, Engagement (Commitment), Respect et Ouverture (Openness)

Le 6 juillet dernier, Jeff Sutherland et Ken Schwaber, les créateurs du Scrum Framework, ont présenté les mises à jour du « Scrum Guide ».

La vidéo permet de suivre le wébinaire donné à cette occasion et la séance de questions/réponses.

De plus, la présentation est disponible ici

Scrum ValuesElle met en évidence 5 valeurs cardinales de Scrum et de l’Agilité et les détaille.

Microsoft est partenaire de DantotsuPM
Microsoft est partenaire de DantotsuPM

Visitez http://scrumguides.org  pour lire et télécharger le Official Scrum Guide (seulement disponible en Anglais pour l’instant).

Enregistrer

participez à cette enquête sur la coopération et soyez les 1ers à en recevoir les résultats

Le par mopertodans agileLaisser un commentaire

Cette enquête porte sur la coopération en entreprise.

Livre disponible sur Amazon
Livre disponible sur Amazon

Elle est rapide et prend moins de 5 minutes.

Elle est constituée de questions à choix multiple.

L’enquête est ouverte jusqu’au 22 juillet 2016

Faites-là connaître des personnes de votre entourage familial, amical et professionnel pour plus de réponses.

Les participants qui laissent leur email recevront la primeur des résultats.

L’enquête s’inscrit dans la suite des travaux qui ont conduit à la rédaction du livre L’Entreprise du vivre-ensemble publié le 31 mai 2016.

Répondez tout de suite !

Enregistrer

l’indice de Bonheur est un outil à connaitre pour les rétrospectives Agile

Le par mopertodans agile, outils et méthodes3 commentaires

Happiness Index – agile retrospective tool

Book on Amazon
Book on Amazon

http://blog.oikosofy.com/happiness-index-agile-retrospective-tool/

Peu importe combien votre équipe est performante, il y a toujours une opportunité d’amélioraation. L’indice de bonheur est un outil des rétrospectives agile, qui mesure le bonheur des équipes agiles. Luis Gonçalves le partage dans le livre écrit avec Ben Linder « Getting Value out of Agile Retrospectives. »

Cet exercice est une combinaison de « Développez une chronologie » et « Sismographe émotionnel » de Normand L. Kerth.

Que pouvez-vous tirer de cette technique ?

Le but de cet exercice est d’avoir une représentation graphique des émotions des membres de l’équipe pendant un Sprint. Ce type d’informations aide l’équipe à identifier ce qui affecte sa performance pendant le Sprint. Indépendamment du problème qu’expérience l’équipe, cet exercice les aide à révéler les émotions d’équipe directement en cet endroit.

Quand utiliseriez-vous cette technique ?

C’est certainement approprié pour une équipe qui passe à travers beaucoup d’émotions différentes (positives ou négatives) pendant un sprint. Cela leur bénéficie quand ils veulent en évaluer les conséquences ou quand l’équipe a plusieurs défis dans le Sprint et voudrait comprendre comment ces problèmes sont apparus.

L’indice de bonheur est approprié pour n’importe quelle équipe. Il n’exige pas de niveau de maturité spécifique. L’exercice peut être appliqué tant aux équipes à distance qu’à celles réunies en un même lieu.

Comment le réaliser ?

Prenez une page blanche A4 et quelques post-it. Divisez le papier sur 2 parties/axe – positif et négatif. Graduez ensuite l’axe des abscisses en fonction des jours de sprint.

indice bonheurIl y a 2 façons de conduire l’exercice

équipe en face à faceOption 1 : L’exercice est fait pendant la rétrospective avec toute l’équipe

Créez de petits groupes de 2-3 personnes. Demandez-leurs de faire une session de brainstorming sur les événements ou les situations qui se sont produites pendant le dernier sprint. Ensuite, demandez aux groupes de créer une représentation graphique des niveaux émotionnels pour les situations sur lesquels ils ont fait du brainstorming. Quand tous les groupes ont terminé, compilez une représentation de tous les groupes sur un seul graphique. N’oubliez pas de mettre une explication sur chaque émotion différente.

intérêtOption 2 : L’exercice est réalisé par petits bouts pendant le sprint

Au lieu d’une équipe dessinant le graphique émotionnel, vous laissez chaque individu dessiner un graphe avec son propre niveau d’émotion à la fin de chaque journée de travail. Cette approche permet de s’assurer que tous les événements ou situations sont couverts et aucun n’est oublié.

Les deux options marchent bien!

Vous aurez une belle vue de ce qui est arrivée pendant le sprint. Ces informations aident le facilitateur de la rétrospective dans l’identification des situations qui devraient être répétées et des événements qui causent des problèmes ou le retard de l’équipe.

Microsoft est partenaire de DantotsuPM
Microsoft est partenaire de DantotsuPM

De plus, vous pouvez aussi utiliser des techniques d’analyse de cause racine pour identifier les problèmes fondamentaux.

Scrum of Scrums : l’essentiel pour appliquer Agile à de plus larges efforts

Le par mopertodans agileLaisser un commentaire

Scaling Agile, Scrum of Scrums – The Basics

https://tcagley.wordpress.com/2015/06/23/scaling-agile-scrum-of-scrums-the-basics/ par Thomas M. Cagley

Scrum Stand upLa technique Scrum of Scrums (SoS) sert à augmenter la portée de Scrum et autres techniques Agiles et les appliquer à de plus grands efforts. Sur le papier, le SoS est une simple extrapolation des réunions quotidiennes de Scrum ou stand-up meeting qui sont devenues le label de la pratique Agile. Une typique réunion debout se produit chaque jour pour que tous les membres de l’équipe puissent coordonner et planifier les activités du jour. Classiquement, l’équipe utilise la technique des trois questions pour organiser la réunion. De la même manière, une session Scrum of Scrums typique agit comme un focus pour aider à synchroniser une équipe d’équipes ou même plusieurs équipes d’équipes.

Il y a quatre basiques pour SoS qui doivent être compris avant toute adaptation.

1. Qui participe

Scrum Stand up egalitarianIl y a deux écoles de pensée dans le choix des participants au SoS. La première (et plus commune) école suggère que le Scrum Master soit présent lors du SoS. Le Scaled Agile Framework Enterprise (SAFe) est un exemple d’une méthodologie qui met à profit le Scrum Master tant pendant l’événement de planification que pendant l’incrément de programme. Alors que le deuxième groupe adopte une approche plus égalitaire (probablement plus pragmatique) permettant à chaque équipe de choisir un participant qui peut le plus facilement transmettre ou comprendre que les problèmes actuels de l’équipe et du plus grand groupe à cet instant. Par exemple, si les décisions de conception sont primordiales, peut-être des membres de l’équipe avec la grande compréhension UX. Dans ce scénario, les participants varieraient au fil du temps.

2. Qui facilite

Pour de petits SoS, par exemple une poignée d’équipes co-localisées, une facilitation peut ne pas être exigée. Le SoS peut s’auto-organiser et exécuter la réunion avec peu de facilitation additionnelle. Cependant, comme le nombre de participants augmente (je limite les réunions SoS en utilisant la même règle 5 à 9 membres utilisée dans les équipes Scrum) ou comme la distribution géographique des membres s’accroit, la facilitation devient plus importante. Les facilitateurs aident l’équipe à utiliser la pratique du SoS, s’assurent que la logistique est en place et gèrent le temps. Dans de plus grands efforts, un Directeur de Programmes fournit souvent la facilitation, ou si vous pratiquez SAFe, le Release Train Engineer joue ce rôle de facilitateur.

3. Fréquence

Image courtesy of pakorn / FreeDigitalPhotos.net
Image courtesy of pakorn / FreeDigitalPhotos.net

Le Scrum of Scrums suit souvent le même modèle que la réunion quotidienne de Scrum/Stand-Up. Un deuxième modèle de fréquence est basée sur le niveau de risque; la fréquence des réunions SoS varient en fonction du besoin. Tôt dans un projet le SoS se tient quotidiennement comme les équipes se forment, se trouvent et que les premières décisions sont construites. La réunion SoS passe à deux fois par semaine au milieu du projet et revient ensuite à quotidienne comme une fin de release approche.

4. Format

Les réunions quotidiennes debout déroulent généralement la classique approche avec trois questions (Qu’ai-je fait ? Que vais-je faire ? Et quels sont mes points de blocage ?).

La réunion Scrum of Scrums suit généralement un format TRÈS SEMBLABLE avec chaque participant qui répond aux quatre questions suivantes :

  1. Qu’est-ce que mon équipe a fait depuis la dernière réunion ?
  2. Que fera-t-elle avant que nous ne nous rencontrions de nouveau ?
  3. Mon équipe rencontre-t-elle des points de blocage ?
  4. Mon équipe va-t-elle délivrer quelque chose qui est sur le chemin d’une autre équipe ?

La réunion suit la même approche : chaque participant interagit à tour de rôle avec les autres. Le facilitateur (si utilisé) ne devrait jamais être au centre de la réunion, et le SoS ne devrait pas dériver en une réunion de statut d’avancement.

Le stand-up quotidien et le SoS Sont des réunions très semblables. Les deux réunions sont tenues pour partager des informations, coordonner des activités et identifier des problèmes. Le périmètre de la réunion SoS est plus large qu’une seule équipe et cette réunion fournit la coordination et les activités de planification dans et transverses aux équipes.

May 10 – Anvers – Reinforce traditional project management with Agile

Le par mopertodans agileLaisser un commentaire

Agile… again… when will this hype finally be over ?!

PMI Belgium Chaper Web Site
PMI Belgium Chaper Web Site

Well… probably never.

It is not even a hype. It is just sound project management.

There have always been aspects of agile, and there will always be aspects of agile. In any project that is somehow successful.

This session will walk you through a series of different types of projects each time picking out one (or more) aspects of agile. By the end of this chapter event you will have a clearer view of how agile and traditional project management (can) reinforce one another.

Steven Deneir will share his vast experience of combining Agile with traditional project management practices. Next to managing projects and programmes himself, Steven gives certified training and coaching workshops for companies. He’s also experienced in doing maturity assessments and giving speeches at conferences. He holds many certificates of Portfolio, Programme and Project Management specialties.

Register for this PMI Belgium Chapter event

Scrum… Vraiment

Le par mopertodans agile, outils et méthodesLaisser un commentaire

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)

Le rapport CRASH de CAST Software révèle les réels impacts du développement Agile

Le par mopertodans agile, pointeurs utiles1 commentaire

impact objectif des méthodes agiles, de l’externalisation et de l’offshoring: des évidences mais aussi de l’inattendu !

Rassemblant les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises, cette étude de CAST sur la qualité logicielle des applications (CRASH), présente l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.

Télécharger le rapport CRASH

L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.

Crash Report 2015

Les principales conclusions sont pour certaines évidentes, d’autres bien plus surprenantes.

  • l’intégrité architecturale d’une application affecte sa sécurité,
  • les applications servant plus d’utilisateurs ont tendance à être de meilleure qualité,
  • la maturité des processus (niveau CMM) affecte la qualité générale du code,
  • les méthodes hybrides Agile/Waterfall produisent de meilleurs résultats que les méthodes agiles pures,
  • les équipes internes et externalisées fournissent la même qualité de code,
  • l’offshoring impacte la robustesse et l’évolutivité des applications.
Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Précédentes éditions:

Call for proposals PROJECT MANAGEMENT JOURNAL® AGILE Special Issue

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Exploring the Role of Agile Approaches for the Management of Projects

PM Journal April_MayCoverAlthough agile-related topics are discussed in computer science and information management literature primarily regarding software development (see Cardozo et al., 2010), the concept has also been applied to non-IT related projects, notably new product development (Ries, 2013; Blank, 2010). Application of the agile concept has been suggested for other types of projects (Conforto et al., 2014; Ktata & Lévesque, 2009).

It is not clear how the agile concept translates in domains outside of software development.

Geeky Unsure WomanDoes it replace or negate traditional project management concerns with risk, scheduling, metrics, and execution, or does it shift how we think about these and necessitate new techniques and approaches?

Does it translate differently into different domains, for example, construction versus new product development?

This special issue of Project Management Journal® seeks a wide range of papers that draw on diverse institutional settings, theories, and approaches to understand the different aspects of agile-based process models and methods as applied to project management both within and outside the domain of software development. The Project Management Journal’s mission is to shape world thinking on the need for and impact of managing projects by publishing cutting-edge research to advance theory and evidence-based practice.

Check ou the details of the potential topics for your papers’ proposals here.

DEADLINES FOR PAPER SUBMISSION:
  • 1 June 2016: Submit proposal of 2,000 words, including a tentative title, aim, and nature of the submission (conceptual or empirical).
  • 1 September 2016:  Authors informed of decision.
  • 1 February 2017: Submit full paper of up to 10,000 words.

Agile is dead ! Long life to Agility !

Le par mopertodans agile1 commentaire

Pourquoi visionner une conférence sur un thème a priori déjà beaucoup commenté  ? Qui plus est, pour une durée de 40 minutes… et en anglais !

Parce que c’est LA conférence qui discute de l’essence même des principes fondateurs de ce que l’on appelle maintenant « l’agilité ». L’orateur, Dave Thomas est ici tout à fait légitime puisqu’il revient sur la réunion, à laquelle il participait en 1999 qui donnait lieu au « Manifesto for agile software development ».

Dans la première partie, Dave porte un regard sur ce qu’est devenu le mouvement agile, et il analyse comment certains ont perdu de vue ce qu’est ou ce que n’est pas Agile, il se livre à une sorte de déconstruction qui lui fait dire de manière provocatrice : « Agile is Dead ».

C’est pour mieux expliquer, dans la seconde partie l’esprit même de la démarche « agile » et rappeler sa pertinence tout à fait actuelle et valide.

C’est un vrai plaisir à regarder, la présentation est très claire, les arguments percutants et les idées développées sont simples, ce qui permet à cette conférence de se classer parmi celles qui nous laissent quelque chose, et qui peuvent réconcilier avec la démarche agile ceux qui pourraient trouver que la notion est galvaudée.

Un recentrage qui fait du bien !

Un billet de Jean-Michel Torres que je remercie vivement car je suis certain que vous serez nombreux comme lui (et moi-même) à apprécier cette vidéo.

3 articles sur Agile au niveau de l’organisation

Le par mopertodans agile, pointeurs utiles1 commentaire

Nouvelles Ressources de Conduite de projet Agiles sélectionnées par Melanie Franklin

New Agile Project Management Resources par Melanie Franklin

Melanie Franklin
Melanie Franklin

J’ai choisi ces articles récents car ils racontent tous une histoire semblable sur l’importance de l’agilité dans le business en tant que partie essentielle de gagner un avantage compétitif. Ils partagent aussi ma propre philosophie qui est que cette agilité business est l’objectif final pas seulement le développement logiciel agile. Donc les méthodes Agiles devraient être considérées pour ce qu’elles sont : des contributions à une agilité globale de l’organisation.

L’étude du management de projet Agile fournit une compréhension de base d’Agile qui vous permet d’appliquer Agile à tous les aspects de votre rôle et votre organisation:

1. McKinsey fournit le cas d’affaire pour être Agile, mais il met aussi en évidence l’importance de processus métier cohérents et clairs qui permettent à l’organisation de répondre de façon agile sans mettre à risque tout ce qu’elle a déjà réalisé.

2. Un rapport détaillé d’Accenture met en avant l’écosystème business dans son ensemble (fournisseurs, collaborateurs, clients) doit devenir Agile. Il met aussi en évidence comment être agile est maintenant considéré par les dirigeants d’entreprises comme une caractéristique essentielle de réussite des organisations.

3. Forbes relève un exemple d’organisation qui a développé ses approches agiles sur la base du développement logiciel agile et de la conduite de projet agile.

N’hésitez pas à poster vos commentaires sur ces documents ! Et vos pointeurs vers d’autres rapports sur le sujet.

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

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Microsoft est Partenaire de DantotsuPM
Microsoft est Partenaire de DantotsuPM