les articles les plus lus sur DantotsuPM de Juin 2017
Ce mois-ci les billets appréciés des suiveurs du blog et autres visiteurs furent ceux liés à l’agilité, aux soft skills et à la qualité. Bonne relecture ou découverte !
Les personnes non intuitives et de nombreux professionnels techniques disent que maitriser les aspects pas si évidents des interactions avec les personnes (« soft skills » ou compétences relationnelles) est un grand défi et souvent prise de tête.
certaines relations peuvent être particulièrement frustrantes !
Quelles vérités sur les compétences ces personnes doivent-elles apprendre et utiliser ?
L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.
Cet art s’est inspiré de la pratique et de la philosophie de l’aïkido martial, et permet de diriger une agression verbale vers un résultat positif et équilibré. Comme dans l’art martial, l’assaillant et le défenseur sont dits « partenaires » et non « adversaires ». Il n’y a donc pas à proprement parler d’affrontement, ni vainqueur ni vaincu.
PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.
La qualité est mal comprise par trop de personnes qui n’y pensent que quand ils touchent au produit final. En réalité, c’est seulement au travers de processus de qualité centrés sur l’efficacité, l’innovation et l’amélioration continue qu’un produit de qualité est réalisé, et ces processus exigent une culture de management de qualité non seulement dans nos projets, mais aussi dans nos organisations.
Dans le chapitre 2 de son livre de 1986, « Out of the Crisis« , Edward Deming a présenté 14 prinipes dont il pense qu’ils peuvent rendre l’industrie plus compétitive grâce à un accroissement de la qualité.
Une transmission de projet réussie exige bien plus que de remettre les clés et les informations de connexion au nouveau chef de projet. Un chef de projet devrait suivre ces six étapes pour compléter avec succès la transmission de son projet.
Cet article, au départ écrit pour des entrepreneurs, recèle quelques conseils tout aussi utiles pour les chefs de projet.
Le livre sur Amazon
En effet, nous sommes souvent confrontés à la nécessité de « vendre » notre projet aux membres de nos équipes, à nos diverses parties prenantes et au management. En particulier lors de la justification et du lancement du projet mais également lors de changements organisationnels, à l’arrivée de nouvelles parties prenantes, pour accueillir de nouveaux clients…
En échange de tous ces avantages, vous avez moins de prévisibilité car le logiciel et les personnes restent complexes. Vous ne pouvez plus blâmer quelqu’un d’autre si les choses ne se passent pas bien et cela exige généralement beaucoup plus d’engagement et d’efforts de chaque personne impliquée – c’est-à-dire que la collaboration est encore plus importante.
Néanmoins, les bénéfices du développement Agile sont vraiment irrésistibles.
de nombreux jeunes chefs de projet interrogent leurs ainés plus expérimentés et leaders de PMO sur comment améliorer leurs compétences en management de projet.
Les initiateurs, experts et formateurs sur la méthode Scrum et surtout sur les attitudes Agile y partagent leurs expériences.
En sus de ces webcasts, le site Scrum.org vous permet de visionner des vidéos et lire des papiers d’étude et articles de blog sur l’agilité et plus spécifiquement sur Scrum.
Je fais une réelle différence, non seulement pour mon organisation, mais pour toute l’économie. J’aide à aplanir les hiérarchies et à donner aux clients ce qu’ils veulent vraiment !
Agile serait-il devenu un club fermé, réservé à ses membres ?
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Pensez-vous avoir à maitriser une horde de chevaux sauvages au lieu de mener une réunion quand les membres de votre équipe ne parviennent pas à tomber d’accord ? Eh bien, si cela peut vous réconforter, sachez que ce problème est le lot de la plupart des facilitateurs de réunions à un moment ou un autre.
Beaucoup d’attention est portée sur le « Manifeste Agile » et bien qu’il soit une composante importante de Agile, il n’en est pas toute la substance. Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste. Jetons un rapide coup d’œil à chacun d’entre eux et voyons combien ils affectent les pratiques Agiles et comment nous percevons et implémentons l’agilité…
Bien sûr, lire ses SMS ou emails professionnels en arrivant à la maison après une mauvaise journée est fortement déconseillé, droit à la déconnexion oblige !
OK, ils ne marcheront peut-être pas toujours mais je pense que ces conseils de John Baldoni, très simples et faciles à mettre œuvre, peuvent avoir un effet positif et re-booster votre moral avant de reprendre le chemin de la maison.
Partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Récemment, j’ai beaucoup réfléchi à comment augmenter l’agilité personnelle. Non, je ne parle d’exécuter des sauts périlleux ou autres folles poses de yoga. Je parle de la capacité à me concentrer sur la valeur et à être adaptable dans ce que je fais chaque jour. L’agilité telle que mentionnée dans les valeurs et principes du Manifeste pour le Développement Logiciel Agile. Quand le manifeste a été répondu en 2001, il y avait des représentants de Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming et autres. Aussi, quand je dis Agile, je ne veux pas nécessairement dire Scrum.
Scrum de Un ?
Scrum de un ?
Dans ce billet, je veux mettre le focus sur les personnes et pas les organisations. Étant un coach Agile et un consultant, j’ai appris beaucoup de stratégies qui m’ont aidé à manager des clients. En travaillant avec de grandes organisations complexes, j’ai vu des améliorations de productivité au niveau organisationnel en appliquant Lean et Kanban et au niveau de l’équipe avec Scrum et Kanban. Mais qu’en est-il de toutes les personnes qui travaillent pour ces organisations ou dans ces équipes Scrum ? Qu’en est-il des gens qui n’ont aucune idée de ce qu’est Scrum et ne s’en soucient pas ? Comment peuvent-ils améliorer leur productivité ?
Dans le billet Lifehack « Scrum for One« , Dustin Wax décrit combien des éléments de Scrum pourraient être adaptés à la productivité individuelle. En lisant l’article, je n’ai pas acheté l’idée. Scrum est une approche géniale pour des équipes mais c’est comme vouloir faire passer une pièce ronde dans un trou carré que de vouloir utiliser Scrum pour votre productivité quotidienne.
Dans Scrum, vous démontrez la valeur à votre client toutes les 2 à 4 semaines dans le cadre d’un sprint. Cela a-t-il du sens pour manager votre travail personnel ? Non.
Dans Scrum, vous avez les 3 rôles : ScrumMaster, Propriétaire de Produit et Équipe. À moins que vous n’ayez une double personnalité, il n’y a que vous !
La plupart des choses auxquelles je pense pour atteindre mes objectifs : l’alignement des activités sur les livrables, la décomposition du travail en morceaux exécutables, réitérer sur ce qui est créé pour pouvoir l’améliorer au fil du temps… la liste est longue.
Et ces composants ne sont pas des éléments exclusifs de Scrum. Alors, pourquoi vous limiter à Scrum ?
Manifeste d’Agilité Personnelle
Je crois que la productivité personnelle doit être repensée.
La productivité personnelle est-elle d’être tout le temps occupé ou de réaliser des choses ?
Pour être productif, cela signifie que vous devez produire. Sinon, vous êtes actifs. Il y a une différence! Pour aider à structurer mes pensées, j’ai écrit un Manifeste d’agilité personnelle.
Vous remarquerez que c’est proche du Manifeste Agile. Mais, il y a des différences clés.
D’abord, (tous) les résultats obtenus sont des mesures primaires de progrès. Ceci n’est pas du tout le cas pour le développement logiciel.
Deuxièmement, je me suis concentré sur des minutes, heures et jours pour réaliser des choses. Les équipes continueront à se concentrer sur des jours, semaines et mois pour obtenir le travail escompté et le livrer.
Je cherche à produire quelque chose que tout un chacun puisse utiliser. Quand vous entendez « Agile » c’est en réalité un groupe de niche de personnes concernées. Mais, quand vous parlez de productivité personnelle, la taille de l’audience explose. Comme avec Agile, je ne pense pas qu’il y ait une unique et meilleure voie. Alors, je regarde pour expérimenter et continue d’essayer pour améliorer.
Comme j’écris sur Personnel Kanban depuis 2010, vous pourriez penser que je devrais avoir tout compris à ce jour. Eh bien non, ce n’est pas encore le cas…
Aussi, si vous avez des trucs et astuces, j’aimerais les entendre.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Personne n’est plus surpris que tant d’organisations explorent les méthodes Agile pour manager leur flux de travail. Kanban est l’une des méthodes Agile. Une fois comprise, adoptée et déployée avec succès, elle apporte des bénéfices très significatifs à la gestion de votre équipe et du flux de tâches à réaliser par celle-ci.
Le principe de Kanban est de manager et décroître le nombre de goulets d’étranglement qui peuvent entraver la progression de toute l’équipe. C’est un choix bénéfique pour les équipes qui délivrent souvent et pour les équipes de développement en général. C’est une méthode de management très visuelle et participative qui tourne généralement autour d’un tableau blanc, des post-it colorés et des marqueurs. Travailler ainsi permet à toute l’équipe de voir la progression de l’ensemble des tâches en cours. Les zones sujettes à futur problème deviennent visibles à l’avance.
« Gross ignorance is 144 times worse than ordinary ignorance » – Bennett Cerf
Par exemple, les numéros 100 à 105 se réfèrent à Scrum
Scrum: A huddle of team members who have assembled temporarily in order to collaborate and solve a problem, or to otherwise reach a joint agreement (e.g. a Daily Scrum). The Scrum Framework is an agile development approach based on this technique, and which is used for building complex products.
Scrum Board: An information radiator which shows the progress of a team’s work as it is drawn, actioned, and completed from their Sprint Backlog. A Scrum board may show user stories and/or planned tasks, or both, or some other meaningful representation of the team’s work.
Scrum Master: The servant-leader for a Scrum Team, who removes impediments to their work, facilitates their progress towards the Sprint Goal, and coaches them and the wider organisation in the best use of the Scrum Framework.
Scrum of Scrums: A Scrum held between multiple Scrum Teams or their representatives, often for the purpose of ensuring that mutual dependencies are resolved and that product integration is not impeded.
Scrum Team: A self-organising team of professionals, consisting of a Scrum Master, Product Owner, and a Development Team, who deliver increments of value every Sprint and who inspect and adapt their progress.
Scrum Values: The characteristics which Scrum Team members seek to internalise and demonstrate as a cultural norm, including Commitment, Focus, Respect, Openness, and Courage. See also: prime directive.
L’agilité au niveau des équipes de développement a fait ses preuves depuis des années maintenant principalement grâce à SCRUM et XP .
Aujourd’hui, alors qu’elles montent en maturité, les entreprises qui développent leur SI de façon agile sont confrontées à un double plafond qui limite leur capacité à démultiplier leur performance:
1. les projets de développement deviennent de plus en plus importants ; La synchronisation de nombreuses équipes de développement devient de plus en plus complexe et les coûts de transaction rattrapent les coûts de développement. SCRUM n’a qu’une réponse partielle à cette problématique à travers son SCRUM-of-SCRUMS, mais qui reste très conceptuel.
Résultat : plus l’entreprise grossit, plus elle ralentit ;
2. les équipes agiles qui ont acquis une vélocité soutenable, sont contraintes par les prises de décision et les mécanismes de financement qui eux, ne sont pas du tout agiles. L’environnement de l’équipe agile devient alors un frein à la vitesse acquise.
Résultat : plus on cherche à aller vite, plus on est freiné.
Les entreprises ont donc aujourd’hui de réelles difficultés à percer ce plafond de performance. Il faudrait un référentiel qui démultiplie l’organisation agile existant aujourd’hui dans les équipes à travers toute l’entreprise. On parle de référentiel « scalable », car il doit permettre d’être extrapolé quel que soit la taille des projets de développement : 10, 50, 200, 1000 personnes développant les applications en mode Agile.
Ce référentiel, c’est SAFe® (www.scaledagileframework.com)
Scaled Agile Framework web site
SAFe® est une réponse d’une grande élégance à la problématique de la scalabilité agile en entreprise. Ce référentiel s’articule en 3 (ou 4) couches :
1. la couche « Team »
Dans XP/SCRUM, on retrouve l’équipe de développement avec ses deux rôles pivot : le Scrum Master et le Product Owner. La « Team » implémente des incréments de fonctionnalités sur la base de User Stories.
2. la couche « Program »
Avec le SCRUM of SCRUMS, on trouve de nouveaux rôles qui ont pour objectif de coordonner n Teams contribuant à un même programme. On parle d’Agile Release Train (ART®) qui délivre des incréments de systèmes (agrégation de n incréments de fonctionnalités). Les rôles décrits ici sont le Product Manager (leader des Product Owners), le System Architect/engineer, et le responsable du Train de Release, le RTE® (Release Train Engineer) leader des Scrum Masters. La taille d’un ART® est supposée comprise entre 50 et 125 développeurs.
3. la couche « Value Stream » (optionnelle)
Elle est adossée aux principes du Lean management et a pour objectif de synchroniser les différents trains ART®, de façon à livrer des incréments de Solutions à un client final. Une Value Stream peut synchroniser de 2 à 10 ARTs® (ce qui signifie des équipes de 100 à 1250 personnes).
4. la couche « Portfolio »
Elle rend agile la prise de décisions liées aux investissements, permet la priorisation des epics (histoires de haut niveau décrivant les attendus macro) et abonde aux budgets, eux-mêmes associés aux Value Streams. Grâce à ce niveau, les décisions sont fluidifiées et associées aux flux de valeur à destination directe des clients.
Cet édifice est construit autour de principes très structurants, liés à une approche Lean-Agile permanente.
Des implémentations de SAFe® sont opérationnelles depuis plusieurs années maintenant, mais les entreprises qui utilisent SAFe® ne communiquent pas toujours sur leurs retours d’expérience : certaines considèrent en effet l’adoption de SAFe® comme étant un avantage concurrentiel tant les effets positifs sont rapides et puissants.
Il ne fait aucun doute que les entreprises vont basculer progressivement vers ce référentiel. De nombreuses très grandes entreprises l’ont déjà fait : Microsoft, Air France-KLM, Philips, Astra-Zeneca, SwissCom, HP, Cisco, Pôle emploi, Intel, Sony Interactive, etc….
à quand votre tour ?
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Les approches agiles ne se limitent plus au développement de logiciels.
Elles sont devenues populaires auprès de diverses organisations qui doivent être plus souples et réactives pour traiter efficacement leur rythme de changement croissant. Agile Project Management (AgilePM) est une approche novatrice de la gestion de projet. Le webinar vous présentera les différentes méthodes agiles, les principes de l’approche AgilePM et les outils nécessaires pour gérer les projets Agiles.
Accédez à la vidéo de notre partenaire QRP International
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.
Une des parties les plus importantes d’une rétrospective réussie est son « lancement ». Le facilitateur doit créer un environnement dans lequel l’équipe se sente à l’aise pour parler devant les autres de n’importe quel sujet. C’est le moment où l’exercice « la marque de voiture » pourrait vous aider.
Que pouvez-vous espérer de cet exercice ?
C’est une bonne entrée en matière pour permettre aux membres de l’équipe de partager leurs sentiments sur comment est allé le sprint. Ils peuvent montrer leurs ressentis sans avoir besoin d’exprimer ouvertement leur avis. Quand les membres de l’équipe sont nouveaux, peut-être hésitent-ils à parler franchement, c’est pourquoi ceci est un excellent exercice à utiliser dans cette situation.
Quand utiliserez-vous cet exercice ?
Comme expliqué ci-dessus, l’exercice devrait être utilisé au début pour préparer le terrain pour que l’équipe puisse commencer la rétrospective. Ceci est un bon moyen de révéler l’avis des personnes, permettant à tout le monde d’avoir une compréhension partagée de ce que pensent les autres.
Comment l’exécutez-vous ?
Au début de la rétrospective, assurez-vous que tout le monde se sent confortable, posez-leur après cela une question simple : « si vous pensez à ce sprint comme à une marque d’une voiture, quelle voiture choisissez-vous ? ».
Par exemple, je choisis une Ferrari ou une Maserati si le sprint est allé très bien. Si le sprint avait des hauts et des bas, je choisirais une Fiat ou une Skoda. Donnez à une équipe 2-3 minutes pour réfléchir à leur marque.
Ensuite, demandez à chaque membre de l’équipe de révéler « sa voiture ». Laissez-les dessiner sur un flipchart ou l’écrire sur un post-it. À ce moment-là, ne leur demandez pas de justifier leurs choix. Permettez aux membres de l’équipe de voir quel est le choix de chacun. Ceci crée un sentiment global sur où en est l’équipe. Puis, demandez-leur de penser à la voiture de leurs rêves et donnez-leur 10 minutes pour réfléchir à ce qu’ils changeraient dans le sprint passé pour avoir « la voiture de leur rêve ».
Normalement, les équipes trouvent beaucoup d’idées différentes, mais ces idées sont d’habitude liées à des problèmes partagés. Demandez alors à l’équipe de voter pour choisir le problème le plus critique et important auquel l’équipe s’attaquera dans le prochain sprint.
Cet exercice utilise une marque de voiture, mais vous pouvez utiliser d’autres objets significatifs pour vous. L’équipe n’a pas besoin d’être co-localisée pour exécuter cet exercice. Il est applicable aux équipes géographiquement distribuées en utilisant divers outils de partage virtuel.
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
« La connaissance s’acquiert par l’expérience, tout le reste n’est que de l’information. »
Cette citation d’Albert Einstein nous rappelle l’importance de l’apprentissage continu ou tel qu’il est défini dans le cadre européen des compétences, lifelong learning.
Notre partenaire QRP International essaie de toujours nous offrir des informations, des idées, des conseils et des retours l’expérience pour nous aider dans nos choix de formations et leur application dans nos organisations.
Livre blanc de notre partenaire QRP International
Ce livre blanc est dédié aux questionnement sur l’adoption de l’Agilité.
Commencez-vous à découvrir les méthodes Agiles ?
Envisagez-vous d’en adopter une ou plusieurs, comme nouveau mode de travail ?
«Pourquoi choisir une méthode Agile?» est une question très judicieuse.
Dans ce livre blanc, Alex Gray, formateur/coach Lean & Agile, analyse les méthodes de travail actuelles, en précisant leurs points forts et points faibles. Il liste les bénéfices pour les organisations d’une approche de gestion de projet agile.
Comme nous le savons tous, les réunions debout quotidiennes, « daily stand-up meetings » ou « Daily Scrums », constituent l’une des cérémonies de sprint les plus importantes, pour réussir à développer des histoires d’utilisateur. Je préfère penser au Daily Scrum comme à une réunion de synchronisation.
Les membres de l’équipe synchronisent leur travail : Voici ce que j’ai fait hier et ce que je pense que je ferai aujourd’hui. Le Daily Scrum donne de l’énergie. Les membres de l’équipe quittent la réunion enthousiastes sur les progrès qu’ils et que les autres ont réalisés.
Malgré le sixième principe du Manifeste Agile, « la méthode la plus efficace et effective de transmettre des informations dans une équipe de développement est la conversation en face à face », pour des équipes géographiquement distribuées, ceci n’est pas possible. La conduite de Daily Scrum quand les membres de l’équipe sont dans le même fuseau horaire et parlent la même langue est beaucoup plus simple que pour une équipe avec des membres dans de multiples pays et fuseaux horaires avec beaucoup de langages et de cultures différents. De telles équipes Agiles exigent un niveau différent d’attention, particulièrement quand elles se sont récemment formées.
Les équipes Scrum distribuées peuvent être classifiées selon trois types majeurs
a. Équipes Scrum dans le même fuseau horaire
b. Équipes Scrum avec chevauchement de fuseaux horaires
c. Équipes Scrum sans chevauchement de fuseaux horaires
Techniques pour piloter les Daily Scrums
Voici des techniques de pilotage des Daily Scrums pour les cas a. et b. ci-dessus.
Prenez en compte les fuseaux horaires, choisissez l’heure la plus commode possible pour toutes les équipes.
Identifiez et attaquez les points de blocages entre les Daily Scrums.
Utilisez un outil de planification Agile. Les avantages à utiliser un outil de planification Agile est que tout le monde est sur la même page et chaque membre peut, pendant les Daily Scrums, passer sur chacune des tâches ou histoires d’utilisateur en sachant que tout le monde sait où il en est. Tout le monde peut voir les informations de statut à travers les divers fuseaux horaires aussitôt qu’il est connecté.
Apprenez à l’équipe de l’importance de couper les micros de leurs téléphones quand un autre membre de l’équipe donne sa mise à jour.
Faites du Daily Scrum un sujet de discussion pour les rétrospectives de l’équipe.
Considérez que la qualité des Daily Scrums est directement liée à la communication. Une bonne communication peut être réalisée par téléconférence avec un écran d’ordinateur partagé avec tous les membres de l’équipe, ou par visioconférence, ce qui sera un peu plus difficile à configurer et n’oubliez pas de réserver une même salle de réunion chaque jour.
L’équipe et le ScrumMaster devrait s’efforcer de comprendre tous les points bloqueurs. Le ScrumMaster s’assure que tous ces bloqueurs sont adressés immédiatement après le Daily Scrum au cas où une autre réunion est exigée pour éliminer les bloqueurs.
Prenez des minutes des Daily Scrum. Cela aide des membres de l’équipe distribuée à surmonter des problèmes de langage, à planifier et à apprendre. Les outils de chat et un Wiki facilitent les Daily Scrums.
Si vous implémentez un outil de planification Agile, assurez-vous que les informations y soient à jour avant le Daily Scrum, que l’équipe soit co-localisée ou géographiquement distribuée.
Équipes sans chevauchement de fuseaux horaires (le cas c. ci-dessus)
Les points précédents sont valables pour les équipes Scrum qui opèrent dans le même fuseau horaire ou des fuseaux horaires se chevauchant (par exemple, l’Inde et l’Europe), mais pas pour des équipes sans chevauchement de fuseaux horaires (comme l’Asie et les États-Unis, ou l’Australie et la France).
Alors, comment réalisez-vous des Daily Scrums sans chevauchement de fuseaux horaires ?
Tenez le Daily Scrum chaque jour à une heure qui est incommode pour un côté ou pour l’autre. Faites tourner le fardeau de cet inconvénient d’un emplacement à l’autre chaque mois, en fonction de la réceptivité des équipes Scrum.
S’il est difficile de tenir la réunion dans ces conditions, identifiez un membre de l’équipe et demandez-lui de prendre note des mises à jour et de les partager avec l’autre partie de l’équipe.
(Un peu plus coûteux:) Enregistrez les Daily Scrums sur chaque emplacement et partagez l’enregistrement avec l’autre équipe. Avant le début du Daily Scrum quotidien, votre équipe peut revoir les mises à jour fournies par l’autre équipe.
Réalisez les Daily Scrums par la documentation.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Melanie Franklin, spécialiste du management du changement, a synthétisé dans un article en anglais le contenu de la table ronde lors de « Agile Business Conference » à Londres.
Voici quelques extraits traduits en français pour vous donner envie de lire l’original en entier: free download Selling Agile to Senior Managers
Melanie Franklin
« Selon mon expérience, il est utile de parler de quelques uns des concepts généraux que nous associons avec Agile et oublions parfois d’exposer parce qu’ils ne sont pas si évidents:
1. Nous livrons de premières versions du livrable final aussi tôt que possible pour que ceux qui sont concernés puissent apprécier ce que nous avons compris de ce qu’ils ont exprimé comme besoin:
Ainsi, nous pouvons corriger très tôt toute mauvaise compréhension
Et nous pouvons ajouter ce que nous avons oublié de mentionner quand nous discutions du sujet de manière abstraite
2. Le travail est une collaboration entre les experts qui conçoivent et code et les clients qui l’utiliseront pour réaliser leurs tâches
3. Bien que les détails de ce qui sera livré évoluent en fonction des retours, nous nous accorderons sur un périmètre et des délais sur lesquels nous engager. »
En conclusion, Melanie rappelle que:
« Pour le management exécutif, la transition vers un mode de travail Agile peut sembler demander un grand effort pour résoudre quelque chose qui n’a pas besoin d’être résolu. Ne vous attendez pas à un immédiat vibrant enthousiasme pour ce changement. Soyez prêt à régulièrement expliquer et démontrer les bénéfices de Agile. »
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Les 5 points remontés par Neil restent plus que jamais vrais dans nos organisations et entreprises
Genius Project est partenaire de DantotsuPM
1) Avoir la culture adéquate au déploiement d’une approche Agile
Dans les environnements Agile, les équipes sont autonomes. Elles sont face aux clients et agissent de manière démocratique. Les organisations cherchant à adopter Agile doivent questionner si ces principes sont en accord avec la culture et les valeurs de leur société. Si les divergences, voire antagonismes, sont trop forts: les chances de réussite sont minimes. Il faudra dans ce cas se concentrer sur une transformation de l’entreprise pour ne pas démarrer du mauvais pied avec Agile et ruiner d’entrée de jeu ses chances de succès.
2) Obtenir l’adhésion sans réserve du management et des leaders
La plupart des environnements de travail en management de projet ne réussissent qu’avec une bonne adhésion du leadership. Même si la culture de la société est adéquate, Agile nécessite une adhésion totale de la base au top management. Chaque personne a un rôle à jouer. Chaque personne a sa part de responsabilité avec Agile.
3) Mettre en place un robuste management du changement
Votre société est-elle prête pour un changement qui peut être radical ? Agile nécessite un changement majeur. Il est donc primordial qu’une stratégie de management du changement et des risques soit en place afin d’assurer une transition en douceur entre l’ancienne et la nouvelle manière de faire les choses.
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
4) Former toute l’organisation à la philosophie Agile
La méthodologie Agile nécessite une compréhension de sa philosophie dès le début. Agile nécessite la participation de tous les membres de l’équipe. Il est important que chacun connaisse l’ensemble du processus ainsi que sa propre contribution.
5) Mettre en œuvre un système qui institutionnalise la collaboration
La base de l’efficacité des projets Agile est un effort concerté de mise en place d’un système qui permette une collaboration efficace et transverse entre toutes les parties prenantes, internes comme externes. Vos clients sont-ils réellement prêts à s’investir lourdement dans le développement de leurs projets ?
Pour en savoir plus sur la méthodologie Agile, regardez cette vidéo de 6 minutes en anglais et le livre blanc qui l’accompagne
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La nature itérative du développement Agile implique que des fonctionnalités sont livrées de façon incrémentale, ce qui permet de commencer à encaisser des revenus pendant que le produit continue d’être développé.
2. Accélérer la vitesse de commercialisation
La recherche suggère qu’environ 80 % de tous les leaders du marché ont été les premiers à commercialiser leurs produit ou service sur ce marché. En sus d’un revenu plus élevé grâce à une livraison progressive, la philosophie de développement Agile supporte aussi la notion de sorties en avant-première et de nouvelles versions régulièrement par la suite ainsi que des versions « perpétuellement bêta ».
3. Accroître la qualité
Un principe clé du développement Agile est que les tests soient intégrés tout au long du cycle de vie. Ceci permet une inspection régulière d’un produit fonctionnel en cours de développement. Cela permet au propriétaire de produit (le « product owner ») de faire des ajustements si nécessaire et identifie en avant première tout problème de qualité pour l’équipe de développement.
4. Donner de la visibilité aux utilisateurs
Voici le diagramme du Modèle Scrum
Les principes de développement Agile encouragent la participation active des utilisateurs tout au long du développement du produit dans une approche collaborative très coopérative. Cela fournit une excellente visibilité aux principales parties prenantes, à la fois sur l’avancement du projet et sur le produit lui-même, ce qui aide à son tour à garantir que les attentes soient gérées efficacement.
5. Manager les risques au plus tôt
De petites versions progressives donnent de la visibilité au « product owner » et à l’équipe produit pendant le développement, permettent d’identifier les problèmes au plus tôt et facilitent la réponse à ceux-ci. La transparence dans le développement Agile aide à s’assurer que les décisions nécessaires peuvent être prises le plus tôt possible, pendant qu’il reste du temps pour faire une différence substantielle sur le résultat.
6. Améliorer la flexibilité en intégrant le changement
Dans des projets de développement traditionnels, nous écrivons de grandes spécifications au préalable et disons ensuite aux responsables business combien il est coûteux de changer quoi que ce soit, particulièrement quand le projet avance. Dans la crainte d’une dérive du contenu et de projet interminable, nous résistons aux changements et faisons passer les demandeurs par un comité de contrôle des changements pour les réduire au minimum vital. Les principes de développement Agile sont différents. Dans le développement Agile, le changement est accepté. En fait, on s’y attend. Parce qu’une chose certaine dans la vie est le changement. Au lieu de cela la durée est fixe et les exigences apparaissent et se développent comme le produit est développé. Bien sûr, pour que cela fonctionne, il est impératif d’avoir des parties prenantes impliquées qui comprennent ce concept et prennent les décisions de compromis nécessaires, négociant le contenu prévu pour un nouveau.
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
7. Contrôler les dépenses
La susdite approche avec des durées fixes et des besoins flexibles permet de tenir un budget fixe. Le contenu du produit et ses fonctionnalités sont variables, plutôt que le coût.
8. Satisfaire le client et le business
La participation active d’un représentant des utilisateurs et/ou un propriétaire de produit, la forte visibilité du produit et de l’avancement et la flexibilité de changer quand le changement est nécessaire, créent un bien meilleur engagement du business et accroissent la satisfaction du client. C’est un bénéfice important qui peut créer des relations de travail beaucoup plus positives et durables.
9. Construire le bon produit
Par-dessus tout autre point, la capacité dans le développement Agile de faire émerger et évoluer les besoins et la capacité d’embrasser le changement (avec les compromis appropriés), fait que l’équipe construit le bon produit. Il est trop commun dans des projets plus traditionnels de livrer un projet « réussi » côté informatique et de constater que le produit n’est pas ce à quoi on s’attendait, ni ce dont on avait réellement besoin ou que l’on espérait. Dans le développement Agile, l’accent est mis absolument sur la construction du bon produit.
10. Rendre le projet plus agréable !
L’engagement actif, la coopération et la collaboration font des équipes de développement Agile un endroit beaucoup plus agréable pour la plupart des personnes. Au lieu de grandes spécifications, nous discutons des besoins dans des ateliers. Au lieu des longs rapports d’avancement, nous collaborons autour d’un tableau des tâches, discutant de la progression. Au lieu des longs plans de projet et des Comités de Gestion des Changements, nous discutons de ce qui est bon pour le produit et le projet et l’équipe est autorisée à prendre des décisions. Dans mon expérience, cela donne une approche beaucoup plus utile pour chacun. À son tour, cela aide à créer des équipes fortement motivées, à haute performance et qui sont fortement coopératives.
Les implications d’embrasser des principes de développement Agile
Mais il y a des implications. Il n’existe rien de tel qu’une invitation à déjeuner sans contrepartie ! Et il n’y a aucune baguette magique pour le développement logiciel. Désolé, non, cela n’existe pas 🙂!
En échange de tous ces avantages, vous avez moins de prévisibilité car le logiciel et les personnes restent complexes. Vous ne pouvez plus blâmer quelqu’un d’autre si les choses ne se passent pas bien et cela exige généralement beaucoup plus d’engagement et d’efforts de chaque personne impliquée – c’est-à-dire que la collaboration est encore plus importante.
Néanmoins, les bénéfices du développement Agile sont vraiment irrésistibles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les initiateurs, experts et formateurs sur la méthode Scrum et surtout sur les attitudes Agile y partagent leurs expériences.
En sus de ces webcasts, le site Scrum.org vous permet de visionner des vidéos et lire des papiers d’étude et articles de blog sur l’agilité et plus spécifiquement sur Scrum.
Scrum est un processus empirique, parfois décrit comme “l’art du possible.” Par cela, je veux dire que nous faisons du mieux nous pouvons avec ce que nous avons.
Un Propriétaire de Produit (« Product Owner ») planifie une version (« release ») en se basant sur toutes les informations actuellement disponibles.
Il ou elle définit les objectifs, puis les fonctionnalités et capacités qui permettront de les atteindre ainsi que le coût probable et la date de livraison. À partir de ce moment-là, le travail du Propriétaire de Produit est d’évaluer ce qui est possible au vu les capacités de l’équipe et de prendre les meilleures décisions possible pour atteindre l’objectif visé. Étant donné la nature de la technologie, des marchés, des besoins et des personnes, des compromis seront faits. Parfois, le but ne peut pas être atteint pour un coût raisonnable. Parfois, le but sera atteint, mais d’une manière un peu différente de celle que le Propriétaire de Produit envisageait initialement. C’est l’empirisme en pleine action.
L’équipe (de développeurs) dans l’équipe Scrum fait de même. Elle rencontre le Propriétaire de Produit et évalue ce que le Propriétaire de Produit voit comme les choses les plus importantes à faire. Si réalisées, ces choses amèneront le produit émergent dans la meilleure direction vers le but désiré. L’équipe choisit autant de choses qu’elle pense pouvoir faire pendant le prochain Sprint. Le coût de l’équipe et la longueur de Sprint sont fixes. Seule la quantité d’items du « Product Backlog » embarquée peut varier. Le Propriétaire de Produit et l’équipe définissent souvent un objectif global pour le Sprint. Il est un sous-ensemble des objectifs de la version (« release »).
Microsoft est partenaire de DantotsuPM
Quand l’équipe choisit des items lors d’une réunion de Planification de Sprint, elle s’engage à le faire pendant le Sprint.
Une définition « s’engager » est : « Se lier moralement par une promesse : Il s’est engagé à payer ses dettes dans les huit jours. » selon le Larousse. (ndlt)
Cela correspond à ma compréhension du mot s’engager, qui est une promesse, un engagement sur un plan d’action.
Cependant, beaucoup d’équipes Scrum utilisent le mot « s’engager » comme si c’était « une garantie ». C’est un reste des méthodes traditionnelles dites en cascade, où une estimation valait pour contrat. Cependant, cela reste présent dans l’esprit des propriétaires de produit et des développeurs. J’ai trouvé équipes après équipes qui estiment qu’elles doivent tout faire pour respecter leur engagement: La victime est habituellement la qualité.
Je me demande si nous devrions échanger le mot « s’engager » pour celui de “prédire” ?
Ceci pourrait donner la même perception que la présentatrice météo essayant de nous fournir les meilleures informations possibles. Elle fait avec que l’on connaît et avec ce que peut lui fournir la science de la météorologie. Elle ne fournit pas de garantie mais quelque chose que nous pouvons utiliser pour prendre des décisions. Les prévisions sont également utilisées par les organisations de ventes.
Peut-être cette clarification nous aidera-t-elle à comprendre qu’ « un engagement » dans Scrum est une promesse de faire de notre mieux avec ce que nous avons.
CertYou est partenaire de DantotsuPM
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
L’Aïkido Verbal est un moyen pacifique de gérer les attaques verbales, basé sur la philosophie de l’aïkido martial.
