Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).
Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets
Le manque de transparence cause des malentendus et des conflits.
Cependant, générer de la transparence a un coût.
Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.
Plusieurs des techniques les plus communes pour générer de la transparence
#1 – Le Contrat
Spécifiez ce qui peut et doit être partagé dans le contrat. Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre. Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu). Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.
#2 – Un Plan construit conjointement
Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres. La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur des risques et communiquer les dépendances en temps réel.
Matchware est partenaire de DantotsuPM
#3 – Des Cérémonies communes
Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies). Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives. Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.
#4 – Des Ateliers de mûrissement des exigences et de design
Collecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.
#5 – Des Modèles de design
L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.
Facile ET difficile à la fois
une plus grande transparence comme base de relations et de travail
Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les projets agiles sont basés sur le concept que livrer une solution imparfaite au business le jour promis est plus important que livrer une solution parfaite en retard.
Avec Agile, tenir vos promesses sur quand quelque chose sera disponible pour être utilisé en production est au cœur de la réalisation de bénéfices. Chaque élément fourni, même s’il a un nombre minimal de fonctionnalités peut résoudre un problème métier. Focalisez votre équipe sur faire utiliser leur livrable en production, en sachant qu’ils pourront ajouter davantage de fonctionnalités plus tard.
Il y a une fausse idée répandue qui est que ceux travaillant dans des équipes Agiles ne planifient rien.
Alors que les compétences de planification y sont plus importantes que dans l’approche prédictive « en cascade » (PRINCE2 ®) pour les projets parce que :
La planification est plus fréquente
La planification est faite en collaboration, impliquant chacun qui contribue au projet
Les plans y sont un mécanisme essentiel de suivi du progrès
QRP est partenaire de DantotsuPMaux fausses croyances sur Agile
Pour ces raisons, les compétences de planification sont critiques au travail Agile efficace. La planification détaillée du projet de bout en bout au début ne fait pas partie Agile. Au lieu de cela, il y a la planification fréquente et la re-planification pendant tout le cycle de vie du projet. Quand un élément de la solution est livré au business, le focus se porte sur la planification de la livraison suivante.
Objectifs de la planification
Pour respecter l’importance de planification, j’encourage mes équipes à se mettre d’accord sur un jeu commun d’objectifs pour leurs sessions de planification.
Utilisez ceux-ci pour débuter avec votre équipe :
Assurons-nous que nous livrons une solution utilisable et de valeur
Assurons-nous que nous n’avons rien oublié
Donnons la priorité au travail le plus important en premier
Allouons le travail aux meilleurs de l’équipe pour le faire
Clarifions l’ordre/le séquencement pour réaliser des économies d’efforts
Créons un visuel qui permette aux autres de voir ce que nous faisons et quand afin qu’ils puissent aligner leur travail avec le nôtre
Utilisons ce visuel pour fournir un suivi facile de notre progression sans devoir écrire de rapport d’avancement
CertYou est partenaire de DantotsuPM
Ordre du jour de la planification
Supportez ces objectifs en définissant comment va se dérouler chaque session de planification.
J’encourage mes équipes à utiliser un ordre du jour standard pour tous les événements de planification.
Utilisez cet ordre du jour type pour encourager votre équipe à faire de même :
Examiner les résultats de notre session de brainstorming préparatoire.
Appliquer les critères de priorisation pour créer une liste agréée de travail pour ce sprint
Définir ensemble qui va construire et qui va tester le résultat.
Chaque personne crée son propre échéancier pour le sprint en s’assurant que les must have ne dépasse pas les 60 % du travail.
Chacun effectue un contrôle croisé de son échéancier avec la personne testant son travail.
Réserver le temps nécessaire dans son agenda pour réaliser le travail
Se mettre d’accord sur comment vous partagerez le progrès avec l’autre
Matchware est partenaire de DantotsuPM
Pour plus d’astuces sur l’application des pratiques de travail Agile dans la vraie vie, abonnez-vous au bulletin de Melanie ou visitez son site Web.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’approche Agile signifie que les idées sont très tôt dans leur développement distribuées au business pour qu’ils les essayent. Leurs retours sont essentiels au concept et pour ajouter plus de fonctionnalités.
CertYou est partenaire de DantotsuPM
Mais…Je commence à se demander combien d’entre nous sont vraiment prêts pour ces retours. Après tout, c’est souvent un mélange d’éloges et de critiques, qui penche trop souvent vers la critique :
Il ne fait pas ce que nous avons dit !
Où est la fonctionnalité X ?
J’ai pensé que ça allait remplacer Y mais maintenant il ne semble pas que ce soit le cas ?
Il ne se connecte pas avec Z donc nous aurons besoin d’un processus manuel pour enregistrer ces données!
Ceci vous semble-t-il familier ? Il est difficile d’aller chercher des réactions, mais si ce doit être utile, je dois le faire dans un état d’esprit de curiosité.
Curiosité
La curiosité est une belle qualité plutôt qu’un vilain défaut.
Je dois commencer le processus avec un véritable intérêt pour ce que je vais entendre. Et pour obtenir les retours les plus utiles, je dois entendre des perspectives différentes. J’ai besoin de courage pour dépasser mes contacts habituels et trouver un ensemble le plus diversifié possible de voix. Après tout, plus la personne donnant les réactions a une expérience et un contexte différents des miens plus ils vont possiblement poser des yeux neufs sur la question.
Je viens de finir de lire l’excellent livre par Michelle Obama où elle fait ces remarques “la similarité amène davantage de similarité, jusqu’à ce que vous fassiez un effort réfléchi pour la neutraliser.” Elle parlait des recruteurs à la Maison Blanche mais c’est vrai de tous ceux avec qui nous travaillons.
Mes efforts pour neutraliser la similarité impliquent un effort conscient de reconnaître mes expériences et rechercher des personnes qui en ont de différentes. À moins que je ne sois très honnête avec moi-même sur mon contexte, mes accomplissements, mon chemin de vie, il est ardu de reconnaître l’existence de quoi que ce soit de différent.
Cherchez votre opposé
Beaucoup de mes clients essaye d’encourager cette auto-évaluation sur les biais cognitifs inconscients, qui semble vraiment être la tendance. Ce que je retiens de cela est “cherchez l’opposé” car semble être une bonne place pour commencer :
Je cherche des personnes qui ont la moitié de mon âge.
Je cherche des personnes sans diplômes.
Je cherche des personnes qui ont changé d’industries de multiples fois.
Je cherche des personnes qui ont travaillé pour le même employeur pendant des décennies.
Je cherche des personnes qui ont vécu et ont travaillé dans des pays différents.
Comme nous changeons de saison, je veux vous soumettre le défi suivant. Sortez et faites-vous de nouveaux contacts !
FDF est partenaire de DantotsuPM
Commencez à discuter avec de nouvelles personnes
Au lieu de regarder votre montre, engagez la conversation avec vos voisins.
Faites l’effort conscient d’engager la conversation avec des personnes que vous ne connaissez pas dans la file d’attente pour déjeuner. Demandez-leur où elles travaillent et ce qu’elles font. Allez dans une autre partie de votre bâtiment et présentez-vous à de nouveaux collègues. Demandez à être conférencier externe dans d’autres réunions d’équipe pour pouvoir partager ce sur quoi travaille votre équipe avec d’autres parties de votre société.
Engagez la conversation avec des clients et des fournisseurs et demandez-leur quelles sont leurs priorités et défis pour la saison prochaine et dites-leur sur quoi vous travaillez. Découvrez s’il y a les zones d’intérêts communs et une chance de collaborer.
Un printemps d’opportunités !
Je sais que tout cela semble un travail difficile mais chacun a ce nouveau printemps à l’esprit et c’est une belle occasion de parler de ce qui a été réalisé récemment et ce qui vient ensuite.
Autrement dit vous avez déjà une entrée en matière, alors sortez et utilisez-la.
partagez ce billet avec vos amis, collègues et relations professionnelles
Demandez votre copie gratuite de ce très sympathique et complet poster Scrum et montrez-le à vos collègues et amis.
Cette affiche peut être un outil d’apprentissage (par exemple lors de la lecture du guide Scrum) et un outil permettant à un ScrumMaster d’expliquer Scrum à l’organisation, au responsable produit ou à l’équipe de développement.
Une seule demande par personne est acceptée. Expédition aux États-Unis et en Europe uniquement. Vous serez informés par e-mail une fois le poster expédié.
Et voici la bande son en anglais dans cette vidéo
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
L’utilisation d’une approche Agile est pertinente pour tout type de changement, et pas seulement pour les changements technologiques.
Melanie le précise parce que, trop souvent, on a l’impression que Agile ne s’applique qu’aux projets des nouvelles technologies.
Les principes et techniques d’Agile ont été largement adoptés dans l’ensemble de la communauté informatique, mais les initiatives de restructuration des entreprises, de changement de localisation, d’acquisition et de rationalisation des processus bénéficient toutes d’Agile.
En effet, Agile est une façon de travailler qui permet de décomposer un objectif en petits étapes, chaque pas (ou Sprint en approche Scrum) menant à une réalisation qui peut être utilisée, davantage développée et construite.
Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…
Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.
Qu’en pensez-vous et comment traitez-vous ce problème ?
Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?
Est-ce périodiquement lors de grands « ménages » saisonniers ?
Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vous l’accorde volontiers, il ne s’agit pas avec Agile d’oublier que la complexité est bien réelle ni de l’ignorer…
Mais, il faut savoir commencer petit puis apprendre en marchant si l’on veut tirer rapidement bénéfice des avancées même modestes.
Par exemple, vous pouvez trouver acceptable d’avoir des paramétrages codés en dur dans la première version du logiciel, ou bien des capacités réduites de personnalisation, ou encore un seul profil/persona utilisateur…
Ou des choix de coloris limités pour vos premières productions.
CSP est partenaire de DantotsuPM
Devrions-nous adopter certaines des approches de « triage » utilisées dans les services des urgences des hôpitaux pour définir nos MVPs ?
Livre sur Amazon
Darria Long, médecin urgentiste, explique les principales leçons tirées des urgences de l’hôpital sur la gestion du stress, du chaos et de la vie.
Le Dr. Darria Long Gillespie est un médecin d’urgence formé à Yale et Harvard, auteur du livre à succès « Mom Hacks ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Avec l’essor massif de l’Agilité dans les organisations et plus particulièrement de la méthode Scrum, un nouveau rôle est apparu : Scrum Master.
Et avec ce rôle de nombreuses questions:
Peut-il développer ?
Est-il chef de projet ?
Est-il le responsable des développeurs ?
Comment s’interface-t-il avec les utilisateurs et le Product Owner ?
Quelles sont ses missions ?
Cette vidéo devrait vous permettre de faire le tri entre les mythes et les réalités qui entourent ce rôle.
En bonus vous repartez avec quelques outils bien pratiques dans votre rôle quotidien de Scrum Master si vous l’êtes et vous comprendrez mieux ce rôle si vous ne l’êtes pas !
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Un challenge très commun chez les managers de produit de tous niveaux d’expérience est de comprendre et mettre en œuvre une certaine forme de processus répétable autour de la priorisation.
Certaines personnes prennent une approche très légère, elles font des décisions basées sur leur propre expérience, données et conviction sur la direction du produit. D’autres prennent une approche beaucoup plus rigoureuse, appliquant des scorecardset autres mesures « objectives » à travers une pléthore de différentes métriques potentielles.
Je dois ici vous dire qu’il n’y a rien de mauvais avec n’importe laquelle de ces approches, mais il m’est aussi apparu clairement au cours de mes années de manager de produit qu’il n’y a aucune solution miracle pour vous assurer que vos décisions de priorisation seront bonnes plus souvent que mauvaises.
Trop compter sur des systèmes et des scores aboutit souvent seulement à un faux sentiment de sécurité que « le processus » était bon, quand en creusant vous constaterez que ces “scores objectifs” ne sont rien plus qu’un système avec lequel jouer.
Il y a cependant 3 choses dont je pense que chaque système de priorisation devrait tenir compte. Aussi, sans plus de cérémonie, discutons valeur, difficulté et instinct…
#1 – Prioriser c’est prendre en compte la valeur
Si nous pensons au problème racine que nous essayons de résoudre avec nos efforts de priorisation, ce devrait être que nous essayons de livrer la plus grande valeur possible, aussi rapidement que possible, en apportant des bénéfices à nos utilisateurs finaux et clients. Si c’est votre but (et si ça ne l’est pas, honte à vous !), alors l’un des facteurs les plus importants à considérer dans vos efforts de priorisation est la valeur que cette chose apportera vraiment.
Apporter la plus grande valeur possible, aussi rapidement que possible à nos clients.
Certains lui donnent une valeur numérique, d’autres utilisent une valeur monétaire — quoique ce soit qui marche, tant que vous considérez combien de valeur vos efforts vont délivrer. Cependant, baser vos décisions seulement sur la valeur marchande peut souvent aboutir à une dépriorisation de la dette technique et des investissements d’infrastructure. S’il vous plaît, pour l’amour de toute puissance supérieure en laquelle vous croyez, n’en soyez pas la victime. Bien que la dette technique et l’infrastructure pourraient ne pas avoir la valeur évidente pour le client, échouer à investir le nécessaire dans celles-ci causera l’échec de votre produit à un certain point critique pour un certain client critique. Si vous utilisez la valeur pour le client comme unique ou principale métrique, assurez-vous s’il vous plaît que vous avez un groupe de taches séparé pour le travail qui vous permet de rembourser votre dette technique et investir dans des améliorations d’infrastructure. Ayez confiance en moi, vous respirerez beaucoup plus librement en sachant qu’il n’y a pas un certain item technique inconnu qui va causer un effondrement général au plus mauvais moment possible.
#2 – Prioriser c’est prendre en compte la difficulté
Alors que la valeur pour le client est importante, il est également important que nous comprenions la quantité de travail qui va entrer dans toute nouvelle fonctionnalité ou amélioration de notre produit. Peu importe combien la valeur client est incroyablement élevée, si vous ne parviendrez jamais en réalité à compléter le travail à temps pour capitaliser sur cette opportunité. Trop souvent, des managers de produit décident seuls de la difficulté de quelque chose sans impliquer quelqu’un côté développement, support, ou équipes de livraison : C’est une erreur de débutant que même les managers de produit avec plus de 10 années d’expérience font tout le temps (oui, je la fais aussi parfois).
Attention au mirage venu de la seule imagination du manager de produit sans réelle prise en compte de la faisabilité.Évaluer l’effort exigé pour ajouter une fonctionnalité ou une capacité est plus précis quand réalisé en impliquant les gens qui feront effectivement le travail. Ils connaissent leurs capacités mieux que vous, ils connaissent la technologie mieux que vous, ils connaissent le code existant mieux que vous, etc. Cela ne signifie pas que vous devez tout décomposer en tâches, ou même en histoires utilisateur mais cela veut dire que vous devez consulter vos équipes techniques pour avoir une meilleure idée de combien une fonctionnalité est « grande », ou combien de temps il leur faudrait pour la produire. Quand nous devons évaluer la difficulté de résoudre un problème, assurons-nous que nous nous basons sur des experts et n’utilisons pas simplement nos propres opinions qui seront plus souvent fausses que correctes.
#3 – Prioriser c’est aussi suivre son instinct
Des données objectives et quantitatives sont des apports épatants dans tout processus de priorisation et plus de données vous pouvez obtenir, meilleures vont probablement être vos décisions. Mais il y a aussi un aspect inexprimable à la priorisation qui fait de ce processus tout entier plus un art qu’une science. Franchement, si tout ce qu’il fallait était des données objectives déposées dans un tableau qui donne un score alors vous n’auriez pas vraiment besoin de managers de produit pour mener vos efforts de priorisation. Vous auriez un système basé sur l’Intelligence Artificielle qui considère vos idées, prend toute les données disponibles et vous dit exactement que faire et précisément quand le faire. Heureusement pour ceux d’entre nous qui avons choisi le Management de Produit pour carrière, ce n’est pas le cas.
Il y aura toujours une partie d’analyse subjective quand on regarde les données et prend des décisions sur si vraiment la direction que nous indiquent les données signifie réellement quelque chose dans le schéma d’ensemble. J’ai travaillé dans des environnements où les décisions ont été prises par des résultats d’étude Six Sigma, des tableaux, un processus « objectif » de collecte de données et celles-ci ont poussé des fonctionnalités que personne ne voulait ni ne se souciait et en gaspillant des ressources techniques. L’équipe de Management de Produit savait qu’il y avait de meilleures options, savait qu’il y avait d’autres données subjectives pour soutenir ces efforts, mais a été forcée de se taire et de “laisser marcher le système”. Mais il n’a pas fonctionné, parce qu’il a ignoré l’expérience globale que de bons managers de produit apportent à la table. Un bon manager de produit sait quand insérer l’instinct et l’expérience dans l’équation et changer ou réarranger des choix basés seulement sur des données « objectives ».
Sans instinct, sans le ressenti dans ses tripes, seuls les choix apparemment les plus sûrs seront adoptés et l’innovation jetée par la fenêtre.
partagez ce billet avec vos amis, collègues et relations professionnelles
Au début 2020, une nouvelle version de SAFe sera disponible. Elle est, comme d’habitude, entièrement compatible avec la version précédente SAFe 4.6, permettant une migration en douceur.
Il y a maintenant 7 compétences fondamentales qui permettent l’agilité dans le business. Certaines sont repositionnées et restructurées et 2 nouvelles compétences étendent SAFe afin qu’il englobe l’entreprise toute entière et permettent l’agilité d’affaires. Voir la nouvelle grande image de SAFe.
Les deux nouvelles compétences sont : Culture d’Apprentissage Continu (Continuous Learning Culture / CLC) et Agilité Organisationnelle (OA).
La Cultured’Apprentissage Continu est basée sur trois dimensions : L’Organisation Apprenante (vision partagée, systems thinking, modèles mentaux, apprentissage dans l’équipe, maîtrise personnelle), l’Amélioration Inexorable (un sentiment constant de danger, optimisation de l’ensemble, culture de résolution de problème, Prise de recul aux événements marquants principaux, l’amélioration basée sur les faits) et la Culture d’Innovation (les gens innovateurs, le temps et l’espace, aller voir, expérimentation et réactions, pivoter sans pitié ni culpabilité, innovations à contre-courant).
Les trois dimensions d’Agilité Organisationnelle sont : des gens pensant LEAN et des équipes agiles (house of lean, principes SAFe, Manifeste Agile), des Opérations LEAN (temps de traitement –temps d’attente – temps de traitement) et Agilité de Stratégie.
L’ancienne compétence DevOps et release on demand est maintenant appelée Livraison de Produit Agile (Agile Product Delivery). Ici nous voyons des développements sur la Cadence, la livraison sur demande, DevOps et le Pipeline de Livraison en Continu. Une nouveauté est la Position Centrée sur le ClientCustomer Centricity qui comprend : étude de marché, design avec l’utilisateur) et Design Thinking dans la Livraison Agile de Produit.
Livre sur mazon
Les équipes business de l’entreprise montent maintenant ‘sur le train’ et participent à la livraison et au support de solutions business innovantes. Ces équipes adoptent les valeurs, principes et pratiques Lean et Agiles.
Si je prends une vue d’ensemble de la forêt agile, je replace SAFe pour souligner que SAFe couvre maintenant, au niveau produit, cible produit ainsi que le choix de culture.
Un tout nouveau guide disponible gratuitement et traduit en français.
à télécharger en ligne
L’approche Kanban, orientée flux, peut améliorer et compléter le cadre de travail (Framework) Scrum ainsi que sa mise en œuvre. Les équipes peuvent ajouter des pratiques Kanban complémentaires, qu’elles débutent avec Scrum ou l’utilisent déjà.
Le Guide Kanban pour les équipes Scrum est le résultat d’une collaboration entre des membres de la communauté Scrum.org et des leaders de la communauté Kanban.
Ensemble, ils supportent Le Guide Kanban pour les équipes Scrum. Ils partagent la conviction que les professionnels du développement de produits peuvent bénéficier de l’application de Kanban couplée à celle de Scrum.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Livrer souvent un produit certes incomplet mais utilisable et de valeur c’est Agile !
Personnellement, je ne connaissais ni MVE ni MMF et je trouve que ces concepts sont utiles pour préciser ce que l’on cherche à réaliser et surtout ce que l’on peut ou pas livrer aux clients et utilisateurs. L’idée des spikes sur une journée pour préciser les besoins me parait également très intéressante.
La promesse des approches agiles est de livrer quelque chose souvent. Nous livrons, ainsi nous pouvons obtenir des réactions et discuter du reste à faire avec notre client (ou le Propriétaire de Produit / Product Owner). Et, donc nous pouvons évaluer notre processus et notre travail d’équipe tout le temps.
Trop souvent, les gens pensent aux fonctionnalités comme la somme de tout ce qui pourrait être dans ce périmètre. Cependant, nous en avons des alternatives à ce « tout » avec une variété de minimums.
Définissez les divers Minimums
Nous avons beaucoup de « minimums » possibles quand nous pensons aux histoires et plans de travail :
MVE, Minimum Viable Experiment – Expérience Viable Minimale : une histoire fournit des réactions pour l’équipe et le propriétaire de produit.
MVP, Minimum Viable Product – Produit Viable Minimal : une histoire ou un jeu d’histoires qui apportent assez de fonctionnalités pour que le client puisse les utiliser, même si ce ne sont pas les pleines fonctionnalités.
MMF, Minimum Marketable Feature – Fonction Commercialisable Minimale : le plus petit morceau de fonctionnalité qui le client considère de valeur.
Les MVEs peuvent être utiles quand vous voulez savoir si vous devriez même songer à cette partie d’un jeu de fonctionnalités.
Une équipe à la société Acme se débattait avec l’ensemble de fonctionnalités appelé « Rapports ». La fonctionnalité couvrait plusieurs grands rapports : ventes par géographie, par type de produit, agrégées par plusieurs clients et autres.
L’équipe savait qu’elle avait besoin d’une base de données, d’un système de production configurable et de sécurité/protection des données, parce que les clients pourraient accéder directement à certains de ces rapports. Et, chaque client devait avoir ses données protégées. Aucun client ne pourrait voir des données d’autres clients. Ils savaient qu’ils auraient besoin d’au moins deux niveaux de protection pour les clients et en interne à leur organisation.
En essayant d’écrire l’histoire dressant la liste de fonctionnalités des rapports, ils avaient créé plus de 20 histoires, juste pour les rapports client. Ils ont alors décidé qu’ils avaient besoin d’un MVE pour voir ce quels étaient les besoins minimaux pour les rapports clients. Peut-être sur-analysaient-ils le jeu minimal de rapports clients.
Comme ce produit exigeait de la sécurité, tant le MVP que le MMF nécessitaient une base de données avec des fonctionnalités de management de la sécurité. L’équipe savait que pour la base de données, ils auraient probablement besoin de données avant de créer un schéma pour cette base.
Ils ont finalement choisi d’expérimenter avec des données simulées pour voir de quoi les clients auraient vraiment besoin. Puis, ils pourraient élaguer l’arriéré d’histoires.
Les expérimentations créent un accord commun sur ce qui est important
Quand l’équipe a créé son histoire utilisateur originale pour des rapports clients, les membres avaient identifié trois niveaux de sécurité : le vendeur chez le client, le directeur commercial du client (ou tout autre membre de la direction) et les personnels internes de gestion de produit et commercial. Acme avait besoin d’informations sur ses clients et les clients de la sécurité nécessaire pour l’un et l’autre, c’est pourquoi il y aurait des niveaux différents de sécurité.
L’expérimentation initiale était simple : Sur un petit jeu de produits, comment les clients avaient-ils besoin de visualiser les données ?
L’équipe a pensé à simuler les rapports dans un fichier informatique. Puis, un testeur a suggéré qu’ils créent plutôt les prototypes sur papier car ils seraient faciles à changer instantanément, si nécessaire.
L’équipe (incluant le Product Owner) a passé une heure à créer une variété de prototypes papier et de flux de travail qu’ils pensaient que le client voudrait. Ils ont appelé le chef de produit qui avait rencontré un client la semaine précédente. Ils lui ont déroulé les flux.
Le chef de produit a accepté le premier flux et a rejeté les trois suivants et a expliqué pourquoi. Les explications ont surpris tant le Product Owner que le reste de l’équipe. Ils ont appris beaucoup de cette expérimentation et furent capables de reporter à plus tard un certain nombre d’histoires utilisateurs sur les Rapports – le tout en un seul jour de travail.
Puis, ils ont eu besoin de considérer le schéma de la base de données. Ils savaient qu’ils n’auraient pas de MVP sans la sécurité nécessaire. Cela signifiait qu’ils devaient embarquer non seulement la sécurité, mais aussi sa performance.
Les Spikes ont aidé toute l’équipe à apprendre ensemble
Ndlt : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.
Copyright 2000 Don Wells
Cette équipe avait essayé les spikes dans le passé et les avait appréciées.
Ils avaient un flux typique
L’équipe entière se rencontre 20 minutes maxi le matin (à 9 :00) pour passer en revue l’histoire. L’équipe a souvent besoin de seulement 5 minutes, mais on y alloue 20 minutes.
L’équipe décide comment travailler ensemble. Dans ce cas spécifique, deux développeurs travaillent en paire sur le schéma, deux autres membres de l’équipe sur les tests automatisés et l’autre développeur s’assure qu’il créée des outils pour que les testeurs puissent vérifier les résultats dans la base de données. Ils décident de développer et tester directement dans la base avant l’interface utilisateur.
L’équipe est séparée en ses sous-groupes et travaille pendant une heure.
Toutes les heures, ils se réunissent 5minutes pour un point rapide. Quelqu’un a-t-il été bloqué ? Tout se passe-t-il comme prévu ? Quelqu’un aurait-il besoin d’aide ? Quelqu’un a-t-il terminé et pourrait aider les autres ?
Leurs réunions n’étaient pas des standups traditionnels, où trop souvent, l’équipe se concentre sur la personne. Ces rencontres ont permis aux membres d’équipe de se concentrer sur le travail.
Au point rapide, l’équipe décide si elle a besoin de modifier les sous-équipes pour améliorer le flux du travail. Ils font ceci à chaque heure (avec une pause déjeuner) jusqu’à 16:00 ou quand ils ont terminé, le premier des deux.
L’équipe s’ arrête à 16:00 pour plusieurs raisons
Ils sont fatigués. Ils se sont concentrés toute la journée sur du travail difficile.
S’ils ne peuvent pas « finir » le spike dans la journée, le travail nécessitait probablement plus que même deux journées. Ils ont besoin de se regrouper et de replanifier.
S’ils ont terminé, ils peuvent expliquer ce qu’ils ont découvert au Product Owner.
À la fin de la première journée, ils se sont rendus compte qu’ils auraient besoin d’autres scénarios pour la performance et la sécurité. Il était le temps de discuter de comment ces aspects fonctionnaient ensemble et séparément avec le Product Owner.
Que pourraient-ils reporter en matière de performance, d’autant plus qu’ils n’allaient pas encore exécuter ces rapports sur de gros volumes ?
Les MVPs fournissent des retours à l’équipe
Produit Viable Minimum (MVP)
Le Product Owner mène la discussion d’équipe sur ce qui constitue un réel MVP. Un MVP signifie que les clients devaient être capables d’utiliser ce que l’équipe a livré. Ils choisissent cinq histoires et créent ce premier MVP centré seulement sur le vendeur interne à la compagnie. L’équipe s’attend à recevoir des réactions du personnel commercial sur les fonctionnalités et la performance. Ils utilisent ces retours pour prévoir les MVPs suivants à destination du personnel commercial de la société.
Dans ce cas, le Product Owner décide quel persona est le plus important à quel moment, pour séquencer les MVPs de manière logique. Il faut trouver la balance entre manager les retours de l’équipe et délivrer de la valeur pour les clients.
Les MVPs permettent de créer un produit commercialisable ou MMF
Il faut plusieurs MVPs pour créer une MMF, une Minimum Marketable Feature (Fonction Commercialisable Minimale). Ce MMF fournit assez de valeur (et de cohérence produit) pour trois personae clés : le personnel commercial interne et leurs managers, ainsi que l’équipe de ventes.
Plus petit votre MMF, plus rapide le flux de travail pour le produire.
Vos minimums sont-ils assez petits ?
Je travaille régulièrement avec des équipes qui pensent qu’un MVE est la même chose qu’un MVP et qu’un MMF. Même s’il est possible que les trois soient identiques, le plus souvent ils sont différents.
Je constate que quand les équipes utilisent des spikes d’un jour, apprenant ensemble pendant cette journée, elles sont mieux à même de faire la différence entre ces divers minimums.
A quel point pouvez-vous minimiser votre travail et en maximiser la valeur pour vos clients ?
Livre sur Amazon
Cet article a été écrit parJohanna Rothman. Johanna, est connue comme la “Pragmatic Manager” qui fournit des avis honnêtes sur vos problèmes.
La mission du Scrum Inc « Licensed Scrum Program« est de développer Scrum dans le monde entier, en libérant les gens des servitudes incroyables du système dans lequel ils travaillent. Nous sommes à un moment charnière où les plus grandes organisations du monde se rendent enfin compte que leur façon de travailler ne marche pas. Elles doivent changer et cherchent à le faire en faisant preuve « d’agilité », souvent sans les pratiques prouvées qui produisent de bons résultats.
Le programme « Licensed Scrum« est conçu pour fournir aux particuliers et aux organisations une voie claire de mise en œuvre de Scrum d’une façon qui conduit à des résultats opérationnels immédiats et fait en sorte que Scrum ait un impact de transformation durable.
Ce programme enseigne comment nous délivrons réellement deux fois plus de résultats en la moitié de temps dans des organisations à travers le monde entier.Les formations de Scrum Inc. comprennent les principes Lean, les modèles du mouvement Scrum Pattern Language et les leçons tirées des implémentations de Scrum@scale dans la vraie vie.
Visionnez cette vidéo de Jeff Sutherland, l’un des concepteurs de Scrum.
La boite à outils DA est un ensemble complet de connaissances agiles (un Body of Knowledge – BOK) qui fournit des conseils simples et pratiques pour aider les personnes, équipes et entreprises à décider de leur « façon de travailler » en fonction du contexte.
Parmi les principes clés
Être centré sur le client
Être pragmatique plutôt que puriste
Proposer une large gamme d’options agiles et LEAN
Adapter ses pratiques en fonction du contexte
Optimiser les flux dans l’ensemble de l’entreprise
CertYou est partenaire de DantotsuPM
Il s’agit pour les organisations d’adapter « leur façon de travailler » à leur contexte.
Disciplined Agile a compris la nécessité de personnaliser toute méthode ou toute approche, traditionnelle et prédictive, Scrum ou SAFe, afin d’obtenir des résultats qui les différencient de leurs concurrents.
La combinaison de PMI et DA offre donc une proposition de valeur nouvelle et attractive. Voici, je pense, pourquoi le PMI a fait cette acquisition. Elle lui permet de rester à la pointe dans le management de projet en utilisant de manière pragmatique des approches Agiles quand cela fait sens pour le projet.
PMI is a registered mark of Project Management Institute, Inc.
Si vous connaissez ou utilisez déjà Disciplined Agile, n’hésitez pas à me contacter pour partager votre expérience sur ce blog.
partagez ce billet avec vos amis, collègues et relations professionnelles
Lors du dernier forum National du PMI France, le demi-millier de très chanceux participants ont pu échanger avec Cécile Dejoux !
Son entrée en matière a immédiatement capté notre attention avec une intéressante analogie gastronomique : « Nous sommes dans une nouvelle civilisation : Avant, on faisait confiance à l’expert, aujourd’hui à la multitude. »
Il s’agissait bien sûr des recommandations du guide Michelin versus celles de Trip Advisor.
Cécile entra ensuite dans le vif du sujet avec 4 étapes pour réussir toute transformation numérique.
Comment avoir une approche de management de projet en laquelle on a déjà confiance et y ajouter le nouveau ‘ test de pertinence ’ pour s’assurer que l’approche adoptée est la bonne pour le projet en question ?
PMGS est partenaire de DantotsuPM
Une parfaite tempête de circonstances dans la gestion de projet dans le secteur public au Royaume-Uni aide à ouvrir la porte aux méthodes agiles et en particulier aux promesses de PRINCE2 Agile.
D’abord, certains projets n’ont pas atteint le succès escompté, ne livrant pas le produit escompté ou ne répondant pas aux attentes des parties prenantes. En combinant ces problèmes avec la suite probable de mesures d’austérité du Gouvernement et encore plus d’attention sur les projets rend fort attirante l’opportunité d’avoir l’accès à des méthodes qui aideront à les mener plus efficacement.
D’autre part, il y a eu des dépenses significatives engagées dans les formations et certifications PRINCE2® dans les secteurs tant publics que privés et les organisations veulent s’assurer que leurs investissements produisent un retour maximal. Les managers de projets qui ont acquis une certification de base ou avancée pourraient appliquer leur expertise de ces pratiques pour un effet encore plus important en se servant plus largement de la méthodologie qu’ils ont appris pour réussir l’examen. Cela signifie porter l’utilisation de PRINCE2 au-delà de la connaissance sur une application tangible et augmenter le retour sur l’investissement en conséquence. Et c’est pourquoi la création de PRINCE2 Agile fournira une combinaison gagnante de méthodologies aux projets : Ajouter Agile à l’approche PRINCE2 la rend plus flexible, pratique et de valeur.
Il s’agit de prendre l’approche de management de projet en laquelle on a déjà confiance et d’y incorporer le nouveau ‘ test de pertinence ’ pour s’assurer l’approche adoptée est la bonne pour le projet en question. Cela aidera les managers de projet à développer leur capacité professionnelle à choisir la meilleure approche pour un projet et prendre les bonnes décisions plutôt qu’être contraints à utiliser une seule et unique méthode.
QRP International est partenaire de DantotsuPM
Pourquoi mixer PRINCE2 et Agile ?
Le cocktail combinant PRINCE2 et Agile amènera les praticiens au-delà du simple ‘ posséder la connaissance ’ et les équipera de techniques pratiques pour démarrer. L’avantage d’utiliser les deux approches ensemble signifie que les managers de projet ‘ ne repartent pas de zéro ’ mais construisent sur leurs connaissances existantes.
Du point de vue d’une organisation, cela aidera à rentabiliser l’investissement fait dans PRINCE2 et adresser des secteurs où, parfois, cela ne convient pas tout à fait. En termes simplistes, cela permettra aux organisations d’être plus agiles en utilisant des approches qui aident à produire ce que veut l’utilisateur sans s’attendre à ce que l’utilisateur dise d’entrée de jeu “je sais ce que je veux”. Au lieu de cela, le projet peut présenter le résultat possible dans des livrables plus petits et les évaluer avec l’utilisateur pour démontrer ce qui est possible sans devoir décider du produit final dès le départ.
Cette façon de travailler permet d’apprendre rapidement, de manager plus efficacement les exigences des utilisateurs, de contrôler les dépenses et d’augmenter la probabilité de livrer le bon produit au final.
Partenaire de DantotsuPM
Dépasser la méthode : la promesse de PRINCE2 Agile
Le manager de projet et l’équipe sont donc plus certains des besoins en ressources, des éléments à fournir par le projet et de comment tout cela s’aligne avec le cas d’affaires. Cela, à son tour, rend l’exécution du projet plus prévisible, plus sûre et en fin de compte avec davantage de chance de réussir.
Dans certaines formations PRINCE2, la technique de Moscow peut ne pas être détaillée à moins que les chefs de projet ne soient en position de prendre d’importantes décisions et cette approche peut donc être nouvelle pour ces managers de projet. PRINCE2 Agile comble le trou entre la théorie et la pratique avec une approche pour l’utiliser dans les projets qui devrait la rendre plus facile et plus fréquemment déployée.
Avoir la capacité d’aller au-delà du suivi d’une méthode ou une discipline et commencer à utiliser l’apprentissage résultant de l’expérience apportent extrêmement de valeur aux managers de projet. En fait, il s’agit de construire une plus grande compétence professionnelle, à long terme à travers la communauté des managers de projets et de programmes dans son ensemble.
‘Le 70-20-10’, le modèle d’apprentissage utilisé dans le secteur public correspond à 10 % pour l’étude en salle de formation, 20 % à apprendre des autres et 70 % par l’expérience. Cela signifie des managers de projet qui développent la capacité, par leur expérience aussi bien qu’études et obtention de qualifications, de gérer des projets plus complexes avec une plus grande confiance et meilleure efficacité. PRINCE2 Agile est un bon pont pour lancer les chefs de projet dans ce voyage vers l’application ce qu’ils savent.
Se concentrer sur le futur de la réussite de projet
Une nouvelle approche, comme la promesse de PRINCE2 Agile, accroit l’opportunité que les bons produits soient livrés pour répondre à un cas d’affaires. L’approche se fonde sur ce que l’on a déjà appris et devrait nous amener à progresser tant sur les processus que les résultats réalisables. Pour des organisations considérant une aussi nouvelle approche, le critère de décision est simple : Obtenir un retour sur investissement.
Mais la volonté d’adopter une telle méthodologie exige la coopération des membres de deux communautés de pratiques tout à fait distinctes et leurs perceptions les uns des autres. La communauté Agile peut considérer PRINCE2 Agile comme inflexible alors que les praticiens PRINCE2 questionnent le niveau de contrôle avec des principes de livraison Agile.
Mais avec une compréhension des bénéfices mutuels sur le contrôle et la flexibilité, basée sur la communication claire de ces avantages, les deux camps devraient reconnaître la valeur que chacun peut apporter pour mener le projet au succès.
Clairement, la gestion du changement impliquant la dimension culturelle sera importante pour persuader des professionnels de projet que mixer PRINCE2 et Agile aura un impact positif sur leur travail dans le long terme.
partagez ce billet avec vos amis, collègues et relations professionnelles
Tous concernés si nous voulons réussir ce bouleversement dans la manière de développer, mettre en production et utiliser efficacement les produits des projets Agiles.
Dans son billet « 10 profils qui ont besoin de comprendre DevOPS », notre partenaire QRP recense au moins 10 rôles et autant sinon plus de départements dans l’entreprise qui ont besoin de se familiariser avec ces concepts et approche.
Lisez ce billet de QRP International, partenaire du blog DantotsuPM
Je vous invite à le lire, que vous soyez manager de projet, sponsor ou simple partie prenante potentiellement impactée par un projet mené en mode Agile (Marketing, Finance, Ventes, Support…).
partagez ce billet avec vos amis, collègues et relations professionnelles
Téléchargez gratuitement Le Manifeste Agile : 4 préceptes et 12 principes !
Imprimez-les, affichez-les au mur, faites-les suivre à vos équipes et surtout, appliquez-les !
Le Manifeste Agile a été écrit en février 2001 par 17 développeurs informatiques libres d’esprit. Il a donné naissance au mouvement Agile dans le développement de logiciels. Bien que chaque méthodologie Agile applique les préceptes et les principes à sa manière, ceux-ci leur servent de guide tout au long du processus de développement.
Spécifiez ce qui peut et doit être partagé dans le contrat. Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre. Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu). Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.
Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies). Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives. Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.
Collecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.
DantotsuPM.com 