Peu importe combien votre équipe est performante, il y a toujours une opportunité d’amélioraation. L’indice de bonheur est un outil des rétrospectives agile, qui mesure le bonheur des équipes agiles. Luis Gonçalves le partage dans le livre écrit avec Ben Linder « Getting Value out of Agile Retrospectives. »
Le but de cet exercice est d’avoir une représentation graphique des émotions des membres de l’équipe pendant un Sprint. Ce type d’informations aide l’équipe à identifier ce qui affecte sa performance pendant le Sprint. Indépendamment du problème qu’expérience l’équipe, cet exercice les aide à révéler les émotions d’équipe directement en cet endroit.
Quand utiliseriez-vous cette technique ?
C’est certainement approprié pour une équipe qui passe à travers beaucoup d’émotions différentes (positives ou négatives) pendant un sprint. Cela leur bénéficie quand ils veulent en évaluer les conséquences ou quand l’équipe a plusieurs défis dans le Sprint et voudrait comprendre comment ces problèmes sont apparus.
L’indice de bonheur est approprié pour n’importe quelle équipe. Il n’exige pas de niveau de maturité spécifique. L’exercice peut être appliqué tant aux équipes à distance qu’à celles réunies en un même lieu.
Comment le réaliser ?
Prenez une page blanche A4 et quelques post-it. Divisez le papier sur 2 parties/axe – positif et négatif. Graduez ensuite l’axe des abscisses en fonction des jours de sprint.
Il y a 2 façons de conduire l’exercice
Option 1 : L’exercice est fait pendant la rétrospective avec toute l’équipe
Créez de petits groupes de 2-3 personnes. Demandez-leurs de faire une session de brainstorming sur les événements ou les situations qui se sont produites pendant le dernier sprint. Ensuite, demandez aux groupes de créer une représentation graphique des niveaux émotionnels pour les situations sur lesquels ils ont fait du brainstorming. Quand tous les groupes ont terminé, compilez une représentation de tous les groupes sur un seul graphique. N’oubliez pas de mettre une explication sur chaque émotion différente.
Option 2 : L’exercice est réalisé par petits bouts pendant le sprint
Au lieu d’une équipe dessinant le graphique émotionnel, vous laissez chaque individu dessiner un graphe avec son propre niveau d’émotion à la fin de chaque journée de travail. Cette approche permet de s’assurer que tous les événements ou situations sont couverts et aucun n’est oublié.
Les deux options marchent bien!
Vous aurez une belle vue de ce qui est arrivée pendant le sprint. Ces informations aident le facilitateur de la rétrospective dans l’identification des situations qui devraient être répétées et des événements qui causent des problèmes ou le retard de l’équipe.
Microsoft est partenaire de DantotsuPM
De plus, vous pouvez aussi utiliser des techniques d’analyse de cause racine pour identifier les problèmes fondamentaux.
partagez ce billet avec vos amis, collègues et relations professionnelles
La technique Scrum of Scrums (SoS) sert à augmenter la portée de Scrum et autres techniques Agiles et les appliquer à de plus grands efforts. Sur le papier, le SoS est une simple extrapolation des réunions quotidiennes de Scrum ou stand-up meeting qui sont devenues le label de la pratique Agile. Une typique réunion debout se produit chaque jour pour que tous les membres de l’équipe puissent coordonner et planifier les activités du jour. Classiquement, l’équipe utilise la technique des trois questions pour organiser la réunion. De la même manière, une session Scrum of Scrums typique agit comme un focus pour aider à synchroniser une équipe d’équipes ou même plusieurs équipes d’équipes.
Il y a quatre basiques pour SoS qui doivent être compris avant toute adaptation.
1. Qui participe
Il y a deux écoles de pensée dans le choix des participants au SoS. La première (et plus commune) école suggère que le Scrum Master soit présent lors du SoS. Le Scaled Agile Framework Enterprise (SAFe) est un exemple d’une méthodologie qui met à profit le Scrum Master tant pendant l’événement de planification que pendant l’incrément de programme. Alors que le deuxième groupe adopte une approche plus égalitaire (probablement plus pragmatique) permettant à chaque équipe de choisir un participant qui peut le plus facilement transmettre ou comprendre que les problèmes actuels de l’équipe et du plus grand groupe à cet instant. Par exemple, si les décisions de conception sont primordiales, peut-être des membres de l’équipe avec la grande compréhension UX. Dans ce scénario, les participants varieraient au fil du temps.
2. Qui facilite
Pour de petits SoS, par exemple une poignée d’équipes co-localisées, une facilitation peut ne pas être exigée. Le SoS peut s’auto-organiser et exécuter la réunion avec peu de facilitation additionnelle. Cependant, comme le nombre de participants augmente (je limite les réunions SoS en utilisant la même règle 5 à 9 membres utilisée dans les équipes Scrum) ou comme la distribution géographique des membres s’accroit, la facilitation devient plus importante. Les facilitateurs aident l’équipe à utiliser la pratique du SoS, s’assurent que la logistique est en place et gèrent le temps. Dans de plus grands efforts, un Directeur de Programmes fournit souvent la facilitation, ou si vous pratiquez SAFe, le Release Train Engineer joue ce rôle de facilitateur.
3. Fréquence
Image courtesy of pakorn / FreeDigitalPhotos.net
Le Scrum of Scrums suit souvent le même modèle que la réunion quotidienne de Scrum/Stand-Up. Un deuxième modèle de fréquence est basée sur le niveau de risque; la fréquence des réunions SoS varient en fonction du besoin. Tôt dans un projet le SoS se tient quotidiennement comme les équipes se forment, se trouvent et que les premières décisions sont construites. La réunion SoS passe à deux fois par semaine au milieu du projet et revient ensuite à quotidienne comme une fin de release approche.
4. Format
Les réunions quotidiennes debout déroulent généralement la classique approche avec trois questions (Qu’ai-je fait ? Que vais-je faire ? Et quels sont mes points de blocage ?).
La réunion Scrum of Scrums suit généralement un format TRÈS SEMBLABLE avec chaque participant qui répond aux quatre questions suivantes :
Qu’est-ce que mon équipe a fait depuis la dernière réunion ?
Que fera-t-elle avant que nous ne nous rencontrions de nouveau ?
Mon équipe rencontre-t-elle des points de blocage ?
Mon équipe va-t-elle délivrer quelque chose qui est sur le chemin d’une autre équipe ?
La réunion suit la même approche : chaque participant interagit à tour de rôle avec les autres. Le facilitateur (si utilisé) ne devrait jamais être au centre de la réunion, et le SoS ne devrait pas dériver en une réunion de statut d’avancement.
Le stand-up quotidien et le SoS Sont des réunions très semblables. Les deux réunions sont tenues pour partager des informations, coordonner des activités et identifier des problèmes. Le périmètre de la réunion SoS est plus large qu’une seule équipe et cette réunion fournit la coordination et les activités de planification dans et transverses aux équipes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Agile… again… when will this hype finally be over ?!
PMI Belgium Chaper Web Site
Well… probably never.
It is not even a hype. It is just sound project management.
There have always been aspects of agile, and there will always be aspects of agile. In any project that is somehow successful.
This session will walk you through a series of different types of projects each time picking out one (or more) aspects of agile. By the end of this chapter event you will have a clearer view of how agile and traditional project management (can) reinforce one another.
Steven Deneir will share his vast experience of combining Agile with traditional project management practices. Next to managing projects and programmes himself, Steven gives certified training and coaching workshops for companies. He’s also experienced in doing maturity assessments and giving speeches at conferences. He holds many certificates of Portfolio, Programme and Project Management specialties.
Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.
Amy Thompson
Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?
J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.
Partenaire de DantotsuPM
Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.
L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)
partagez ce billet avec vos amis, collègues et relations professionnelles
impact objectif des méthodes agiles, de l’externalisation et de l’offshoring: des évidences mais aussi de l’inattendu !
Rassemblant les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises, cette étude de CAST sur la qualité logicielle des applications (CRASH), présente l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.
L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.
Les principales conclusions sont pour certaines évidentes, d’autres bien plus surprenantes.
l’intégrité architecturale d’une application affecte sa sécurité,
les applications servant plus d’utilisateurs ont tendance à être de meilleure qualité,
la maturité des processus (niveau CMM) affecte la qualité générale du code,
les méthodes hybrides Agile/Waterfall produisent de meilleurs résultats que les méthodes agiles pures,
les équipes internes et externalisées fournissent la même qualité de code,
l’offshoring impacte la robustesse et l’évolutivité des applications.
Exploring the Role of Agile Approaches for the Management of Projects
Although agile-related topics are discussed in computer science and information management literature primarily regarding software development (see Cardozo et al., 2010), the concept has also been applied to non-IT related projects, notably new product development (Ries, 2013; Blank, 2010). Application of the agile concept has been suggested for other types of projects (Conforto et al., 2014; Ktata & Lévesque, 2009).
It is not clear how the agile concept translates in domains outside of software development.
Does it replace or negate traditional project management concerns with risk, scheduling, metrics, and execution, or does it shift how we think about these and necessitate new techniques and approaches?
Does it translate differently into different domains, for example, construction versus new product development?
This special issue of Project Management Journal® seeks a wide range of papers that draw on diverse institutional settings, theories, and approaches to understand the different aspects of agile-based process models and methods as applied to project management both within and outside the domain of software development. The Project Management Journal’s mission is to shape world thinking on the need for and impact of managing projects by publishing cutting-edge research to advance theory and evidence-based practice.
Check ou the details of the potential topics for your papers’ proposals here.
DEADLINES FOR PAPER SUBMISSION:
1 June 2016: Submit proposal of 2,000 words, including a tentative title, aim, and nature of the submission (conceptual or empirical).
1 September 2016: Authors informed of decision.
1 February 2017: Submit full paper of up to 10,000 words.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pourquoi visionner une conférence sur un thème a priori déjà beaucoup commenté ? Qui plus est, pour une durée de 40 minutes… et en anglais !
Parce que c’est LA conférence qui discute de l’essence même des principes fondateurs de ce que l’on appelle maintenant « l’agilité ». L’orateur, Dave Thomas est ici tout à fait légitime puisqu’il revient sur la réunion, à laquelle il participait en 1999 qui donnait lieu au « Manifesto for agile software development ».
Dans la première partie, Dave porte un regard sur ce qu’est devenu le mouvement agile, et il analyse comment certains ont perdu de vue ce qu’est ou ce que n’est pas Agile, il se livre à une sorte de déconstruction qui lui fait dire de manière provocatrice : « Agile is Dead ».
C’est pour mieux expliquer, dans la seconde partie l’esprit même de la démarche « agile » et rappeler sa pertinence tout à fait actuelle et valide.
C’est un vrai plaisir à regarder, la présentation est très claire, les arguments percutants et les idées développées sont simples, ce qui permet à cette conférence de se classer parmi celles qui nous laissent quelque chose, et qui peuvent réconcilier avec la démarche agile ceux qui pourraient trouver que la notion est galvaudée.
Un recentrage qui fait du bien !
Un billet de Jean-Michel Torres que je remercie vivement car je suis certain que vous serez nombreux comme lui (et moi-même) à apprécier cette vidéo.
partagez ce billet avec vos amis, collègues et relations professionnelles
J’ai choisi ces articles récents car ils racontent tous une histoire semblable sur l’importance de l’agilité dans le business en tant que partie essentielle de gagner un avantage compétitif. Ils partagent aussi ma propre philosophie qui est que cette agilité business est l’objectif final pas seulement le développement logiciel agile. Donc les méthodes Agiles devraient être considérées pour ce qu’elles sont : des contributions à une agilité globale de l’organisation.
L’étude du management de projet Agile fournit une compréhension de base d’Agile qui vous permet d’appliquer Agile à tous les aspects de votre rôle et votre organisation:
1. McKinsey fournit le cas d’affaire pour être Agile, mais il met aussi en évidence l’importance de processus métier cohérents et clairs qui permettent à l’organisation de répondre de façon agile sans mettre à risque tout ce qu’elle a déjà réalisé.
2. Un rapport détaillé d’Accenture met en avant l’écosystème business dans son ensemble (fournisseurs, collaborateurs, clients) doit devenir Agile. Il met aussi en évidence comment être agile est maintenant considéré par les dirigeants d’entreprises comme une caractéristique essentielle de réussite des organisations.
3. Forbes relève un exemple d’organisation qui a développé ses approches agiles sur la base du développement logiciel agile et de la conduite de projet agile.
PRINCE2 Agile was released by AXELOS in June this year. The guidance combines the flexibility and responsiveness of agile delivery with the established and proven best practice framework of the world’s most recognized project management method.
The guidance is designed to help experienced PRINCE2® practitioners tailor management controls for agile development, while helping ‘agilistas’ understand PRINCE2 governance requirements.
Accueil et Inscriptions
Further information is available via the APMG and AXELOS websites.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Nouvel atelier de Claude Emond en Gestion de Projet Agile des projets d’innovation et de développement de produits, en collaboration avec L’IDP.
Une approche comme toujours originale de notre ami Claude Emond: Sur 3 journées (4, 9 et 16 nov 2015) incluant, pour chaque participant, 3 heures de coaching personnel sur un projet de leur choix, pendant, entre et après chaque jour de formation.
Inscriptions et Détails
Objectif de cette formation-action
Outiller les gestionnaires de projets en développement de produits sur les techniques de gestion agile. Cette formation leur permettra d’accélérer leur projet, de mieux mobiliser leur équipe de développement et ainsi maximiser les bénéfices et le retour sur investissement.
Bénéfices pour les entreprises participantes
Préciser le rôle du chef de projets, en mode agile
Augmenter le taux de succès de vos projets de développement de produits
Maîtriser le savoir-faire qui permettra d’accroître votre efficacité en gestion de projets
Développer vos compétences pour mobiliser et guider les équipes de projets agiles vers le succès
Intégrer de nouvelles connaissances par la formation-action dans le cadre d’un projet en cours dans votre entreprise
Profiter de l’encadrement des formateurs entre les rencontres pour maîtriser les nouveaux outils et mener à bien votre projet ;
Développer les habiletés de leadership de vos chefs de projets implanter des outils de suivi pour livrer vos projets en respectant les coûts et les délais.
Qui devrait participer à ce programme de formation ?
Ce programme de formation spécialisé (voir la brochure détaillée) s’adresse aux personnes jouant le rôle de chefs de projets, ou membre d’équipe de projet, dans le cadre de projets de développement de produits et/ou de services.
Il est destiné à tous ceux qui désirent approfondir par l’action leurs connaissances en gestion de projets de développement de produits.
Une méthodologie ancrée dans l’action !
Ce programme unique de formation combine la présentation de notions théoriques et d’outils pratiques. Des exercices permettent d’appliquer les enseignements et d’utiliser les nouveaux outils dans le cadre d’un projet actuellement en cours dans votre entreprise. Entre les rencontres, vous devrez accomplir différentes tâches avec les membres de votre équipe de projet tout en bénéficiant d’une aide personnalisée de la part du formateur.
Voici ce que nous propose Tom Wujec dans ce très simple exercice !
Plus surprenant encore, les résultats obtenus par diverses populations lorsqu’elles sont confrontés à ce challenge. Qui l’emporte entre des ingénieurs, architectes, PDGs, secrétaires, élèves de maternelle… ?
En fait, c’est la méthode qui importe le plus et dans le cas de cette exercice, une approche Agile basée sur des expérimentations rapides et répétées pour trouver la meilleure piste et l’exploiter pleinement.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici une vidéo exceptionnelle de Henrik Kniberg 15 minutes expliquant et illustrant le développement logiciel Agile du point de vue du métier.
Certains d’entre vous connaissent sans doute déjà cette vidéo. Cependant, cette version a été doublée en Français par FlorentLothon qui trouvait difficile de lire la version originale sous titrée et apprécier les illustrations en même temps.
L’ »étoile de mer » est une excellente activité lors de la collecte de données pour favoriser la réflexion autour des pratiques et de la valeur que l’équipe en retire. Elle aide des membres de l’équipe à comprendre la valeur perçue par chacun sur ces pratiques.
L’étoile de mer divise le tableau blanc en 5 zones :
Continuez à Faire – quelque chose que l’équipe réussit bien et dont vous reconnaissez la valeur.
Moins de – quelque chose de déjà fait; vous y constatez une certaine valeur, mais vous souhaitez le réduire un peu.
Plus de – quelque chose de déjà fait; et dont vous pensez qu’elle apportera encore plus de valeur si davantage utilisée.
Arrêter de Faire – quelque chose qui n’apporte pas de valeur, ou encore pire, qui empêche de progresser.
Commencer à Faire – une nouvelle idée, ou quelque chose vous avez vu marcher auparavant et que vous voudriez mettre sur la table de discussion.
La conférence sur le Management de Portefeuille de projets informatiques (« IT Project Portfolio Management ») s’est tenue fin juin à Berlin. Rares sont les fois où j’ai ramené un message si clair après deux journées de conférences. Certes, il y avait plus de 20 présentations et ateliers qui ont partagé une variété d’expériences et de projets. Mais chaque présentation et discussion mettait en avant un même point critique : les entreprises et leurs portefeuilles de projet doivent devenir plus agiles.
Partenaire de DantotsuPM
Management de Projets Agile au niveau de l’entreprise
Les processus agiles pour les projets individuels sont devenus une banalité dans le management de projet.
Pour la plupart des grandes sociétés, c’est simplement une question de volume : chez certains, seulement 10 à 15 % des projets sont organisés utilisant des processus agiles, tandis que beaucoup d’autres gèrent déjà plus de 50 % de leurs projets de cette façon.
Au niveau stratégique il est important par contre de comprendre ce à quoi le Management Agile de portefeuille de projets peut ressembler au niveau de l’entreprise.
Selon Campana & Schott, on peut considérer les options suivantes:
Get the referential
Aucune planification de A à Z des budgets et ressources (particulièrement en ce qui concerne les budgets annuels)
Des réajustements plus modestes mais plus fréquents des portefeuilles
Le passage d’une approche « Design to budget » au Management de portefeuille : moins de détails dans le cahier des charges du projet, au lieu de cela les budgets sont alloués à des thèmes spécifiques, des initiatives ou « des produits »
Au premier rang les bénéfices, c’est-à-dire quels budgets sont alloués à quels profits attendus ? Ceci peut être réalisé avec des cas d’affaires qui sont alors utilisés comme une base pour prioriser les budgets
Une considération est portée aux dépendances pas seulement dans les projets mais aussi entre les projets : comment ces dépendances sont-elles incluses dans la priorisation et des préparatifs de prise de décision ?
Plus d’accent sur la communication et les échanges d’informations entre projets
Des sociétés agiles ont besoin des bons collaborateurs
Étonnamment, pratiquement toutes les présentations ont fini par souligner le même point : des compétences supplémentaires seront exigées des collaborateur dans le futur proche. Elles incluent de nouvelles qualifications pertinentes dans les projets, comme « Data Scientists » ces experts qui tirent des modèles économiques et des relations de travail de grands entrepôts de données.
Mais surtout, les sociétés agiles ont besoin des collaborateurs qui ont été familiarisés avec des environnements très exigeants. C’est une raison pour laquelle de grandes sociétés incluant Daimler et Microsoft investissent dans des startups, à savoir « injecter » les collaborateurs de ces startups dans leur propre main-d’œuvre.
Sans ces ‘perturbations’ externes, la culture d’entreprise de la société ne pourrait pas répondre assez rapidement aux nouvelles Meta Compétences comme l’orientation client systématique ou l’examen minutieux permanent et constructif de modèles économiques. L’exemple du « crowd-soucing interne » illustre la combinaison des deux mondes : une certaine partie du budget informatique est quasiment distribué aux collaborateurs. Ils peuvent alors assigner leur propre budget aux projets de leur choix et produisent ainsi le portefeuille qui est le plus prometteur de leur propre point de vue : celui-ci est porteur de très forte valeur.
Partenaire de DantotsuPM
Agile est le « nouveau normal »
Ce n’est pas seulement les projets qui sont agiles. Dans l’avenir, le focus sera sur la construction de management de portefeuille de projet plus agile au niveau de la société et donner davantage de pouvoir aux collaborateurs dans l’organisation qui implémenteront la transformation agile.
PS : Ceci vous donne-t-il matière à réflexion sur ce que pourrait être votre propre futur PPM ?
Partenaire de DantotsuPM, LE blog du management de projet
partagez ce billet avec vos amis, collègues et relations professionnelles
Tous les ans, la Scrum Alliance réalise une enquête sur l’utilisation et les évolutions de Scrum et en résume les résultats dans le State of Scrum report.
On y trouve les taux d’adoption en entreprise (5000 réponses de 108 pays et 14 industries), les tendances actuelles, les prochaines évolutions telles que perçues par les pratiquants de la méthode.
Certaines statistiques sont révélatrices:
87% estiment que Scrum améliore la qualité de vie au travail
56% utilisent les cérémonies de Scrum avec discipline
71% pensent que leur utilisation de Scrum crée des tensions avec d’autres parties de l’organisation qui ne l’utilisent pas
59% of des ScrumMasters certifiés et 81% pensent que cela les aide à améliorer leurs pratiques
93% des projets Scrum supervisés par un PMO réussissent
L’essayer c’est l’adopter puisque 95% vont continuer à utiliser Scrum
Does it replace or negate traditional project management concerns with risk, scheduling, metrics, and execution, or does it shift how we think about these and necessitate new techniques and approaches?
PRINCE2 Agile was released by AXELOS in June this year. The guidance combines the flexibility and responsiveness of agile delivery with the established and proven best practice framework of the world’s most recognized project management method.
1. Dessin pour guider la session
Préciser le rôle du chef de projets, en mode agile
Qui devrait participer à ce programme de formation ?
Voici un exemple de rétrospective de Sprint d’une petite d’équipe. D’abord l’équipe écrit les notes: les billets bleus.
Puis l’équipe discute vraiment de chaque note et ajoute les mesures à prendre: les billets jaunes.
Simple et efficace ?
Étonnamment, pratiquement toutes les présentations ont fini par souligner le même point : des compétences supplémentaires seront exigées des collaborateur dans le futur proche. Elles incluent de nouvelles qualifications pertinentes dans les projets, comme « Data Scientists » ces experts qui tirent des modèles économiques et des relations de travail de grands entrepôts de données.
DantotsuPM.com 