Tirez le meilleur des « daily scrum » en vous refocalisant sur leur raison d’être.
Agile et Scrum ont révolutionné le paysage de l’industrie informatique. La plupart des sociétés ont déjà adopté Agile ou se rapprochent de ces méthodes. Cependant, la réalité est que la plupart considèrent encore Agile comme une forme de développement en cascade itératif plutôt que d’accepter ses pratiques radicalement différentes.
L’une des pratiques Agile les plus intéressantes et les plus utiles est la réunion debout de Scrum (Daily stand-up) tenue par l’équipe Agile. Le ScrumMaster y supporte la collaboration entre les membres de l’équipe. Pourtant, il existe quelques pièges typiques dans lesquels tombent les équipes Agiles.
En voici quelques-uns à éviter :
1. Entrer en mode réunion classique.
En réunion classique, l’équipe s’éloigne du format du stand-up et commence à discuter des choses dans le désordre. La réunion devient un état des lieux plutôt qu’un rapport d’avancement. Ceci peut tuer la concentration de toute l’équipe qui se focalise sur une ou deux activités importantes plutôt que l’objectif à atteindre. Il est extrêmement important que toute l’équipe soit concentrée ce que chacun réalise dans l’équipe pour comprendre la dynamique et prendre conscience de ce vers quoi se dirige le groupe en entier.
2. Tout discuter maintenant.
Souvent une personne mentionne un point et cela devient une discussion entre deux ou trois personnes. Il est important de terminer cette conversation, mais il est encore plus important que cette session se tienne hors réunion pour permettre un échange correct. Même si le point impacte toute l’équipe, une discussion séparée pour débattre de ce point est nécessaire. Le Daily Stand-up ne devraient pas être utilisés pour débattre de tels sujets, se focaliser sur l’avancement des tâches est de la plus haute importance.
3. Annuler la réunion comme si elle n’était pas nécessaire.
Une autre chose qui arrive souvent dans les périodes où l’équipe est trop chargée ou pas assez, est que certaines équipes décident d’annuler la réunion. Ou bien, ils tombent dans ce piège si le ScrumMaster est absent. N’annulez jamais cette réunion. Si il y a peu à discuter, terminez la plus tôt. La réunion n’est pas faite pour présenter un rapport à qui que ce soit (même au ScrumMaster) mais pour maintenir l’auto-organisation de l’équipe et son focus. La discipline et la pratique sont les clés de l’Agilité.
4. « Ils n’ont pas besoin de savoir »
Souvent le ScrumMaster assume que l’équipe est concentrée sur le boulot en cours et garde donc par devers lui les discussions sur de nouveaux développements discutés avec le client ou autres détails. Ceci est fatal. Il est important que cette information soit partagée avec l’équipe pour que tous soient au courant. Rester proche du client et de son monde contribue largement au succès de l’équipe Scrum.
5. « Laissez-moi juste en parler au client »
Un autre mythe ou mauvaise compréhension est mis en évidence lorsque le ScrumMaster ou le chef de projet essaie d’apporter des choses qui proviennent de l’équipe au client sans impliquer l’équipe. Il est primordial que l’équipe soit rapprochée du client. Ceci est l’un des attributs les plus importants et uniques de l’équipe Agile en termes de collaboration et d’ouverture. Ceci aide de multiples façons que d’engager avec le client et toute tendance à l’éviter devrait être bannie.
Marc Burlereaux has presented an article written by Christine Rieu, Sylvain Gautier and himself about the pitfalls when introducing Agility at the Project Zone Congress 18,19 March 2013 in Frankfurt.
The Agile approach used for projects, or new product development, ensures a greater flexibility with iterative design, lighter documentation and formalization, more interactivity and efficiency in the conduct of meetings, and especially more customer involvement throughout the project (Pichler, 2010). By coupling a Lean approach to these Agile methods; we remove all unnecessary and ‘non-value added’ steps to minimize waste and to maximize the expected value of the product (Larman & Vodde, 2010). This seems to be the panacea!
But it is not straightforward to implement this type of approach and the Project Manager may be asked many questions:
o How will these approaches be integrated successfully in mature Project Management organizations that are more familiar with traditional software V-Model (software development) or Waterfall Model?
o How will the Release Manager be in a position to facilitate the delivery of products developed with Agile and Lean approaches? This is particularly relevant given his/her role is to keep adherence to rigid processes for minimizing the risks associated with change, which is often seen by the Agile Project Manager as an awful slowdown in the delivery process.
o How will these deliveries fit in the whole Release Management process, including testing procedures (unit, integration and acceptance testing of applications), the production of operating technical documentation, user guides, and the creation of installation and deployment procedures?
o How will you avoid Agile being used as an excuse for lax and ineffective behaviours, such as removing documentation?
The success of such projects imposes a balance between a comprehensive Agile approach and a discipline warranty by the Release Management process. Hence the title of our paper, « An Iron Fist in a Velvet Glove. »
This presentation is based on lessons learned gathered during project experiences combining Agility and Lean Management in various fields of industry and banking organizations. We explain our vision of the prerequisites for a project to be eligible for Agile methods. The thread of the presentation is to then illustrate our experiences with emphasis on Agile best practices that we have identified as key success factors. We have divided these keys points throughout the various phases of project development, with a particular emphasis on the early stages of scoping and preparation, and then the final stages of acceptance (technical and business) and finally the transition to production.
The following anecdote illustrates that sometimes agile’s team are surprisingly facing rigidity:
Jack Duggal, a seasoned Program Manager with over 30 years of experience in project management, said at a conference organized by PMI (Project Management Institute) in Geneva in 2012: « You can sometimes blame rigidity in the application of agility. In a Scrum meeting, which assumes that you are standing, a person a little tired had expressed the need to sit down: this was refused, as matter of principle! »
Whatever method is chosen, we should be able to get inspired by other approaches and benefit from best practices:
As an example, PMI, which is the authority in the management of « traditional » projects, has naturally opened the door to the principles of Agility by recently creating a new credential PMI-ACP (Agile Certified Practitioner) and integrating Agile and Lean Management into traditional project management. For example, the PMBOK 5th edition now takes into account Agile « Adaptive Life Cycles » with section 2.4.2.4 covering iterative and incremental methods. These methods involve short iterations of 2 to 4 weeks with fixed time and resources (i.e. time boxing).An important aspect to add is the risk management: this is an example of good practice derived from traditional methods integrated into agile approaches.
Finally, we conclude by reminding the four principles issued by the Manifesto for Agile software development written by Kent Beck and 16 other signatories (K. Beck et al, 2001) which by the way could be followed regardless of the chosen project management methodology:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we place more value to the items on the left.
The Agile approach should be considered rather as a philosophy of development
In this presentation, we wanted to give very practical advice to implement a successful agile approach, especially in organizations which will combine it with more traditional models. It is inspired by our experiences in various project contexts and emphasizes the importance of deeply understanding the benefits and implementation impacts of this new way (i.e. not just use it as a « tool box with an integrated checklist »). The Agile approach should be considered rather as a philosophy of development, which focuses on employee involvement and commitment. One has to take in each method that is « good for business », knowing that every business is unique and has its own specific operational characteristics. Opposed to traditional methods, Agile methods are a revolution, but they can also bring their share of the burden and stress, depending on the implementation and the use.
The Agility is good but to control it is even better …
– The Scrum approach is not a panacea, especially if it is not understood and supported by the Management and Business Analyst (MOA)
– The Lean Approach coming from the industry may not be implemented in all contexts
– The AGILE mindset is primarily the key success factor that will ensure a smooth Agile implementation
– We must select the right AGILE tools best suited to the company
– A pragmatic coaching is a key success factor
– The dogmatism must be forgotten
– And we must contextualize the process that could not be standard for all areas (from the space industry to Google, through aerospace, automotive, banking …).
Last but not least, misunderstood and badly launched / implemented Agility may cause more damage than traditional methods.
Let’s Be WAGILE! Contraction of WATERFALL (traditional methods of development) and AGILE … hence Agility: An Iron Fist in a Velvet Glove!
Christine RIEU, works as an Associate Professor in the Listic laboratory and has carried out research on Knowledge Management for the past 15 years. Christine teaches Project Management at the IUT of Annecy where she also holds the position of Head of International Relationships. . Christine is also a founding member of “PMI Pôle des Pays de Savoie”, France Chapter.
Marc BURLEREAUX, has more than 27 years of expertise in Project, Program and Portfolio Management with a proven track record in the field of Swiss Private Banking. Marc is a Senior Volunteer at PMI, Director of “Pôle des Pays de Savoie” (part of the France Chapter) and also a member of the PgMP® & PMI-RMP® Credentials PRC (Panel Review Committee). Marc has been applying agile technics for the past 10 years, and more recently has spent two years as Head of European Release Management in a Swiss Private Bank.
Sylvain GAUTIER, has more than 27 years of expertise in IT and started his career working as a consultant, and then as an architect, within the Software Industry (Computer Associates, Sybase). Sylvain focused mainly on data design, DBA, and project management methodologies for major European projects before becoming Head of IT Operations for an important private bank in Geneva. Sylvain is now a freelance consultant applying Agile, ITIL, Archimate and Service Design best practice to companies within the Banking and Insurance sector.
Bonus video : « Agile: An Introduction »
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
cliquez sur l’image pour télécharger ce guide gratuit en français
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
Partenaire de DantotsuPM
.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
Partenaire de DantotsuPM
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) ontpermis à 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.
Voici le diagramme du Modèle Scrum
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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,
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 !
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 »
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
article précédent sur assistons-nous à la fin des contrats « classiques »?
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 ».
partagez ce billet avec vos amis, collègues et relations professionnelles
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Avez-vous jamais entendu ou prononcé l’une de ces expressions ?
Nous allons implémenter la méthodologie Scrum.
Nous appliquons un Scrum modifié.
Nos développeurs utilisent un processus Scrum.
Ces déclarations peuvent sembler inoffensives mais elles sont les indicateurs d’interprétation erronée potentielle de comment Scrum est le mieux utilisé. Scrum n’est pas un processus de développement complet (bien que presque quoi que ce soit qui a des étapes puisse être considéré comme un processus) et ce n’est pas une méthodologie. Scrum ne vous dit pas comment implémenter le logiciel. C’est une structure simple qui aidera un groupe qui développe des produits à comprendre ce qui ne fonctionne pas bien et comment y remédier.
Voici le diagramme du Modèle Scrum
La Structure de Scrum
Au début, les personnes et équipes implémentant Scrum se concentrent sur le processus sans comprendre pourquoi et comment réaliser chaque partie efficacement. Nous croyons que nous « ferons du Scrum » et en gagnerons tous les bénéfices, simplement :
En maintenant d’une liste de travail à faire (l’Arriéré de Produit)
En l’assignant à l’équipe pendant une réunion de Planification de Sprint
En réalisant ce travail pendant la durée du Sprint
Ce focus sur comment passer à travers les étapes peut être dangereux et irritant pour les individus, équipes et managers. Scrum n’est pas UNE SOLUTION MIRACLE! Aucun processus, pratiques, ou des techniques ne le sont. Au lieu de vous concentrer sur le processus, les pratiques et les techniques de Scrum, je suggère aux personnes, équipes et au management de se concentrer sur les enseignements qui peuvent être produits par une équipe faisant du Scrum et agir sur ceux-ci.
Scrum est un processus empirique de contrôle. L’idée est que vous planifiez et réalisez ensuite quelque chose, inspectez ce que vous avez fait et adaptez ensuite votre comportement pour vous améliorer. C’est une structure apprenante pour des équipes de développement de produits. On se réfère à ce cycle d’étude comme « inspecter et s’adapter ». Les 3 rôles de Scrum sont impliqués dans cet apprentissage : le Propriétaire de Produit, le ScrumMaster et les Développeurs (quand je dis Développeurs je veux dire toute personne dont on a besoin pour construire le produit, pas seulement des programmeurs).
Dans Scrum, Il y a 3 cycles spécifiques « Inspecter et Adapter » :
La rencontre Scrum Quotidienne (Daily Scrum) permet à l’équipe de se concentrer sur ses engagements pour le Sprint actuel et vérifier s’ils sont toujours en piste pour livrer par rapport à cet engagement. S’ils ne peuvent pas respecter l’engagement, alors on leur demande d’ajuster le Sprint, s’adaptant ainsi à la situation.
La réunion de Revue de Sprint (Sprint Review) permet aux clients de voir un incrément de produit potentiellement utilisable créé par l’Équipe et de leur fournir un retour d’information qui ajuste le contenu de l’Arriéré de Produit et les priorités. Nous inspectons le produit et nous nous adaptons à une nouvelle compréhension du produit.
La Rétrospective de Sprint permet à l’Équipe d’améliorer le processus qu’ils utilisent pour délivrer du logiciel à chaque Sprint. On s’attend à ce que l’équipe inspecte son processus honnêtement et à fond pour comprendre comment ils peuvent s’adapter pour que leur capacité collective de livraison soit améliorée dans le prochain Sprint.
Si vous lisez souvent mon blog, vous pourriez reconnaître ici un billet précédent appelé « Kaizen Mentalité » qui contient de bonnes informations sur la façon d’utiliser les leçons apprises et gérez les obstacles autour de celles-ci.
Partenaire de DantotsuPM
Scrum est plus un outil qu’une méthodologie.
Scrum rendra visible ce qui ne va pas aussi bien qu’il pourrait être. C’est alors aux personnes dans l’équipe et l’organisation e faire des changements pour s’améliorer. Avec chaque amélioration progressive, l’équipe de développement accomplira beaucoup plus efficacement son travail. Plutôt que de vous concentrer sur atteindre la perfection sur chaque étape dans la structure de Scrum, découvrez ce qui peut être amélioré dans votre processus de livraison et adaptez-le en conséquence. Si une partie de la structure de Scrum est difficile à faire ou semble être une perte de temps alors, au lieu d’éliminer cette partie, découvrez pourquoi c’est difficile ou gaspilleur dans son adoption. Il y a d’habitude un obstacle caché derrière ces difficultés et perceptions qui si il est éliminé permettra à l’équipe de développement de produits d’être plus efficace.
Scrum n’est pas une destination.
C’est plutôt un outil qu’une équipe de développement de produits utilise pour continuellement inspecter et adapter leur façon de délivrer pour la rendre plus effective. La destination devrait être votre business et vos objectifs d’efficacité d’équipe de développement. Comment pouvons-nous livrer davantage ? Comment pouvons-nous réduire le temps entre le commencement et la livraison du projet? Comment pouvons-nous délivrer plus souvent à plus bas coût pour stabiliser les sorties de produits ? Comment pouvons-nous réduire le risque dans notre processus de livraison de projet et dans notre portefeuille de projets ?
La destination devrait être substantielle et attractive. Scrum est seulement le véhicule pour vous aider à vous y rendre.
partagez ce billet avec vos amis, collègues et relations professionnelles
La méthode de gestion de projets PRINCE2 grandit en popularité dans le monde entier. Cependant, un nouveau challenger, Agile, est apparu. Nous commençons à entendre ici et là le débat « PRINCE2 ou Agile » ? C’est une question intéressante, mais souvent c’est une façon erronée de poser le problème.
En effet, lorsque vous commencez un projet de décoration d’intérieur, vous ne vous demandez pas si vous allez utiliser le marteau ou le tournevis ? Il est probable que vous aurez besoin des deux. Ce qui importe est de savoir quand utiliser quel outil et de savoir utiliser chaque outil correctement.
La même chose s’applique à PRINCE2 et Agile. Une organisation mature dispose des deux méthodes dans sa boîte à outils, et de manière habile utilisera l’outil approprié au bon moment.
Donc si nous avons besoin de PRINCE2 et Agile, comment comparer les deux outils ?
Tout d’abord comparons ce qui est comparable, le point de départ est donc de trouver l’Agile qui convient. En effet, Il y a beaucoup de variantes d’Agile, comme ces variantes légères que sont SCRUM et XP. Ces variantes légères ne sont pas des méthodes de gestion de projets de grande envergure, elles sont utilisées par les équipes afin de gérer des parties de projets, surtout la partie informatique. Un concurrent de poids à PRINCE2 est ATERN Agile (aussi connu sous le nom DSDM).
Partenaire de DantotsuPM
PRINCE2 et Agile-ATERN sont des méthodes de gestion de projets à part entière. Les deux sont des méthodes globales. Les deux sont des méthodes « clé en main » axées sur la rentabilité, le contrôle, la qualité, et ainsi de suite.
Laquelle choisir ?
PRINCE2 est le choix le plus approprié pour les projets basés sur les spécifications
ATERN Agile est le meilleur choix pour les projets de découverte
ATERN Agile est fantastique pour les projets avec des dates butoir serrées
Le type de projet va influencer le choix de votre méthode :
Basés sur les spécifications signifie que vous commencez avec un document écrit (et probablement avec un contrat) ;
Les projets de découverte eux ont seulement besoin des éléments essentiels pour démarrer ;
Les projets avec des fortes contraintes de délai doivent absolument être livrés à temps.
Mais il n’est pas toujours nécessaire de choisir entre l’une ou l’autre des méthodes. Puisqu’ATERN a intégré des idées de PRINCE2, alors vous pouvez aussi rendre PRINCE2 plus Agile.
Voici quelques façons de rendre un projet PRINCE2 plus Agile :
Utiliser votre première séquence pour construire un prototype avec des fonctionnalités limitées afin de simuler la vraie solution ;
Utiliser ensuite une séquence pilote avec un déploiement limité qui vise à développer quelque chose qui marche et est utilisable dans l’usage quotidien ;
Utiliser les « timebox » (zéro tolérance de temps pour une séquence, mais une haute tolérance de périmètre – si vous êtes en retard, réduisez le périmètre) ;
Débuter votre journée par des réunions debout (chef de projet plus les chefs d’équipe) ;
Utiliser le concept de « suffisamment de conception en amont » (EDUF : Enough Design Up Front) et non pas le concept de « Massive Conception en Amont » (BDUF : Big Design Up Front) en finalisant vos descriptions de produit à la limite de séquence (au lieu du DIP) ;
Pour un lot de travaux où vous avez besoin d’une approche de découverte, utilisez une méthode Agile légère comme XP ou SCRUM.
Tout comme la question n’est pas de savoir s’il faut utiliser le marteau ou le tournevis pour vos projets domestiques, le même raisonnement s’applique lorsqu’il s’agit de PRINCE2 ou d’Agile pour votre entreprise.
CONCLUSION
Tout comme vous avez besoin d’un marteau et d’un tournevis à la maison, vous pouvez avoir besoin de PRINCE2 et d’Agile au travail. Le mieux c’est donc d’avoir les deux outils. Si vous utilisez PRINCE2 aujourd’hui, vous devriez d’ores et déjà commencer à vous intéresser à ATERN.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Merci à Mahfoud Amiour , Directeur de projet indépendant, Expert Agile chez SOFTENIA Solutions, qui a récemment traduit en français la dernière version du guide Scrum de Ken Schwaber et Jeff Sutherland (Version Juillet 2011).
Il y a trois raisons. Deux font explicitement partie de Scrum. L’autre n’est pas mentionnée, mais est une des fondations de Scrum. Les explicites sont le retour d’information rapide et le renforcement de la vue réaliste. La troisième est la suppression des retards.
Retour d’information rapide
Vous voulez un retour d’information rapide. Attendre plus de 30 jours pour ce retour d’information ne vous donne pas assez rapidement ce retour d’information.
Quel genre de retour d’information ? Un retour d’information qui vous permette d’apprendre rapidement. Le retour d’information vient sous bien des formes. Il y a le temps entre la réception d’une demande jusqu’à sa livraison et le temps de commencer une histoire jusqu’à ce qu’elle soit complète. Mais vous n’avez pas à écrire tout le code pour découvrir que le client n’en veut pas. Au lieu de cela, vous voulez écrire un peu de code sur les histoires dont le client a une compréhension claire. Montrer une partie de la fonctionnalité à un client nous permet d’en apprendre davantage sur le reste de ce qu’ils veulent.
J’entends souvent « échouez vite » comme raison. Je préférerais personnellement apprenez vite. Si je dois échouer, je voudrais le faire rapidement. Mais mon objectif est d’apprendre pas d’échouer.
Renforcement de la vue réaliste
Avec « renforcement de la vue réaliste », je veux dire que seule la fin d’un sprint nous dira où nous en sommes de manière objective, non subjective. Si le test n’est pas fini, sprint n’est pas fini. La raison est probablement un obstacle dans notre processus. Sans dates rigides, fixes, il est facile de rationaliser pourquoi nous n’avons pas accompli ce que nous voulions. Des obstacles usuels sont que les clients peuvent ne pas vouloir vous parler, que les processus de développement sont peut-être inefficaces, que les évaluations et le développement du code sont trop éloignés. En ayant une période déterminée de temps dans laquelle votre travail doit être achevé avec le timeboxing du sprint, ces choses qui travaillent à votre encontre deviendront plus visibles et douloureuses. Ce sont dans les faits des obstacles à votre travail et au lieu de les éviter en rallongeant le sprint, vous devez en réalité raccourcir le sprint pour les mettre encore plus en évidence. Il sera aussi plus difficile de les ignorer : si vous n’avez pas testé votre code à la fin du sprint, ce sera évident et irréfutable.
Ces deux raisons ont en réalité tendance à inciter à des sprints encore plus courts que 30 jours. La plupart des équipes Scrum qui réussissent et que je connaisse utilisent des sprints d’une ou deux semaines. En fait, j’irais jusqu’à dire que des équipes avec des sprints de trois ou quatre semaines indiquent une tendance à ne pas être pas suffisamment engagées dans la résolution de leurs problèmes. Ceci n’est pas toujours vrai, mais c’est assez souvent le cas.
suppression des retards
La troisième raison, qui par beaucoup d’aspects est la plus grande, est d’éliminer les retards.
Depuis 2004, j’ai clamé que Scrum est une faible mise en œuvre des principes Lean. Je dis « faible » parce que Scrum ne se préoccupe pas de l’optimisation de la totalité du processus, Scrum se concentre sur l’équipe de développement et délaisse une grande partie de l’éducation et du management Lean. Mais un des principes clés de Lean est d’éliminer les retards afin que la valeur puisse peut être délivrée rapidement. Ceci est critique parce que chaque délai entre étapes de travail crée littéralement plus de travail.
Le timeboxing dans Scrum exige que les équipes complètent leur travail rapidement, et encourage aussi à élaguer. Ceci réduit les retards et évite donc de faire un travail qui ne devrait pas être nécessaire.
La combinaison du retour d’information rapide, du renforcement de la vue réaliste et de la suppression des retards nous permet d’avoir des boucles de retour d’information de plus en plus brèves jusqu’à ce que tous les frais généraux du sprint, les « overhead », dépassent la valeur qu’ils sont censés apporter. Pour la plupart des équipes ce sera une ou deux semaines. Quelques équipes découvriront qu’elles n’ont pas besoin de la discipline du timeboxing et l’abandonneront complètement et pour passer sur Kanban.
partagez ce billet avec vos amis, collègues et relations professionnelles
Scrum est une technique de » management de projet » de plus en plus populaire sur les projets de développement logiciels (et de temps en temps sur d’autres types de projets). L’article Wikipedia http://fr.wikipedia.org/wiki/Scrum_(méthode) peut être un bon point de départ pour en apprendre davantage sur ce sujet.
Le « Microsoft Project 2010 Scrum Solution Starter » est conçu pour fournir des conseils d’utilisation de Microsoft Project 2010 pour manager des projets Scrum, aspirant à aider les équipes Scrum à commencer à utiliser MS Project pour :
Manager un Arriéré de Produit
Manager un Arriéré de « Sprint »
Suivre la progression et générer des « Burndown charts »
Ce kit de démarrage se concentre sur le poste MS Project 2010 et sur l’expérience de l’équipe Scrum.
Scrum est une méthodologie itérative et incrémentale pour la conduite de projet souvent vue dans le développement logiciel agile. Bien que Scrum ait été destinée au management de projets de développement logiciels, il peut être utilisé pour des équipes de maintenance logicielles, ou comme une approche générale de management de projets/programmes.
Il y a 3 artefacts principaux dans Scrum :
Arriéré de produit : Un arriéré de produit est dynamique : des items peuvent être supprimés ou ajoutés à tout moment pendant le projet. Ce sont les items avec la priorité la plus forte qui sont complétés d’abord. Ces articles prioritaires sont progressivement raffinés alors que ceux de priorité inférieure sont intentionnellement laissés à une granularité plus élevée.
Arriéré de sprint : Un arriéré de sprint est un jeu négocié d’articles de l’arriéré de produit qu’une équipe s’engage à compléter pendant la durée fixée pour un sprint. Les articles de l’arriéré de sprint sont décomposés en tâches détaillées pour que les membres de l’équipe les réalisent. L’équipe travaille de manière collaborative pour compléter les items de l’arriéré de sprint, se rencontrant chaque jour (pendant un « Daily Scrum ») pour partager les problèmes et avancées et mettre à jour l’arriéré de sprint et le « Burn Down chart » en conséquence.
« Burn Down » : Le graphique « Burn Down » du sprint est affiché publiquement et montre le reste-à-faire dans l’arriéré de sprint. Mis à jour quotidiennement, il fournit une vue simplifiée du progrès du sprint. Cela fournit aussi une visualisation rapide pour référence.
Scénarios Supportés:
Un Scrum Master veut utiliser MS Project pour les basiques de l’exécution d’un sprint, y compris :
Collecter et suivre le progrès
Gérer l’Arriéré de Produit
Gérer l’Arriéré de Sprint (et planifier l’itération initiale)
Générer un « Burn Down Chart »
Exporter facilement des données de Scrum poules r envoyer par courrier électronique ou autre moyen
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous n’aimez pas le mot « Exigences » ? Ce n’est pas si clair, n’est-ce pas ? NON ! Avez-vous avez jamais entendu votre client dire « Je vous ai déjà donné mes exigence » et l’équipe répond alors « Nous n’avons pas reçu de besoins clairs ou détaillés ». L’autre face de ceci est quand l’équipe dit au client « Vous nous donnez trop de détails, ne nous dites pas où le bouton doit être placé sur l’écran, dites-nous seulement ce que vous voulez ». Pas étonnant nous ayons tant de problèmes liés aux exigences sur nos projets!
Pendant l’un de mes webinars PMI précédent, nous avons parlé de Agile Requirements – Breaking Down EPICs and Prioritizing. Je ferai un essai dans ce billet à récapituler les niveaux d’exigences Agile (et non Agile pour être honnête) et comment vous pouvez utiliser un processus à quatre étapes pour les rassembler.
D’abord, commençons par l’image ci-dessous. L’image montre 4 niveaux d’exigences et aussi sur la gauche les 4 étapes du processus pour réunir les exigences.
Visioning: C’est l’étape initiale de collecte des exigences. Le but est d’aider à identifier tous les Thèmes et quelques fonctionnalités désirées. Cet exercice commence à définir le périmètre de ce qui est attendu.
Brainstorm: Le but de cette étape est d’identifier toutes les fonctionnalités et histoires (« stories ») désirées. La clé est ici la Couverture d’abord, la Profondeur plus tard. Ainsi, au lieu de discuter les détails de chaque fonctionnalité et histoire, notre but principal est de TROUVER toutes les fonctionnalités et histoires.
Breakdown: Le But de cette étape est de décomposer et découper les histoires qui sont encore trop longues (des ÉPOPÉES) en de plus petits morceaux. Vous avez probablement déjà fait beaucoup de découpage pendant le brainstorming, mais comme vous revisitez votre arriéré, l’équipe se rendra compte que quelques histoires sont encore trop longues pour être complétées en une itération (d’habitude 1 à 4 semaines). Le découpage des histoires est un art et j’y dédierais un blog entier!
Deep Dive: C’est l’étape à laquelle veut sauter tout de suite! Oui, finalement parlons des détails. Ce qui sera sur l’écran, quelles sont les règles de gestion exactes et comment nous ferons pour les tester, ce à quoi ressemblera le processus détaillé, quelles sont les tâches que nous devons réaliser pour achever cette histoire. Sauter dans ce niveau de détail en amont pendant les phases initiales est une des raisons principales contribuant à la dérive de contenu plus tard pendant le projet.
Supposons que nous développons un système pour un site d’offre d’emploi en ligne OnStopJobs.com. Voici à un exemple de ce à quoi les exigences pourraient ressembler en se basant sur les niveaux ci-dessus :
1. Domaine Employeur- Thème
a. Gérez des Emplois- Fonctionnalité
1. En tant qu’employeur je veux afficher un job afin que d’autres puissent le trouver. Histoire
2. En tant qu’employeur je veux modifier une offre d’emploi pour la corriger. Histoire
3. En tant qu’employeur je veux une liste de mes offres d’emploi ouvertes pour les analyser. Histoire
4. En tant qu’employeur je veux pouvoir faire expirer une offre d’emploi pour que personne ne puisse y appliquer. Histoire
b. Gérez les Candidats
1. En tant qu’employeur je veux voir la liste de candidats récents pour pouvoir leur répondre.
2. En tant qu’employeur je veux voir la liste de candidats d’une offre d’emploi spécifique pour pouvoir les qualifier.
3. En tant qu’employeur je veux choisir les meilleurs candidats pour pouvoir les interviewer.
Vous devriez rassembler les niveaux ci-dessus (Thèmes, Fonctionnalités, Histoires) en amont quand vous planifiez de votre « Release », particulièrement si vous avez des projets traditionnels avec des dates de début et de fin. Nous passons d’habitude plus d’effort sur les histoires qui arrivent dans les quelques itérations suivantes ou la Release suivante.
Le Deep Dive est là où se trouve la différence principale entre Agile et En Cascade. Des équipes traditionnelles rassembleraient des informations très détaillées en amont pour TOUTES les histoires de l’arriéré, Alors qu’en Agile , les équipes rassembleront ces détails Juste à temps pour les histoires suivantes, soit une ou deux itérations avant que cette histoire soit à faire.
Voici à un exemple de ce à quoi les détails pourraient ressembler pour cette histoire choisie : « En tant qu’employeur je veux job afin que d’autres puissent le trouver «
Critères/tests d’acceptation (Comment saurons-nous quand nous aurons fini):
1. UAT1 – Vérifier que seul un utilisateur autorisé avec un compte d’employeur valable peut poster un travail pour le compte de cet employeur.
2. UAT2 – Vérifier qu’une offre d’emploi dupliquée ne peut pas être entrée.
3. UAT3 – Vérifier que la date de publication est plus tard que la date du jour.
4. UAT4 – Vérifier que la date d’expiration est en principe dans 90 jours.
5. UAT5 – Vérifier que les champs sur l’écran passent nos règles standards de format.
6. UAT6 – Vérifier que tous les champs requis sont saisis.
Les critères d’acceptation sont ‘les détails’ de l’histoire et on les considère comme des exigences primaires dans Agile. Nous les réunissons avant de débuter tout développement.
Exemples de Tâches (Le travail à faire pour avoir fini):
1.Créez des tables de base de données pour stocker les détails d’offre d’emploi.
2.Concevez et construisez l’écran pour l’offre d’emploi.
3.Développez la logique pour passer UAT1.
4.Documentez/enregistrez l’aide vidéo insérée dans la page d’offre d’emploi.
5.Exécutez le test d’acceptation utilisateur.
6.Déployez le code dans l’environnement de test.
7.…..autres.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
J’étais à une conférence il y a peu de temps parlant et partageant sur divers sujets agiles. Comme il arrive souvent, un jeune homme m’a arrêté afin de me poser quelques questions après ma présentation. Nous avons entamé une conversation agréable qui a finalement débordé jusqu’au corridor de l’hôtel.
Nous avons commencé à parler de la dynamique de sprint dans des équipes Scrum et je suis arrivé de mentionner que je coache souvent des équipes vers la déclaration de leurs sprints en tant que succès ou… (pause pour plus d’effet) échec. Que nous faisons ceci comme partie intégrante de la revue de Sprint avec les équipes, le Propriétaire de Produit étant le décisionnaire final en se basant sur selon que l’équipe a atteint les Objectifs de Sprint ou pas.
Il a été visiblement énervé par mon avis. Il a dit qu’ils (il travaillait dans une société bien connue d’Atlanta) n’avaient jamais échoué de sprint. Jamais! Ils ne pouvaient pas, ni n’utilisaient ce MOT dans leur culture. Je lui ai demandé catégoriquement : n’avez-vous jamais échoué un sprint ? Il a dit bien sûr qu’ils l’avaient. Plusieurs fois. Mais au lieu d’utiliser le terme échec, ils ont utilisé le terme ‘challenge’. De cette façon, les parties prenantes ne se feraient pas de fausse idée et ne mettraient pas en doute les compétences ou la motivation de l’équipe.
Nous avons tourné en rond pendant 10 à 15 minutes de plus dans notre discussion, mais nous n’avons jamais vraiment réglé nos différences. Nous avons simplement consenti à être en désaccord. Bien que ce ne soit pas un terriblement large abîme entre nous, je me rappelle distinctement revenir vers ma chambre en secouant la tête. Je n’avais tout simplement pas compris le grand cas fait de l’échec. De l’utilisation du mot. D’une équipe disant…nous avons échoué. Dans mon job de coach et dans mes « tâches journalières », j’ai pu diriger et développer nos idées pour que l’échec ne soit pas un gros mot. C’est-à-dire l’échec est bon. L’échec est ok. L’échec mène à l’amélioration. L’échec fait partie de la vie.
Aussi, dans ce billet, je veux discuter de l’échec depuis quelques perspectives différentes. La discussion n’est pas destinée à être complète. Au lieu de cela, je veux juste partager quelques pensées avec vous et vous faire réfléchir sur l’échec… sur comment vous le percevez dans votre organisation, quelle est votre tolérance à l’échec et reconsidérer vos réactions normales face à lui. Je pense que cela vous mènera aussi à considérer votre management de risque, parce que je pense que les deux sont inextricablement liés.
Coacher pour éviter l’échec
Dans son blog du 20 juin 2011, s’intitulant Coaching is Not Letting Your Teams Fail (Coacher c’est ne pas laisser vos équipes échouer), Giora Morein justifie que des coach agiles devraient amener ou guider leurs équipes loin de l’échec. Il donne l’analogie d’un Sherpa guidant des alpinistes. Et oui, dans l’exemple de l’alpinisme en montagne, je dois reconnaître que l’échec n’est probablement pas le résultat que nous voulons.
Cependant, dans les environnements qui ne mettent pas la vie en danger, je pense que je ne suis pas d’accord avec Giora. Je crois de tout cœur que l’échec peut en réalité être bon pour une équipe. Je pense aussi que le rôle du coach est d’aider une équipe à regarder sa performance de deux perspectives. La plus facile des deux est la perspective de succès. C’est la perspective où vous donnez un retour d’information positif à l’équipe; où vous leur dites qu’ils ont besoin de répéter les pratiques qui marchent pour eux. En fait, quelles pratiques ils doivent amplifier et faire « davantage » afin d’atteindre des résultats de plus en plus importants.
Ces conversations sont clairement plus faciles.
Mais en ce qui concerne la perspective d’échec ? Comme coach, fournissez-vous une critique constructive ? Montrez-vous à une équipe où ils ont trébuché ? Tant individuellement que comme une équipe ? Je pense que vous le devez. Mais certainement pas de façon malveillante ou maladroite. Je pense si vous coachez efficacement une équipe vous devez explorer leurs erreurs et faux pas avec la même passion et énergie que quand vous traitez leurs succès.
Et je ne pense pas que vous le faites tranquillement, en vous cachant derrière des portes et sans reconnaître de leurs challenges. Non. Je pense que vous l’approchez de façon totalement transparente et pratique. En établissant au départ que l’échec est apprécié et bien accueilli. Que depuis l’échec, vos équipes cherchent des possibilités d’amélioration et avancent rapidement vers l’atteinte de meilleurs résultats.
Exposition Agile
Dans des équipes agiles, il y a deux cérémonies clés qui sont concentrées sur les résultats réussis ou pas de l’équipe. Dans Scrum, c’est la Revue de Sprint (la démonstration) et la Rétrospective de Sprint (les leçons apprises). Typiquement la revue de sprint est exposée au monde, donc vous pourriez vouloir être prudents sur comment vous énoncez vos échecs – pour que les parties prenantes n’interprètent pas mal l’impact ou l’effort consenti par l’équipe. Néanmoins, je crois que vous devriez déclarer des sprints succès ou échecs pendant l’introduction à la revue d’équipes.
Dans Scrum, c’est le rôle des Propriétaires de Produit de déterminer cela. Et c’est relatif aux objectifs sur lesquels l’équipe s’est engagée au début du sprint. On espère que ces objectifs étaient assez flexibles pour permettre à l’équipe d’ajuster leur travail pour les atteindre avec créativité.
Par exemple, je pense qu’un très mauvais objectif de sprint est quelque chose autour de l’équipe livrant un nombre d’histoires utilisateur – ou autres indicateurs d’exécution par cœur. Je pense que cela mène à un en-sablage potentiel de la part de l’équipe pour atteindre un but numérique plutôt que de penser au vrai problème qu’ils essayent de résoudre. Au lieu de cela, je pense que de meilleurs buts tournent autour de la réalisation d’une sorte de démonstration d’un comportement qui résout un jeu spécifique de problèmes clients. Donc le succès est mesuré sur comment l’équipe a respecté l’esprit de l’objectif et combien ils ont appliqué les principes agiles dans leur exécution.
Par exemple, j’ai vu des équipes qui s’engagent sur 10 histoires utilisateur, mais qui avaient 3 jours de temps mort à la fin de leur sprint, rater leur sprint. Pour sûr, ils ont bien livré par rapport à leur engagement, mais leur engagement était faussé. Ils s’étaient protégés et avait surestimé. De plus, ils n’ont pas fait part de leur capacité supplémentaire disponible à leur Propriétaire de Produit ni demandé davantage de travail dans leur sprint. Au lieu de cela ils ont planifié d’avance ou « plaqué or » leurs produits.
J’ai aussi vu des équipes qui s’engagent sur 10 histoires, mais en livrent 7 et ont un sprint très réussi. En cela qu’ils travaillent dur dans la complexité et l’adversité. Ils sont incroyablement transparents et engagent leur Propriétaire de Produit à faire des ajustements quotidiens sur les priorités en fonction de leur actuelle compréhension de leur capacité. Et en tant qu’équipe, bien qu’ils n’aient pas livré la quantité prévue à l’origine, ce qu’ils ont vraiment livré est aligné sur leurs objectifs et respecte l’esprit et l’intention du Propriétaire de Produit.
Ces deux cas devraient être discutés pendant la rétrospective des équipes et les façons de s’améliorer discutées. Pas de petite façon et sans ignorer les premiers troubles du comportement de l’équipe. Non. Tout cela, le bon, le mauvais (erreurs et échecs) et idées d’amélioration significatives, sera discuté pour que l’équipe décide de quels points sont dignes de leur attention pour amélioration dans le sprint suivant.
Mais l’échec est-il apprécié ?
En continuant sur mon exemple de coaching précédent, je me souviens qu’il n’y a pas longtemps je parlais à un groupe de nos Scrum Masters dans mon « travail de jour » chez iContact. Si vous ne connaissez pas Scrum, le Scrum Master est le coach et le guide principal et la voix du leadership agile dans l’équipe Scrum agile. Il est aussi responsable d’entretenir des valeurs agiles clés dans l’équipe et e la performance générale des équipes. Ce que j’entends par cela est qu’il guide les équipes vers une performance qui s’améliore dans la durée. Posant continuellement des questions comme : son équipe s’améliore-t-elle dans sa performance globale ? Sa vitesse s’améliore-t-elle ? Sa qualité de travail s’améliore-t-elle ? La collaboration et le travail en équipe s’améliorent-ils ? Et, leur focus est-il sur l’amélioration de la valeur livrée pour le client ?
Donc mon point auprès des Scrum Masters était que j’estimais que nous n’avions pas échoué depuis quelque temps. J’ai défini l’échec dans ce cas comme un échec de sprint ou un incident dans lequel une équipe s’est essentiellement heurtée à un obstacle et a eu besoin de re-planifier ou revoir l’alignement son sprint.
Ils ont tous été d’accord avec moi que les choses s’étaient déroulées sans à-coups. Et j’ai reçu plus que quelques regards interrogateurs fixes quant à pourquoi c’était un problème. J’ai essayé d’être prudent dans ma réponse, mais ma préoccupation était qu’il se pourrait que nous la jouions un peu trop sûrs. Que nous devenions complaisants dans nos pratiques agiles et que nous ne nous challengions pas assez. Que nous ne tentions rien. Et ne courrions pas de risques.
J’ai expliqué que ces caractéristiques sont fondamentales pour la croissance et la progression d’équipes agiles. Et le fait que nous ne rencontrions pas d’échecs indique que nous avons atteint un plateau dans notre croissance et notre performance. J’ai estimé que c’était un problème…et pour lequel j’ai demandé s’ils pourraient obtenir davantage d’échecs des équipes.
Pouvez-vous imaginer le reste de cette discussion ?
Me voilà le Directeur de R&D dans une société qui réussit en train de parler à mon équipe de Scrum Masters et leur demander d’amener plus d’échecs, pour inciter leurs équipes à davantage de prise de risques et inspirer des objectifs plus agressifs. Le point que j’essaye de faire passer est que j’apprécie vraiment l’échec. Que j’ai appris à le voir comme un critère critique de succès et que son absence est un problème pour moi. Je me demande combien d’organisations et de leaders ont la même position.
La notion de « Chuter en avant »
Un de mes auteurs préférés est John C. Maxwell. Il est relativement bien connu comme un coach en leadership et un prolifique auteur avec plus de 50 livres sur divers sujets de leadership. Il a un fort contexte Chrétien dans sa vie et dans son écriture, mais si vous n’êtes pas aussi enclins, ne laissez pas cela vous rebuter. Il maîtrise pleinement l’art du leadership.
Il y a quelques années il a publié un livre : Failing Forward—Turning Mistakes Into Stepping Stones to Success. Dans celui-ci, il souligne l’échec comme un facteur de réelle transformation dans nos vies personnelles, professionnelles et en équipes. Mais il place soigneusement l’échec dans une position d’avancée. Au lieu de voir l’échec comme un état final négatif et nous en plaindre, nous devrions l’embrasser comme une expérience à portée pédagogique positive. Que nous nous « penchions en avant » en démultipliant les leçons apprises pour nous améliorer.
Je ne pense pas que Maxwell souffle simplement un nuage de fumée positive dans notre direction. L’histoire est clairement encombrée d’exemples de succès qui ont été inspirés, forgés et durcis par le feu de l’échec. Thomas Edison en est un exemple célèbre quand il a persévéré pour inventer l’ampoule électrique.
Dans mon coaching agile j’utilise de manière consistante la terminologie « chuter en avant » quand je discute des échecs d’équipes. Oui, je veux qu’une équipe soit honnête avec elle-même et reconnaisse qu’elle a échoué. Mais je veux aussi que ses membres embrassent leurs erreurs au lieu de devenir défensifs, blâmer d’autres personnes ou être dans le plein déni. Et je veux que leur position les fasse se « pencher vers l’avant ». Désireux d’essayer quelque chose de nouveau qui amènera des résultats différents. Sans avoir peur de l’échec.
Je constate qu’en utilisant cette terminologie, j’aide des équipes à comprendre la nature de l’échec et à se comporter convenablement. Mais au-delà de la terminologie, les leaderships de projet et fonctionnel doivent aussi pleinement supporter l’idée. CE qui signifie que l’équipe de direction toute entière doit supporter l’échec. Voilà…je l’ai dit.
En conclusion – Mais, je suis un peu étrange …
Tout ceci étant dit, je me demande si j’ai une vue étrange et largement minoritaire envers l’échec ? Je me demande si la bonne réponse doit en effet de le craindre, de nier son existence, de passer d’innombrables heures à essayer de le prévoir, de ne jamais le mentionner en public. Est-ce que de telles actions sont les bonnes réponses ?
À cette fin, je ferme ce billet avec une requête auprès de tous les lecteurs. J’ai préparé une brève enquête, que je voudrais vous proposer. Je sais, je sais, vous êtes occupés. Mais je pense vraiment que vos idées seront ici utiles. L’enquête est centrée sur la construction d’une vue sur l’acceptation organisationnelle, de groupe/équipe et individuelle de l’échec et du risque. J’essaye d’obtenir à une compréhension profonde de cette acceptation et aussi de ses causes racines. Même si je suis particulièrement intéressé par les équipes agiles, ne laissez pas votre manque d’expérience agile vous empêcher de répondre.
Agile et Scrum ont révolutionné le paysage de l’industrie informatique. La plupart des sociétés ont déjà adopté Agile ou se rapprochent de ces méthodes. Cependant, la réalité est que la plupart considèrent encore Agile comme une forme de développement en cascade itératif plutôt que d’accepter ses pratiques radicalement différentes.
Souvent une personne mentionne un point et cela devient une discussion entre deux ou trois personnes. Il est important de terminer cette conversation, mais il est encore plus important que cette session se tienne hors réunion pour permettre un échange correct. Même si le point impacte toute l’équipe, une discussion séparée pour débattre de ce point est nécessaire. Le Daily Stand-up ne devraient pas être utilisés pour débattre de tels sujets, se focaliser sur l’avancement des tâches est de la plus haute importance.
Souvent le ScrumMaster assume que l’équipe est concentrée sur le boulot en cours et garde donc par devers lui les discussions sur de nouveaux développements discutés avec le client ou autres détails. Ceci est fatal. Il est important que cette information soit partagée avec l’équipe pour que tous soient au courant. Rester proche du client et de son monde contribue largement au succès de l’équipe Scrum.
DantotsuPM.com 