Voir l’article de Jean-Claude Grosjean sur le sujet: Scrum Guide 2013: le Product Backlog Refinement à l’honneur!
La version de Juillet 2013 en ligne du Scrum Guide de Ken Schwaber et Ken Sutherland (auteurs de Scrum).
version 2013 du Scrum Guide
Catégorie : agile
Méthodes, retours d’expérience, bonnes pratiques
pensons Produit Minimum Viable (MVP)
MVP Thinking
http://brodzinski.com/2013/06/mvp-thinking.html par Pawel Brodzinski
Un des buts atteints par Eric Ries’ Lean Startup’ et porteur du plus de valeur est de populariser le terme de « Minimal Viable Product » (MVP), ou Produit Minimum Viable en français. Bien sûr le concept n’est pas nouveau. Nous utilisions l’idée de « Minimal Marketable Feature » (MMF) depuis les tous premiers jours de Kanban et elle était basée sur la même façon de penser. Il y a aussi davantage de concepts similaires.
La prémisse de base est que nous devrions construire la chose la plus petite possible ou faire fonctionner l’expérimentation la plus petite possible qui reste raisonnable et ajoute de la valeur. Selon le contexte la valeur peut être quelque chose qui aide des utilisateurs, mais peut aussi être simplement la découverte de nouvelles connaissances ou la vérification d’une hypothèse.
Une chose que j’ai réalisée récemment est à quel point j’applique largement cette pensée. Initialement, c’était simplement la façon de décomposer le contenu. J’ai voulu que mes équipes construisent des morceaux de logiciel probablement petits, mais toujours de valeur, et qu’un client puisse donc vérifier et nous donner un retour avec des informations utiles. Alors, après Lean Startup, il s’agissait de faire fonctionner un produit. Ce que nous voulons construire est quelque chose de nouveau qui frappe les esprits. Quelle est la fonctionnalité la plus petite qui peut prouver ou réfuter l’hypothèse que cela puisse fonctionner ?
D’une façon ou d’une autre j’utilise maintenant la même façon de penser, la pensée MVP si vous voulez, pour discuter des idées de marketing, définir des plans d’action pendant des rétrospectives, etc. Souvent il est difficile de définir un produit en soi, mais il y a toujours une idée des résultats attendus et un effort minimal définissable permettant d’obtenir ce résultat.
Ainsi comment définirais-je la pensée MVP ?
1. Définir le plus petit prochain objectif de valeur que vous voulez réaliser.
2. Définir l’effort minimal qui vous permettra d’atteindre ce but.
3. Exécuter.
4. Analyser les résultats et apprendre.
5. Itérer.
Une partie potentiellement délicate est la définition de l’objectif parce que c’est totalement contextuel. C’est aussi quelque chose qui me plaît vraiment car je n’aime pas les recettes toutes prêtes. En fait, s’il y a quoi que ce soit de nouveau ici, c’est essentiellement l’application extrêmement large du modèle car l’idée elle-même n’est pas nouvelle. Je veux dire, nous limitons d’habitude notre contexte de travail au périmètre d’un projet, au management d’un produit, à faire tourner une affaire, etc. Alors, nous inventons un nouveau terme et s’il marche nous en faisons nos carrières de consultants excessivement bien payés.
Ce n’est pas du tout mon but. J’essaye juste d’élargir un contexte applicable d’idées que nous connaissons déjà et que j’ai personnellement trouvées utiles.
résolution de problème
Donc si mon problème est une fuite sous le toit près d’une lucarne, mon objectif minimal suivant peut être de vérifier si la fuite a un rapport avec un volet externe. Un tel objectif est acceptable parce que l’effort minimal peut être simplement d’attendre l’averse suivante avec le volet ouvert ou fermé. Je ne me précipite certainement pas pour réparer le toit.
marketing
Si nous parlons de marketing ? Donnons un objectif général, disons: TechCrunch parlera de nous. Quelle serait l’expérimentation de valeur la plus petite qui pourrait nous rapprocher de la réalisation de cette sorte d’objectif ? Je suppose qu’étendre et manager son réseau peut être une première étape très raisonnable. Cela n’exige même pas d’avoir une idée, sans parler d’un produit, que nous voudrions voir couvert.
développement de produit
Que diriez-vous d’un produit ? Eh bien, celui-ci a été couvert pratiquement partout. Construire la fonction minimale, probablement même une simulation, qui permet de vérifier que l’idée pour le produit a du sens.
leçons apprises
Rétrospectives ? Quel est le simple, plus petit possible, changement qui aura un impact positif sur l’équipe ? Essayez-le. Vérifiez-le. Répétez.
achats
Zut, j’achète même mon équipement de marin de cette façon. Quel est le plus petit jeu d’équipements possible qui donne une chance de survie raisonnable ? Puis, j’utilise le résultat et je réitère, par exemple la prochaine fois j’aurai besoin de nouveaux gants, de caleçons longs et de protection imperméable pour un téléphone.
Quand vous y pensez c’est essentiellement du Kaizen – faire systématiquement de petites expériences d’amélioration partout. Alors oui, il n’y a rien de nouveau. C’est seulement l’idée spécifique de Produit Viable Minimal qui me parle personnellement et m’a donné une contrainte agréable qui peut être utilisée dans les différents domaines de ma vie.
À propos, malgré sa définition très ouverte je trouve aussi que Kaizen est d’habitude appliqué dans un contexte très limité. Aussi, peu importe quelle idée marche pour vous, souvenez-vous juste que vous pouvez l’utiliser dans un contexte beaucoup plus large.
Projet Porsche 911 : l’épreuve de vérité d’un développement Agile ?
Project Porsche 911: Where the rubber meets the road
Http://pmbox.geniusinside.com/manufacturing/project-porsche-911-where-the-rubber-meets-the-road-2/ par : Sofia Hess, Genius Inside Germany
Bien que la célèbre Porsche 911 ait été présentée en septembre 1963 au salon de Francfort (alors appelée la 901), cela ne dénote pas de son grand âge !
C’est un classique absolu parmi des voitures de sport et sa conception éternelle ne se dépare jamais de style. Dans le monde du management de projet, la Porsche 911 est certainement un projet vedette. Selon magazine allemand « MotorKlassik« , seulement 10 prototypes ont été construits avant sa sortie officielle en septembre 1963. Ce simple fait est presque incroyable, comparé aux constructeurs d’automobiles de série d’aujourd’hui qui peuvent passer par des centaines de prototypes avant un lancement de produit.
À l’occasion de son 40ème anniversaire, il y a maintenant 10 ans, trois messieurs, qui ont joué un rôle central dans le succès de la Porsche 911, ont raconté leur histoire vue de l’intérieur à « MotorKlassik ». Ce que j’ai retenu de leur histoire est que dans de nombreux cas des équipes projet plus petites menées par des ressources douées portant de multiples casquettes peuvent donner une meilleure visibilité et des résultats plus efficaces dans les projets. L’ancien pilote de voiture de course et ingénieur développement chez Porsche, Hans Mezger a dit à MotorKlassik qu’il était non seulement responsable de la conception du moteur, mais aussi des essais sur route. Peter Falk, un des principaux ingénieurs, a expliqué que le temps de mise au point était court en raison du fait que les décisions pourraient être prises rapidement et mises en pratique immédiatement (car il n’y avait aucune paperasserie dont on devait se préoccuper en ce temps-là).
Un autre avantage que l’équipe projet avait à ce moment-là était leur petite taille et la proche proximité les rendant agiles et flexibles. Peter Falk a mentionné qu’il était possible d’être assis à son bureau tout en regardant l’atelier conduire le test du véhicule. Dans l’environnement de projet d’aujourd’hui, ce serait très difficile de manager un projet de cette façon. Bien que les gens de nos jours chez Porsche soient toujours de grands innovateurs, la réalité est qu’ils n’ont pas la même liberté de mouvement pour partager leur vision et leur créativité et sont souvent étouffées par des normes et des règlements. La vérité est, il n’y a probablement aucune autre industrie dans le monde qui a des niveaux rigoureux de réglementation juridique et de contraintes similaire à l’industrie automobile. En conséquence, la capacité de livrer des résultats réussis est devenue un énorme défi.
De la R&D à la fabrication en série de véhicules, les constructeurs automobiles doivent strictement adhérer aux réalités de la conformité réglementaire. De plus, des équipes projet font face de nos jours à l’obstacle d’être plus grandes et dans des nombreux cas fonctionnant avec des équipes dispersées à l’échelle planétaire qui doivent collaborer avec une interaction physique minimale.
tout ce que vous aimeriez savoir sur AgilePM de APMG
Agile Project Management
Agile Project Management, basée sur DSDM Atern, est une approche novatrice pour le management de projet, qui aide les acteurs à travailler ensemble
efficacement, pour atteindre les objectifs de l’organisation. Contrairement à une approche traditionnelle, Atern fixe les délais, les coûts et la qualité dès les premières phases d’un projet.
Agile Project Management procure :
• Une approche qui offre l’agilité mais qui retient les concepts d’un projet, de la livraison et de la gestion de projets ;
• Une approche agile qui est compatible avec des approches plus formalisées de gestion de projet comme PRINCE2.
2 niveaux de certifications
Agile Foundation
Le niveau Foundation vise à mesurer si le candidat a les connaissances et une compréhension suffisantes du management de projet Agile pour pouvoir reconnaître et distinguer les éléments clés de l’approche. A cette fin, ils ont besoin de démontrer qu’ils comprennent la philosophie de Management de Projet Agile, les principes, les processus, les personnes, les produits, les techniques et conseils.
Examen Agile FOUNDATION: 60 minutes, 60 questions, QCM, score minimum: 50%, livre fermé.
Agile Practitioner
Le niveau Practitioner vise à mesurer si le candidat a les connaissances et la compréhension suffisantes du management de projet Agile pour l’appliquer et l’adapter à une situation de scénario donnée. Le scénario est conçu pour permettre au candidat de démontrer sa compétence à initier un travail en tant que chef de projet Agile sur un projet non-complexe.
Examen Agile PRACTITIONER: 2 heures, 4 questions, test objectif, score minimum: 50%, livre ouvert.
Lisez le papier blanc de QRP International « AGILE – ALL YOU NEED TO KNOW »
Et regardez et écoutez Ian Stokes nous en parler.
using MS Project for Agile projects
Agile project management methodologies (such as Scrum, Extreme Programming and others) are based on process-centric and iterative development rather than a traditional waterfall approach. Some of the key characteristics of an agile project include a backlog, burn-down charts, frequent communication, and short-cycle delivery of project outputs that don’t typically lend themselves to traditional MS Project scheduling techniques. But in this informative webinar, we’ll show you techniques and tips on how to use MS Project to effectively manage projects in the new frontier of Agile Project Management!
This session is presented by Matt Davis, PMP, MCITP, President of the Microsoft Project Users Group (MPUG) Boston Chapter.
faites-en moins
Do Less
http://www.allaboutagile.com/do-less/ par Kelly Waters
J’ai récemment écrit un billet appelé 10 Things Executives Need To Do Differently (In Agile). Je l’ai aussi présenté à la conférence Agile Australia.
Comme beaucoup de choses dans cette liste, la première des 10 choses est facile à dire et très difficile à faire. C’est un mantra majeur de la pensée LEAN – « Faites-en Moins ».
Il y a des surcoûts et donc de la perte, dans la commutation de tâche (relisez « le multitâche vous ralentit »). Et il y a aussi plus de valeur à livrer quelque chose plus tôt, plutôt que de progresser de multiples choses et les avoir toutes partiellement achever et prendre plus de temps pour finir.
Voici un exemple délibérément simpliste de pourquoi Cela *paye* d’en faire moins…
Disons que vous avez 3 projets. Chaque projet demande un effort de 3 mois pour être achevé. Chaque projet ne délivre qu’une valeur de $10,000 le premier mois, augmentant de $10,000 chaque mois jusqu’à atteindre un plateau de $50,000 par mois.
Le scénario 1 est que les 3 projets sont menés en parallèle, qui est ce qui se produit d’habitude, particulièrement dans les plus grandes organisations. Aucune valeur ne sera réalisée avant la fin des 9 mois. En réalité cela pourrait aussi prendre plus longtemps, en raison de l’inefficacité de la commutation de tâche.
Le scénario 2 est que vous complétez chacun des projets à son tour, vous 
concentrant entièrement sur chaque projet jusqu’à ce qu’il soit fini. Après le mois 3, le projet 1 commence à accumuler de la valeur. Après le 6ème mois, le projet 2 commence à accumuler lui aussi de la valeur. Après le 9ème mois, le projet 3 est lui aussi livré, pas plus tard que dans le scénario 1.
Dans cet exemple simple, cumulativement nous avons réussi à réaliser beaucoup plus de valeur dans le scénario 2 où chaque projet est complété à son tour. Nous avons aussi le bénéfice d’une vitesse plus rapide pour commercialiser les 2 premiers projets, qui pourraient potentiellement nous donner un avantage sur nos concurrents et nous permettre d’établir notre position en premier sur le marché.
Maintenant regardons les chiffres pendant l’année 1 :
- Scénario 1 : accumule une valeur de $180,000
- Scénario 2 : accumule une valeur de $610,000
C’est une différence massive selon tout standard! 330 % de plus de valeur.
C’est un concept si simple.
Et du point de vue de la logique, il est vraiment indiscutable. Mais nous tous semblons tomber dans le même piège commun. Le piège de devoir montrer à tous du progrès, donc nous finissons par en faire trop tout de suite, même si cela délivre moins de valeur au final pour notre organisation.
Peut-être cette explication vous aidera-t-elle à en convaincre d’autres, parce que je suis certain que dans de plus grandes organisations vous pouvez ajouter un ou deux zéro aux chiffres ci-dessus !
Et imaginez tous les maux de tête en problèmes d’approvisionnement et de priorisation qui s’envolent quand on permet à l’équipe de se concentrer sur un projet à la fois. Quel bonheur!
S’il y a une chose qu’un cadre exécutif peut faire pour davantage aider ses équipes, c’est leur fournir l’opportunité de se concentrer.
Integrating Agile into PRINCE2: Webinar recording and slides available
Agile methods and frameworks are increasing in popularity as organizations and individuals seek increased flexibility when managing change initiatives.
Agile approached are often seen as rivals to waterfall methods including PRINCE2, when in reality they complement each other.
This webinar shows how the speed of delivery from Agile and the quality of project definition from PRINCE2 satisfies those seeking excellence and flexibility in project delivery, whilst maintaining strong project governance.
The session:
- Defines what agile working means and how this has been captured in the APMG Agile Project Management qualification scheme
- Uses the PRINCE2 process model to explain how agile project management can govern development, with PRINCE2 governing the overall project.
View/Download Webinar Recording (48 MB)
View/Download Presentation Slides (1.7 MB)
« Je veux diriger un projet agile »
“I want to run an agile project”
https://www.ibm.com/developerworks/community/blogs/julian/entry/iwanttorunanagileproject?lang=en par Julian Holmes
Prologue
Comme la valeur des pratiques Agile est mieux comprise, de courageux chefs de projet commencent à défier les pratiques normales de l’organisation et demandent l’opportunité d’adopter une approche plus agile.
Dans les films animés “I want to run an agile project” (par Carson Holmes et Julian Holmes (Julian) ), nous suivons les expériences de Luke, un tel chef de projet courageux, et nombre de ses différentes rencontres partout dans l’entreprise, comme il travaille pour mettre en place et livrer son projet Agile.
Après avoir observé son voyage tristement distrayant, dans cet article nous expliquons ce qui se passe vraiment, et commençons à mettre en évidence les raisons qui se cachent derrière ses ennuis et comment une organisation peut les surmonter.
Scène 1 – la Partie prenante
Établir qu’il y ait un besoin business d’investir dans un projet est seulement le début de travail avec la partie prenante. Ils peuvent penser qu’ils savent de quoi ils ont besoin, ils pensent probablement qu’ils savent à quoi ressemble la solution, mais quoi qu’ils pensent savoir, ils doivent travailler avec l’équipe projet pour faire du projet un succès.
Ceci est où tant de projets s’engluent. Ils supposent qu’ils peuvent définir et communiquer clairement leurs besoins à l’équipe projet via un document sur leurs perceptions de ce que fera le système: « un seau de « doit faire ceci » »! Ceci réussit rarement.
Cependant, établir une Vision commune et une relation de travail proche avec la partie prenante et leurs utilisateurs métier permettra au projet de commencer rapidement, de collaborer avec les parties prenantes pour identifier des besoins critiques et de travailler pour livrer rapidement un retour sur investissement pour le business.
Sans cette collaboration, les « doit faire ceci » tourneront rapidement en suppositions, les spécifications en spéculations et nous aurons une forte probabilité que tout effort investi ne livrera pas ce que la partie prenante considère vraiment nécessaire.
Scène 2 – Approvisionnement
L’établissement d’un besoin business et avoir des parties prenantes désirant s’engager sur le projet est un bon début, mais ceci nous amène typiquement au besoin de compléter des procédures de financement, que ce soit à travers des équipes d’acheteurs externes, ou des PMOs internes.
Ces équipes veulent savoir ce qu’elles financent et ce qu’elles obtiendront pour leur argent.
Malheureusement, ils fonctionnent typiquement sur des suppositions simplistes telles que le business connait tous les détails de ce dont ils ont vraiment besoin à l’avance et que les besoins business ne changeront pas pendant la vie du projet.
Faire évoluer leur mentalité vers un engagement sur seulement de petits investissements et observer les retours sur investissement avant d’investir de nouveau peut sembler facile. Mais, quand les organisations n’ont jamais expérimenté d’un rapide ROI auparavant, elles s’attendent à ce que chaque projet traîne dans le temps et livre tard des résultats décevants.
Les gens des approvisionnements/achats doivent être courageux et poser quelques questions difficiles aux projets à livrer :
- Et si nous avions à couper le financement au milieu du projet ?
- Pouvons-nous confirmer de premiers revenus business qui financeront le reste du projet ?
- Pouvons-nous financer progressivement votre projet sur la base de résultats démontrés ?
Notre chef de projet Agile serait heureux de répondre à ces questions.
Scène 3 – Gouvernance et conformité
Il y a de bonnes raisons pour lesquelles les organisations ont fondé cette gouvernance et ces équipes de conformité. Les règles de conformité réglementaire de l’industrie doivent être respectées et bien des organisations se sont brulées les doigts avec des projets, typiquement avec la méthode dite « en cascade », aussi, des filets de sécurité ont été exigés pour protéger le business de projets dévoyés et dangereux.
Cependant, ces règles de gouvernance peuvent aussi empêcher le projet d’utiliser des pratiques fructueuses et de mettre en application certaines des pratiques que les règles de gouvernance essayent d’éviter!
Des améliorations progressives du succès de livraison peuvent être réalisées en mettant en application des mesures draconiennes sur les projets. Mais faire une évolution radicale dans le succès des projets exige un changement plus significatif : une livraison progressive et agile.
Comprenez-nous bien, il n’y a rien de mal à poser des questions au projet comme :
- « pouvez-vous prouver que vous comprenez nos besoins ? »
- « pouvez-vous démontrer que vous avez une solution saine qui répondra à ces besoins ? »
- « comprenez-vous les risques impliqués et pouvez-vous montrer comment vous les surmonterez ? »
- « pouvez-vous démontrer que votre solution respecte les attentes des parties prenantes ? »
- etc.
Cependant, le plus souvent, l’équipe de gouvernance a demandé sur ce sujet de la documentation pour supporter les réponses à ces questions par opposition à la preuve, à l’évidence concrète que l’équipe délivre ces résultats.
Revenir sur l’objectif du « point de contrôle » permettra typiquement à une équipe agile d’établir quelles mesures de progrès elle doit présenter pour fournir de meilleures mesures du réel progrès qu’une preuve écrite typique ne pourra jamais fournir.
Scène 4 – Architecture d’entreprise
Il y a beaucoup de valeur dont n’importe quel projet peut tirer profit à travailler avec l’Architecture d’Entreprise (EA) : Compréhension des technologies stratégiques de l’organisation; Établissement des besoins non-fonctionnels et techniques du projet; Alignement sur les autres systèmes de l’entreprise; Retours sur la vision technique du projet; pour en citer seulement quelques-uns.
Cependant, l’EA ne devrait pas chercher à définir le détail de la solution que l’équipe doit déterminer et livrer. Elle devrait ressembler à une partie prenante; aider à définir des besoins, à valider la valeur business et collaborer régulièrement avec l’équipe.
De cette façon, l’EA fournit une source de valeur de gouvernance technique stratégique et d’alignement sur la stratégie d’affaires.
Livrer un gros design d’entrée de jeu mène seulement à la spéculation et à la preuve par la documentation qu’une solution technique fonctionnera. Il vaut mieux démontrer une architecture exécutable et les équipes EA seront d’accord quand elles commencent à se rendre compte qu’il est possible de travailler de cette façon.
Scène 5 – équipe de développement
Non, tout sur le projet ne sera pas techniquement facile. Beaucoup de choses demandées à l’équipe projet seront nouvelles pour elle. Les développeurs auront des expériences différentes et la meilleure manière de surmonter les défis pour l’équipe sera de les encourager à collaborer.
Malheureusement beaucoup de membres d’équipes de développement ont eu des carrières où ils ont été encouragés à agir comme des héros. Ils ont été mesurés par leur performance individuelle et non par le succès de leur équipe projet.
Quand la livraison régulière de réussite démontrable devient importante, l’équipe a besoin à reconnaître ceci et chaque fois que des défis techniques surgissent, de travailler collaborativement pour trouver une solution. Ceci sera d’autant plus efficace que cela permettra de construire un sentiment d’équipe.
Le « Pairing » est une approche pour réaliser ceci, mais ce n’est pas exigé tout le temps, seulement quand quelqu’un sur l’équipe éprouve une difficulté et demande de l’aide. Alors un membre de l’équipe offrira son aide, aussi longtemps que durera le défi.
Scène 6 – Déploiement
Il n’est pas étonnant que les équipes de déploiement considèrent les équipes de développement avec prudence. Ils ont si souvent été en réception de solutions exécutables qui ont été précipitées dans le déploiement, mal évaluées, et pas conçues pour supporter efficacement un environnement de production. Cependant, si elles sont traitées comme une autre partie prenante du projet, on peut facilement répondre à leurs besoins et ainsi apaiser leurs craintes.
On s’attend aussi à ce qu’ils protègent le business et quand les projets ont rarement répondu aux attentes, ils se méfient beaucoup des nouvelles solutions qui sont fréquemment livrées et s’attendent à un déploiement fréquent. L’engagement régulier de l’équipe de déploiement dans le projet, leur permettre de voir les tests de pré-déploiement réussis et leur démontrer un plan de déploiement qui marche, aidera l’équipe à gagner leur confiance pour prévoir les déploiements fréquents de l’équipe Agile.
Scène 7 – Acceptation de la Partie Prenante
Au moment où l’équipe projet Agile est prête à déployer une solution qui ajoute de la valeur au business, il ne devrait y avoir aucune surprise pour le business sur ce qui va arriver. Leur participation continue en tant que membres de l’équipe projet et/ou leur présence aux démonstrations régulières, devraient leur fournir de suffisantes opportunités de s’assurer que le projet livre ce dont ils ont besoin, même si leur besoin a changé ou s’ils étaient incertains de ce qu’ils voulaient avant de l’avoir vu pour la première fois.
Cependant, même dans le scénario catastrophe où les parties prenantes voient seulement la solution à l’instant où une première solution de base pourrait être déployée, ils peuvent tout de même changer le cours du projet beaucoup plus tôt que ce ne serait possible avec un cycle de vie plus traditionnel.
Épilogue
Notre courageux chef de projet, Luke, a vraiment réussi à faire adopter son projet Agile par l’organisation, et même si ce fut un voyage pénible, ça en valait la peine. Le client a vraiment reçu de la valeur très tôt et Luke a établi un précédent avec beaucoup d’autres fonctions de l’organisation.
Au fil du temps il trouvera que le reste de l’organisation commence à reconnaître la valeur de l’approche Agile et des barrières tomberont ou seront ajustées pour apprécier la livraison de valeur au plus tôt.
Cependant, ce processus prendra du temps et cela nécessitera plus que les seuls efforts de Luke pour réaliser ce changement.
ne manquez pas de lire le livre blanc Agile en français réalisé par APMG-International France
lisez en ligne et/ou téléchargez le Livre Blanc Agile
Après la préface en langue anglaise de Richard Pharro, PDG de APMG-International, vous y découvrirez un positionnement des méthodes Agiles (schéma ci-dessous) et comment les combiner au mieux pour en tirer le maximum d’efficacité.
Merci pour ce bel effort Lenny.
LoL Scrum-Master en cette journée du rire :-))
Bonjour, je pense que cette vidéo humoristique sur Scrum et plus particulièrement sur le rôle de ScrumMaster vous fera sourire.
Bien que traités sous un angle amusant, les problèmes abordés sont ceux rencontrés par bien des équipes Agile.
- Membre de l’équipe systématiquement en retard au Daily Stand-Up
- « Scope Creep » avec des utilisateurs qui ne respectent pas le rôle du Product Owner
- Quand « Done » est-il réellement « Done »?
- …
Postez vos commentaires après avoir essayé ces techniques vigoureuses.
Méthodes Agile par Frédéric Marchal de CSP Formations
On associe très souvent méthodes Agile et projets informatiques. Si l’on regarde les conditions de réussite de ces méthodes, on se rend assez vite compte qu’elles peuvent être utilisées de façon universelle.
De même ce n’est pas parce que les méthodes agiles sont très efficaces en développement informatique, qu’il faut rejeter en bloc les méthodes dites « classiques ». Les méthodes agiles sont des outils de la « boite à outils » de gestion de projet, il faut connaître les méthodes classiques (cascade (70’s), V, W, spirale (90’s)) pour bien utiliser « l’Agile ».
Quels sont les contextes propices à la mise en place de méthodes Agile ?
Quels critères « d’éligibilité » pour un projet pour être traité en « agile » ?
- Besoin d’une aide à l’expression des besoins ?
- Besoin d’une aide à l’acceptation du changement ?
Si ces critères sont présents, les méthodes agiles seront pertinentes.
Le courage est une valeur que doit posséder :
- le chef de projet agile qui va s’exposer en continu, qui va devoir faire des choix
- le client qui donne un « chèque en blanc » au Chef de projet.
Qu’est ce qui différencie les méthodes agile des autres méthodes ?
La position du Client : au centre de l’équipe
Les besoins du Client c’est comme une « liste de mariage », on a un budget, il y a des choses qu’on gardera, des choses qu’on changera peut être….- « Dis-moi quel délai et quel budget tu as, je te dirais ce que je peux faire »
- Le client est « encapsulé » dans l’équipe et on ne parle plus de contrat, on bannit la notion MOA/MOE.
- Agile évite l’effet tunnel avec un feed back aux utilisateurs réguliers (ce qui entretient leur motivation)
L’équipe :
L’agilité ne marche qu’en petit groupe autonome, les équipes autonomes voire autogérées.- Un bon chef de projet Agile (qui cumule souvent avec le rôle d’équipier) s’efface petit à petit au cours du projet par un bon transfert aux équipes.
- L’agilité fait confiance à l’humain, il y a peu de règles (parfois même pas de chef de projet , pas de manager)
- La posture des équipiers agile : « Comment puis-je t’aider ? »
Quelles sont les conditions de réussite des équipes agile?
L’agilité est empirique, ce n’est pas inné, ca s’apprend et donc il faut former les équipes: à faire des choix, à faire confiance, …..- Faire simple : L’outil privilégié des méthodes agile = le post-it pour partager et excel (équipiers réunis sur un seul lieu), si équipe à distance, on est obligé d’utiliser des outils collaboratifs pour compenser (sharepoint…). MS project ne sert qu’à faire du reporting.
- Une communication en face à face et tous les métiers se mélangent (on a besoin d’être ensemble), par exemple des « stand up meeting » quotidiennes.
- Faire la guerre aux mails, c’est difficile avec des équipes à distance/multi-sites mais dans ce cas chacune doit être autonome, responsable et doit réaliser ses propres livrables pour que ça marche.
- Les stakeholders ont en permanence, la vision de l’avancement du projet.
- Rythme durable : on ne s’épuise pas si on veut tenir la distance.
- Pilotage par les enjeux et par les risques en continu
- Peu d’indicateurs : le meilleur c’est le « Waouh » de l’utilisateur, mais être ferme sur le reporting
- Réajustement en permanence (nécessite transparence, confiance et absence de sanctions)
- Célébration des victoires rapides
En conclusion :
On parle de « méthode » Agile, mais il s’agit surtout de relations humaines plus que de méthodes. Que ce soit la position du Client, la confiance donnée aux équipiers, l’implication des parties prenantes, ce qui fait que ces méthodes marchent c’est une prise en compte différente des individus et de leurs besoins.
Frédéric Marchal, CSP Formations, Consultant qualité Certifié PMP et IPMA
Pour en savoir plus sur ce sujet, consultez la page CSP Manager les projets avec agilité
Le Scrum Primer : Guide Léger de la Théorie et de la Pratique de Scrum
Il y a beaucoup de descriptions concises de Scrum disponibles en ligne, et cet ouvrage d’initiation a pour objectif de fournir un niveau additionnel de détail sur les pratiques. Il n’a pas pour objectif de constituer l’étape finale de l’apprentissage de Scrum; il est conseillé aux équipes souhaitant adopter Scrum de se doter de l’ouvrage de Ken Schwaber Agile Project Management with Scrum ou Agile Software Development with Scrum, et de profiter des excellentes possibilités de formation ou de coaching Scrum qui sont offertes; tous les détails sont disponibles sur http://scrumalliance.org
.
la force durable d’Agile Project Management par Jeff Ball
Agile est né en 2001 en réaction aux méthodes en cascade de gestion de projet. Le mode de gestion basé sur les seules planifications et spécifications affichait ses limites, les approches Agiles apportent donc de nouvelles réponses. Aujourd’hui, Agile est devenu populaire et de nombreuses organisations s’intéressent à son utilisation comme approche standard pour la gestion de projet. Elles ont besoin d’une force durable telle qu’Agile Project Management. Cela constitue un vrai défi puisqu’ Agile se posait comme un contre modèle aux méthodes business établies.
Le programme Agile de 2001 exprimait des préférences pour :
|
LCG |
|
LCD |
|
Personnes et Interactions |
Plutôt que |
Outils et Processus |
|
Logiciel qui fonctionne |
Plutôt que |
Documentation Exhaustive |
|
Collaboration avec le client |
Plutôt que |
Négociation Contractuelle |
|
Réactif aux changements |
Plutôt que |
Suivre un Plan |
Appelons donc ces préférences le LCG (la colonne gauche) et LCD (la colonne droite). Agile préfère le LCG au LCD.
Ces 10 dernières années, les préférences (LCG) ont permis à Agile de se développer sous diverses formes. De nombreuses équipes business ont adhéré avec enthousiasme aux versions légères d’Agile (comme SCRUM ou XP) fondées sur les préférences LCG.
Mais d’autres équipes business ressentent toujours un besoin fort ou une forte affinité pour le LCD (la colonne de droite)
· Les Processus et les Outils – les entreprises ont besoin de méthodes de travail bien définies, soutenues par des outils ;
· Une Documentation Complète – les équipes opérationnelles ont besoin de comprendre les livrables du projet ;
· Négociation de Contrat – l’approche « prix fixe, délai fixe » reste un concept business fondamental ;
· Suivre un Plan – les entreprises utilisent les plans pour gérer les dépendances de ressources comme de livraison.
Comment réconcilier le LCG et le LCD ? Une variante d’Agile, l’approche Atern du consortium DSDM réduit cet écart.
Comment Atern peut-il réduire l’écart tout en restant Agile?
Premièrement, Atern reste fidèle au programme en exécutant le LCD, les préférences fondamentales du Programme.
|
LCG |
Solution Atern |
|
Personnes et Interactions |
Equipe autogérée |
|
Logiciel qui fonctionne |
Livraison progressive |
|
Collaboration avec le Client |
Voix forte du client dans les équipes |
|
Répondre au Changement |
Approche itérative avec une prise de décision tardive |
Atern se compose de 9 principes fondamentaux qui servent eux aussi à réduire l’écart entre le LCG et le LCD.
De plus, 4 des principes d’Atern sont liés au programme (au LCG) :
1. Collaborer,
2. Construire progressivement,
3. Développer de manière itérative,
4. Communiquer continuellement et clairement.
Alors que les 5 autres principes d’Atern sont liés aux besoins de l’Entreprise (au LCD) :
1. Focalisation sur les besoins business,
2. Livrer dans les délais,
3. Ne jamais compromettre la qualité,
4. Construire des fondations solides,
5. Faire preuve de contrôle.
Pour créer une variante durable et forte d’Agile, Atern se fixe alors sur les impératifs du business – dans les délais et les contraintes de budget :
· Une solution avec une architecture (Atern appelle ceci EDUF = Enough Design Up Front (suffisamment de conception en aval) ;
· la Rentabilité ;
· Suffisamment de planning pour assurer le contrôle ;
· Une remise planifiée aux opérations.
Tout cela est basé sur les 9 principes, qui traitent donc du double besoin du LCG et du LCD.
Enfin, le paquet est emballé pour une utilisation générique :
· Atern est une approche générale (pas spécifique à l’informatique ou aux projets logiciel) ;
· La documentation d’Atern consiste en un manuel publiée (disponible sur Amazon, etc) ;
· la formation Atern est disponible internationalement, par des organismes de formation confirmés comme QRP International ;
· la certification d’Atern est assurée par les agences de certification confirmées comme l’APMG.
Donc dix ans après le programme Agile, Atern est ouvert aux entreprises. Il n’abandonne pas Agile, il épouse toujours l’essence du programme. Il s’est adapté aux besoins du business sans retourner aux méthodes en cascade. Atern est la véritable force durable d’Agile.
© Copyright QRP International 2013. Reproduction in full or part is prohibited without prior consent from QRP International.
Agile PM Certification by APMG International
Agile Project Management Certification
The Agile Project Management (AgilePM) certification aims to address the needs of those working in a project-focused environment who want to be Agile.
Based on the proven fundamentals within DSDM Atern, the certification provides the ability to deliver Agile Projects in organizations requiring standards, rigour and visibility around Project Management, while at the same time enabling the fast pace, change and empowerment provided by Agile.
Agile Project Management Training Courses – To book an Agile Project Management course and exam, contact any of APMG-International’s Accredited Training Organizations.
The course will:
- Explain how to lay the foundations for successful agile projects
- Explain how an agile project is managed
- Clarify the different management styles needed for successful agile projects (compared to « traditional » projects)
- Provide integration with PRINCE2®
Benefits for Individuals
- Develop a more advanced, applied level of knowledge to gain an understanding of agile and the ability to apply relevant project management methods, leading to successful agile projects.
- Clarify different management styles needed for successful agile projects compared to traditional projects and be able to tailor these to the situation.
- Actively promote trust and close co-operation between the business and developers and gives the business ongoing visibility into what is happening.
- Combine knowledge of more traditional management methodologies with agile to better adapt to a changing business environment.
- Improve time-to-market and project success rates while simultaneously accelerating results by encouraging stakeholder involvement, feedback and effective controls.
Benefits for Organizations
- Deliver change faster, at a lower cost and with lower risk by continually validating project milestones against business objectives.
- Complements and works with existing corporate processes such as PRINCE2®, quality and audit processes which improves rigour and visibility around project management, leading to a proven track record of successful delivery in a corporate environment.
- Simply adopt a tried and tested approach rather than developing and integrating a company-specific agile management process.
- Achieve better communication and control over projects and adapt project plans without disrupting the project budget, timescale and scope.
- Develop professionalism in employees and include agile certification in employee professional development schemes.
Foundation Level
The foundation AgilePM certification lives up to its name by providing the users of the method with the core principles needed to facilitate a successful project, while allowing a degree of scope and agility that not many other methodologies provide. With a clear, concise and detailed perspective on project productivity, the AgilePM certification is useful to all candidates and competency levels ranging from highly experienced project managers to those new to the industry.
Exam Format: Multiple choice, 60 questions per paper, 30 marks required to pass, 60 minutes,Closed-book.
Practitioner Level
The practitioner level empowers, encourages and equips you with an in-depth knowledge of not just the certification, but also how to apply and implement these principles into the life of a project manager on a daily basis. Pre-requisites accepted to be eligible to take the Practitioner examination:
- AgilePM Foundation Certificate, or
- DSDM Atern Foundation Certificate, or
- DSDM Advanced Practitioner Certificate.
The practitioner examination is in the « Objective Testing » format of scenario, question and answer booklet.
Exam Format: Objective-testing, 4 questions per paper, 15 marks available per question, 30 marks required to pass, Two hours, Open-book (restricted to the manual only) examination.
Réussir des « standup » efficaces autour du tableau Kanban
Effective Standups around Kanban Board
http://blog.brodzinski.com/2011/12/effective-standups.html par Pawel Brodzinski
Vous pouvez entendre ici et là que Kanban s’adapte plutôt bien aux grandes tailles. En réalité, un des problèmes de Scrum auquel je pense on ne s’est pas soigneusement attaqué, est que faire dans les projets qui nécessitent davantage de personnes qu’une unique équipe Scrum puisse rassembler. L’un des problèmes qui émerge très rapidement quand l’équipe Scrum grandit est la réunion « standup ».
Comme vous passez à travers l’équipe qui grossit avec vos trois questions standards cela nécessite naturellement de plus en plus de temps. Bientôt cela peut devenir un problème que de tenir dans le bref temps imparti pour de telles réunions.
Quand l’équipe adopte Kanban, elle commence d’habitude avec un standup inchangé. Cependant cela signifie que, à un certain point, ils font face au même problème que les équipes Scrum : 15 minutes ne sont désormais plus suffisantes.
Récemment, Jorn Hunskaar a partagé une telle histoire sur son blog. Il m’a incité à combiner une suite d’idées en une seule réponse qui peut servir de un guide sur comment améliorer les standups autour du tableau Kanban.
Au lieu d’exécuter le typique tour de table avec des réponses sur ce qui s’est produit hier, ce qui va être réalisé aujourd’hui et quels sont les problèmes, vous pouvez essayer de reconcevoir le modèle que vous suivez pour le standup.
comment améliorer les standups autour du tableau Kanban
D’abord, passez à travers tous les points bloquants (s’il y en a). Ceux-ci sont certainement vos points de douleur actuels. Cela signifie que vous voulez certainement investir une partie du précieux temps de standup sur ces points bloquants. Cela est évident.
- Deuxièmement, discutez des items urgents ou à expédier (de nouveau, s’il y en a). C’est le travail prioritaire du point de vue de l’équipe toute entière. C’est quelque chose que vous devez vraiment faire sous peine de retarder d’autres taches. De nouveau, ceci est une chose dans laquelle cela vaut la peine d’investir de rares ressources.
- Troisièmement, passez en revue les items qui n’ont pas progressé depuis le dernier standup. Ceux-ci sont les points qui peuvent être à risque. Peut-être ne devaient-ils pas progresser mais dans ce cas ce serait revu rapidement, peu de discussion nécessaire. Autrement, cela vaut la peine d’avoir une brève analyse ce qui a empêché ces points d’avancer. À propos, cela signifie que vous devriez avoir un mécanisme pour marquer visuellement les fiches qui ne se déplacent pas, ce qui est souvent délicat.
- Quatrièmement, passez à travers tout le reste. Encore un conseil : Vous pouvez avoir discuté les sujets selon leur classe de service par priorités. Autrement dit, vous commencez par la classe la plus hautement prioritaire de service (des bogues, des fonctionnalités critiques ou autre) et discutez tous les items de cette classe de service. Puis vous vous déplacez sur une autre. Bien, au moins cela peut fonctionner tant est que vous puissiez dire quelle classe de service est plus importante qu’une autre.
Encore une règle raisonnable : dans chacun de ces groupes, utilisez le tableau Kanban de la droite vers la gauche. Cela indique que plus un article est proche d’être fini plus vous voulez en discuter pour le compléter, apportant ainsi de la valeur à vos utilisateurs, clients et parties prenantes.
OK, jusqu’à ce point il y a en fait peu de différences : vous passez toujours en revue chaque item de travail qui est sur le tableau. Il y a un focus différent sur les problèmes et vous pouvez passer sur les items évidents de travail complété, mais tout de même, toujours beaucoup de contenu à revoir.
Cependant, étant donné que vous venez de trier les sujets à discuter selon leur priorité, vous pouvez utiliser un truc simple et stopper la discussion quand le temps de la réunion s’est écoulé, peu importe si vous avez pu ou pas couvrir toutes les choses. Cela signifie que vous avez probablement couvert tous les items des trois premiers groupes et certainement tous ceux des deux premiers, indépendamment du reste qui exige une moindre part de discussion ou aucune discussion du tout.
Cela signifie aussi que, dans un bon jour, vous pouvez couvrir tous les points, ou davantage de choses, et c’est parfait. Ce dont vous avez essentiellement besoin est de vous assurer que la substance la plus importante ne va pas passer inaperçue.
Un pas de plus serait de sauter une discussion sur un groupe ou sous-groupe spécifique d’items, comme par exemple une classe spécifique de service, quand vous voyez que cela n’ajoute pas vraiment de valeur. Si vous n’êtes pas certain, essayez de les couvrir pendant les standups et voyez quel résultat vous obtenez. Vous pourrez alors commencer à essayer d’autres choses avec l’agenda de la réunion.
Idéalement, après quelque temps, vous finirez par discuter seulement des choses importantes, disons, les points bloquants, les items à expédier et bloqués, et peut-être d’autres qui sont amenés par n’importe quel membre de l’équipe pour une raison importante et sortent du travail habituel qui n’a pas besoin de plus d’attention qu’une confirmation silencieuse que tout est parfaitement en ordre.
soyons WAGILE (W-aterfall + AGILE) : « une main de fer dans un gant de velours »
Christine Rieu et Marc Burlereaux ont présenté un article préparé avec Sylvain Gautier sur l’agilité au premier congrès international en Gestion de Projets de l’UQTR à Trois-Rivières
Christine RIEU, christine.rieu@univ-savoie.fr Maître de Conférences en Informatique, Laboratoire LISTIC, Université de Savoie, Annecy, Membre fondateurs du PMI Pôle des Pays de Savoie,
Marc BURLEREAUX, marc.burlereaux@pmi-fr.org, Release Manager Européen auprès d’une banque suisse, certifications PMP, PMI-RMP, PgMP, ITIL V3, Membre fondateurs du PMI Pôle des Pays de Savoie,
Sylvain GAUTIER, sylvain@sygit.ch Consultant Agile / ITIL / BPMN société SYGIT, Suisse
L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet (Pichler, 2010). 
Si on couple une approche Lean à ces méthodes Agiles, nous supprimons en plus toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit (Larman & Vodde, 2010). Cela semble donc être la panacée !
Vous pouvez accéder à leur présentation ici.
Mais ce n’est pas simple à réaliser et le chef de projet se posera de nombreuses questions :
Comment intégrer ces approches de manière réussie dans des contextes de gestion de projet mature qui sont plus traditionnels avec du développement logiciel en V ou en cascade ?
- Comment est orchestrée la livraison en production de ces produits développés avec agilité et approche Lean dans un processus de gestion des livraisons pour la mise en production qui lui apparaît souvent très rigide, et qui se doit de minimiser les risques liés au changement ?
- Comment ces livraisons s’intègrent-elles dans la gestion des versions (release management), et notamment les procédures de tests (unitaire, intégration et réception des applications), la production de la documentation technique d’exploitation, de la documentation destinée aux utilisateurs et enfin la création des procédures d’installation et de déploiement ?
- Comment éviter que ces méthodes soient un alibi à des comportements laxistes et inefficaces, par exemple en supprimant toute documentation?
La réussite de tels projets passe par un compromis d’usage entre l’agilité de l’approche globale de développement et la rigueur à conserver dans le processus de livraison. D’où le titre de notre communication: « une main de fer dans un gant de velours ».
Cette présentation s’appuie sur un retour d’expériences de projets combinant Agilité et Lean Management dans des domaines variés de l’industrie et de l’informatique bancaire. Nous expliquons notre vision des prérequis pour qu’un projet soit éligible aux méthodes Agiles. Le fil rouge de la présentation est ensuite d’illustrer nos expériences en mettant l’accent sur les meilleures pratiques Agile que nous avons identifiées comme point clés pour la pleine réussite de ces projets. Nous avons réparti ces points clés à travers les différentes phases de développement de projet, en insistant particulièrement sur les phases initiales de cadrage et d’élaboration, puis sur les phases finales de réception – homologation et transition vers la production.
L’anecdote suivante illustre bien que la rigidité n’est pas l’apanage des méthodes de gestion de projet traditionnelles
Jack Duggal, ayant une expérience de plus de 30 ans en gestion de projets, disait lors d’une conférence organisée par l’institution PMI (Project Management Institute), à Genève en 2012: « On peut parfois reprocher une certaine rigidité dans l’application de l’agilité. Lors d’un SCRUM meeting, qui suppose que vous soyez debout, notamment pour garantir une durée de réunion courte, une personne un peu fatiguée avait exprimé le besoin de s’asseoir: cela lui a été refusé, principe oblige. »
Quelle que soit la méthodologie choisie, elle doit pouvoir s’inspirer des avantages des autres méthodes existantes.
Citons l’exemple de l’institut PMI qui est l’autorité en matière de gestion de projets « traditionnelle » ; cet organisme s’est naturellement ouvert aux principes d’Agilité en créant récemment une nouvelle certification PMI-ACP (Agile Certification Practitioner) et en intégrant l’Agilité et le Lean Management dans la gestion de projet plus traditionnelle. Par exemple, le PMBOK 5ème édition qui est encore en cours de rédaction prend en compte les méthodes Agiles “Adaptive Life Cycles”, section 2.4.2.4: méthodes itératives et incrémentales avec des itérations courtes de 2 à 4 semaines et avec un temps et des ressources fixes.
Un aspect important à ajouter dans les méthodologies Agile est la gestion du risque: c’est un exemple de bonnes pratiques dérivant des méthodes traditionnelles qui doit être intégrée dans les approches agiles.
Nous terminons sur un rappel des quatre principes fondateurs du Manifeste pour le développement Agile de logiciels rédigé par Kent Beck et 16 autres signataires qui peuvent être suivis quelle que soit la méthodologie de management de projet employée.
« Ces expériences nous ont amenés à valoriser:
1. Les individus et leurs interactions plus que les processus et les outils,
2. Des logiciels opérationnels plus qu’une documentation exhaustive,
3. La collaboration avec les clients plus que la négociation contractuelle,
4. L’adaptation au changement plus que le suivi d’un plan.
Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers ».
La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement
Nous avons voulu dans cette présentation donner des conseils très pratiques pour dérouler les étapes d’un projet de façon Agile, en nous inspirant de nos expériences sur des contextes projets très variés. Mais nous insistons sur l’importance de comprendre qu’une démarche, quelle qu’elle soit, n’est pas la panacée, si on se contente de l’utiliser comme une « boîte à outils avec check-list intégrée ». La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement, qui mise sur l’engagement des employés et leur participation. Il faut savoir prendre dans chaque méthode ce qui est « bon pour l’entreprise », sachant que chaque entreprise est unique et a ses propres spécificités de fonctionnement qui en font sa richesse. Face aux méthodes traditionnelles, les méthodes Agiles sont une révolution, mais elles peuvent aussi apporter leur part de lourdeur et de contrainte, selon l’usage que l’on en fait.
L’Agilité c’est bien mais la contrôler c’est mieux …
– L’approche SCRUM n’est pas la panacée, notamment si elle n’est pas accompagnée par le Management et la Maîtrise d’Ouvrage (MOA)
– L’approche Lean de l’industrie ne peut être transposée dans tous les contextes
– L’esprit AGILE est avant tout le moteur qui garantira le succès, du Senior Management aux gens de terrain
– Il faut bien sélectionner les outils AGILES convenant le mieux à l’entreprise
– Un coaching pragmatique est un facteur clé de réussite
– Le dogmatisme doit être jeté aux oubliettes
– Et il faut contextualiser la démarche qui ne peut être standard pour tous les domaines (de l’industrie spatiale à Google, en passant par l’aéronautique, l’industrie automobile, le secteur bancaire…).
Et l’Agilité mal comprise et mal appliquée pourra causer encore plus de dommage que les méthodes traditionnelles.
Soyons WAGILE ! Contraction de WATERFALL (méthodes de développement traditionnelles) et AGILE … d’où Agilité une main de fer dans un gant de velours !
En bonus une petite vidéo « Agile: An Introduction »
équipes Agiles et géographiquement distribuées : résultats de recherche
Agile and Distributed Teams: research results
http://www.pm4girls.elizabeth-harrin.com/2012/04/agile-and-distributed-teams-research-results par Elizabeth Harrin 27/04/2012
Équipes Agiles Distribuées : Réalisation des bénéfices, de ProjectsAtWork, recherches écrites et réalisées par Elizabeth!
J’ai travaillé avec ProjectsAtWork cette année sur des recherches et une analyse des bonnes pratiques pour réussir Agile avec des équipes distribuées. Agile n’est pas la première approche à laquelle vous penseriez pour manager un projet avec des membres de l’équipe géographiquement distribués dans le monde entier, mais en réalité c’est une approche vraiment courante.
Pourquoi utilisez-vous Agile avec une équipe distribuée ?
Les gens utilisent Agile avec des équipes distribuées parce que cela revient moins cher. Cela donne aux équipes projet plus de flexibilité. Cela augmente la productivité. La recherche a regardé un certain nombre de bénéfices, en voici les 3 premiers.
Utiliser des ressources offshores est souvent avancé comme l’une des raisons pourquoi lesquelles les équipes distribuées rendent les projets plus flexibles. Mais certaines personnes questionnées ont dit qu’avoir des équipes distribuées signifie qu’elles pourraient choisir la meilleure personne pour le travail, pas seulement celle qui travaille dans le même bâtiment. Cela donne aux chefs de projet une chance de choisir depuis un plus grand réservoir de ressources et ainsi en augmenter la qualité.
L’inconvénient d’avoir des gens partout est que les équipes souffrent souvent des décalages horaires. Presque 25 % des personnes mentionnent des différences de temps de plus de 9 heures. Pas étonnant que la grande majorité d’entre eux dise que travailler avec une équipe distribuée est plus difficile que le travail avec une équipe co-localisée.
Comment faites-vous du travail Agile avec une équipe distribuée ?
Il y a des tas de trucs dans le rapport, mais voici 5 de mes favoris.
- Ne supposez pas que ce qui a marché sur un projet fonctionnera sur un autre. Adaptez votre environnement Agile pour convenir à chaque équipe. Encore mieux, laissez l’équipe l’adapter.
- Utilisez les mêmes outils que vos partenaires si vous « offshorez » ou externalisez un travail.
- N’externalisez pas des disciplines individuelles. Gardez une équipe multifonctionnelle dans tous les endroits.
- Faites un « daily stand up » quotidien en utilisant la conférence à plusieurs sur le Web.
- Communiquez plus que vous ne le pensez nécessaire, particulièrement pour vous assurer que les gens comprennent l’objectif, la finalité. Ceci est aussi important si vous avez de multiples langues dans votre l’équipe. Passez du temps à vous assurer que les gens comprennent ce qui a été discuté.
À quoi ressemble un professionnel Agile?
Une des choses que j’ai faites dans cette recherche est de rassembler le profil d’un professionnel Agiliste expérimenté, basé sur l’enquête auprès d’environ 340 personnes.
Un Professionnel Expérimenté Agile:
- Est âgé de 35 à 44 ans
- Est un homme
- Utilise Scrum
- A travaillé sur plus de 10 projets, mais la plupart d’entre eux n’ont pas été avec des équipes distribuées
- Travaille dans l’informatique
- Travaille dans les plus grandes comme les plus petites sociétés
- Se considère comme un praticien Agile, mais n’a pas de qualification reconnue
- Croit que le plus grand défi pour des équipes distribuées est la faiblesse de communication
- Travaille dans une société où moins de 20 % des chefs de projet sont des chefs de projet Agiles.
Je pensais que plus de répondants seraient des femmes, mais il ne semble pas y avoir beaucoup de professionnels expérimentés Agiles qui soient des femmes. Sauriez-vous pourquoi ?
lisez tout le rapport
Vous pouvez obtenir votre propre copie gratuite du rapport Agile Distributed Teams: Achieving the Benefits
vos clients sont-ils prêts pour Agile ?
Are Customers Ready for Agile?
http://www.scrumalliance.org/articles/403-are-customers-ready-for-agile par Shweta Darbha
La méthodologie « waterfall » a été présente depuis si longtemps que les organisations de développement logiciel qui la pratiquent – et leurs clients – sont complètement en accord avec le processus. Récemment notre gourou résidant Agile l’a indiqué en commentant qu’avec Agile, clients ou propriétaires de produit (« product owners ») ne peuvent pas décharger leurs pensées sur l’engineering. Autrement dit, ils ne peuvent pas donner à l’ingénierie d’un seul coup tous leurs besoins au démarrage, parce que Agile demande une constante collaboration dans laquelle les besoins sont alignés à la fois sur l’équipe et sur le business.
Cela m’a sonné à réfléchir : Intérieurement, dans une organisation de développement de produits qui utilise Agile, coûte que coûte les propriétaires de produit doivent s’aligner. Ils apprendront le concept d’arriéré de produit et de besoins qui s’empilent; ils accepteront les tâches que les experts Agile attendent d’eux. Cependant, dans une organisation pilotée par les projet où les clients sont les gardiens du besoin, est-ce que ces clients sont prêts pour Agile ?
Je me rappelle de plusieurs occasions pendant mes missions de conseil où trois à quatre mois ont été dédiés « à la découverte » des processus clients, l’esquisse des besoins, l’obtention de la signature d’un document de contenu de projet. Le tout avant que nous ne puissions commencer le projet. Les calculs d’allocation de ressources et d’échéanciers, étaient basés sur ces « besoins ». C’est que la communauté informatique communauté a appris à ses clients sur quoi attendre d’un projet.
Aujourd’hui, comme la communauté IT adopte et s’adapte aux pratiques Agile, en faisons-nous assez pour instruire et informer notre écosystème – nos clients ?
Ce qui suit sont mes opinions sur certains des processus ou des engagements auxquels ces clients ont besoin de s’adapter dans le monde Agile.
Vider son esprit par rapport à construire les besoins de manière itérative
Dans la méthodologie « waterfall » les besoins sont le début des projets, avec des clients les exposant et des consultants les documentant. Les besoins n’étaient jamais revisités de nouveau avec le client, puisque le client les avait déjà formellement signés. Les projets commençaient seulement après que la collecte de besoins soit finie.
Dans Agile, cependant, les besoins, depuis le début même, peuvent être définis comme des « épopées » et doivent régulièrement être décomposées en histoires. À chaque planification de sprint, toutes les parties prenantes (incluant le client) conviennent d’histoires (autrement dit de fonctionnalités et de besoins) qui doivent être développées et testées dans le prochain sprint. Cela devrait être utilisé comme un facteur « WOW » par l’équipe projet, pour aider des clients à comprendre qu’ils peuvent être complètement en accord avec ce qui est développé et ils peuvent aussi prioriser les fonctionnalités selon leurs besoins business.
Cependant, là se trouvent les défis :
- Participation : les Clients doivent s’engager sur la démonstration et la planification de sprint. Si éviter celles-ci est la norme et les propriétaires de produit deviennent régulièrement des mandataires pour le client, les bénéfices d’Agile ne peuvent jamais être expérimentés ni implémentés.
- Alignement des équipes : le fonctionnel, le développement et des équipes QA doivent sortir de leurs mentalités « waterfall » et travailler vraiment en tandem dans chaque sprint, recherchant des démonstrations de sprint réussies sans balayer les problèmes sous le tapis.
Les estimations du management par rapport aux évaluations de point d’histoire d’équipe Scrum
En « waterfall », des échéanciers de projet partent du « go ». On s’attend à quelques semaines de collecte des besoins pour permettre au projet et aux managers de dessiner un parfait plan de projet, avec allocation des ressources, test d’acceptation utilisateur et date de livraison bien définie. Un chef de projet méritant son salaire intégrera toujours une marge de 20 à 30 pour cent.
Agile tourne ce processus sur sa tête. Il implique que l’équipe de Scrum (pas le management) devrait calculer les point d’histoire (« Story Points ») et s’engager à atteindre ces points d’histoire en fonction de la vélocité de l’équipe.
Ici, les défis sont :
- Planification de projet : je crois qu’un échéancier est le plus grand défi du projet. L’idée de toujours avoir une date finale de projet (qui, selon diverses études, n’est pas respectée dans 80% des cas en « Waterfall ») sont si innés dans les organisations IT et chez leurs clients qu’atteindre la date finale possible de projet basée sur des points d’histoire va demander beaucoup de désapprentissage avant que cela ne puisse arriver.
- Évaluations récurrentes : les propriétaires de produit, ainsi que les clients, doivent participer à la planification de Sprint en aidant ‘équipe, à nettoyer et calculer les points d’histoire de l’arriéré de produit. Ils peuvent alors voir ce qui peut être accompli dans le sprint à venir et ce quels sont les reliquats du sprint précédent.
- Vélocité d’équipe : la méthodologie Agile implique que l’équipe soit assez mâture pour connaître sa vélocité, a suffisamment d’expérience pour estimer les besoins et a assez d’autorité pour s’engager sur les échéances.
Fin de développement par rapport à démonstration de sprint
Les démonstrations de sprint exigent que l’équipe Scrum ait un morceau de code qui marche, digne d’être montré, mais elles exigent aussi l’engagement de la partie prenante clé : le client.
Les défis de cette approche :
- Revue constante : si l’ingénierie et l’assurance qualité (QA) doivent s’adapter à des cycles de trois à quatre semaines pour créer un morceau de code fonctionnel et digne d’être montré, le client et le propriétaire de produit doivent aussi s’adapter au processus de constante revue. Le succès ou l’échec d’une histoire ramènent finalement à combien l’équipe Scrum a bien compris l’histoire, appelant ainsi à une revue de l’histoire elle-même. Fini sont les jours « Mais je pensais que vous aviez compris ce que je vous avais alors dit ». Si la planification de sprint et même les réunions « stad up » quotidiennes ont abouti à un écart de communication, l’équipe entière doit revisiter beaucoup de terrain, les besoins n’en étant qu’une partie.
Les projets au temps passé et dépenses contre coût fixe
La méthode « waterfall » permet aux organisations de négocier des contrats comme des offres à coût fixe ou bien en fonction du temps passé et des dépenses en matériel. Le type d’offre est dirigé par les offres des concurrents, la longueur possible du projet et le budget et la force de négociation du client.
Cependant, dans le monde Agile, cela n’aurait pas de sens d’avoir des contrats de type temps + coûts en matériels.
Voici Pourquoi:
- Des pratiques de sprint itératives donnent à toutes les parties prenantes la capacité d’arrêter le projet après n’importe quel sprint. (Assomption : à la fin de n’importe quel sprint, l’équipe a un code qui marche.)
- La planification de sprint permet à toutes les parties prenantes d’avoir accès et d’analyser ce qui peut être réalisé dans des sprints futurs en fonction de la vitesse de l’équipe.
- Le soin porté à l’arriéré de produit permet aux besoins d’être alignés sur les besoins business avant chaque sprint, ce qui permet aux clients de prioriser selon ses objectifs business. Par exemple, donner à l’intégration du site Web à PayPal pour les achats en lige la priorité sur un tableau de bord pour les partenaires, atteignant ainsi une présence en ligne avant que la campagne publicitaire « achetez en ligne » ne devienne virale.
Voici quelques-uns des aspects d’Agile auxquels je crois que les organisations doivent s’adapter. Mais un point important est que les clients doivent aussi changer la façon dont ils engagent dans un Monde Agile.
Voici une petite vidéo de Vincent McGevna sur comment « Agiliser » l’approche « Waterfall ».
les présentations du Scrum Day 2012 sont accessibles en ligne
Le 27 mars 2012 a eu lieu le Scrum Day 2012, l’événement annuel organisé par le French Scrum User Group et rendez-vous incontournable pour tous les acteurs de l’Agilité. Il s’agit d’un rassemblement majeur pour la communauté SCRUM : il permet de réunir chaque année sur une journée un grand nombre de membres, ainsi que les personnes impliquées dans l’Agilité en général. Résolument interactif, l’événement revêt différents formats, comme des keynotes, des conférences, des ateliers, des open spaces et des retours d’expériences… retrouvez en suivant le lien ci-dessous les présentations de la journée 2012.
Vous apprécierez par exemple certainement le retour d’expérience de Pierre Neis sur les User Stories:
Cette session reprend un retour d’expérience sur la collecte des user stories sur un programme d’envergure impliquant un grand nombre de participants, un grand nombre de personæ.
Comment procéder ? qui impliquer ? à quelle cadence ?
Grâce à l’aide des équipes d’ergonomes, de Product Owners et de Business Analysts, nous avons testé une approche agile de la collecte des besoins.
Ce retour d’expérience mis l’accent sur:
– le rôle et les actions des ergonomes
– les Business Analysts et les Product Owners
– l’utilisation dynamique de Serious Games pour animer un benchmark de plus de 50 participants
– les forces et les faiblesses de cette approche
– les leçons apprises
le rapport « Distributed Agile Teams : Achieving the benefits » de Projects at Work
Je vous propose de lire le rapport « Distributed Agile Teams : Achieving the benefits » de Projects at Work.
On y trouve entre autre la table ci-dessous, ainsi que :
- une définition, « Une équipe distribuée est une équipe où le chef de projet, le product owner , les développeurs, les testeurs et les utilisateurs ou tout autre membre de l’équipe, consultants et vendeurs externes, travaillent sur plus d’un emplacement. »
- Et des statistiques intéressantes:
- 20% des projets Agile sont distribués sur 2 ou 3 emplacements géographiques
- seulement 20% des projets sont conduits sous méthode Agile.
DantotsuPM.com 