Agile for All Book

Agile fournit des réponses réelles et efficaces à une question qui maintient les cadres éveillés: "Comment réussir dans un monde en évolution rapide et imprévisible?" Cette méthodologie a déjà conquis le marché, prouvant qu'elle est l'une des meilleures approches pour la création et la livraison de logiciels. Agile for All s'adresse aux praticiens, dans ce livre, vous apprendrez comment des organisations entières - des chefs de produit et développeurs aux responsables marketing et dirigeants - peuvent adopter une approche «flexible».

Matt LeMay explique simplement et sans argot ce qu'est l'Agile et propose des étapes concrètes et efficaces qui permettent à toute équipe de réaliser ses tâches le plus efficacement possible. Vous trouverez de nombreux exemples adaptés à tout type et taille d'organisation - des startups aux grandes entreprises - qui vous permettent de mettre en œuvre l'approche Agile dans différents domaines d'activité.

Plongez dans la pratique Agile: "whoopee!"

Lorsque je travaillais en tant que chef de produit, je disposais de nombreuses pratiques et cadres Agile prêts à l'emploi que je pouvais utiliser en équipe. Ces cadres concernent exclusivement les besoins des équipes de développement de logiciels et ont été testés en pratique par des milliers d'experts, dont beaucoup ont aimablement partagé leurs expériences sous la forme de publications accessibles et d'articles de blog.

Cependant, lorsque j'ai commencé à travailler en tant que consultant, je ne pouvais pas immédiatement comprendre comment utiliser ces méthodes par rapport aux objectifs complètement différents des nouvelles équipes. Les résultats de nos travaux - rapports analytiques obtenus après des mois de longues consultations, séminaires sur la formation de l'image du client - étaient significativement différents des produits logiciels, car nous n'avions plus de moyen clair et objectif de vérifier la performance de ces résultats. De plus, dans nos rôles, toutes les frontières ont été effacées par rapport aux rôles dans l'équipe de développement, car maintenant nous avons tous fait une chose commune, ne nous cachant pas sous les titres de «concepteur visuel» ou de «développeur front-end».

Pris dans ce pétrin procédural, nous avons essayé de faire face à un ensemble standard de problèmes qui se posent pour les équipes qui produisent des résultats non techniques. Le sujet de ces résultats se développe imperceptiblement et inévitablement au fur et à mesure que nous travaillons, surtout lorsque nous sommes passés d'états intermédiaires (esquisses) à des documents et des présentations à part entière. La finalité orientée client de chaque résultat restait parfois peu claire pour nous, donc, dans de tels cas, nous avons élargi le sujet de la recherche pour ne rien «manquer». Malgré le fait que nous aimions travailler ensemble, nous ne comprenions pas toujours qui, pour quoi, quand et pourquoi était responsable.

Il est à noter que les méthodes Agile «statutaires» ne cadraient pas toujours parfaitement avec la structure de notre équipe ou les résultats, cependant, nous avons compris que les principes Agiles fondamentaux pouvaient nous maintenir dans la bonne direction. Par conséquent, nous avons commencé à nous poser des questions qui constituaient la base de ce livre: dans quelle mesure comprenons-nous clairement les besoins de notre client? Pouvons-nous éliminer tous les malentendus professionnels grâce à une coopération opportune? Veillons-nous à ce que l'introduction de nouvelles informations dans le workflow ne se transforme pas en un traitement complet du matériel?

Nous avons commencé à poser ces questions régulièrement lors de la planification et des réunions rétrospectives, en changeant le flux de travail pour refléter nos idées et nos réponses. Après avoir expérimenté pendant environ un an, nous avons transformé notre approche en une pratique WHPI (lire "woooops!" Ou "Pourquoi, Comment, Prototype, Itération"). WHPI se compose de quatre étapes, qui sont données dans le tableau. 6.3. Pour commencer, vous décidez collectivement pourquoi vous placez le résultat en premier lieu, quel impact vous attendez et quelle valeur votre client recevra. Ensuite, vous décidez comment vous allez fournir cette valeur, à quoi ressemblera le résultat final. Enfin, vous confiez à l'un des membres de l'équipe pour un temps limité de créer un prototype qui reflète l'expérience que vous souhaitez créer pour le client, puis itérez ce prototype et vérifiez s'il a pu atteindre les objectifs que vous vous êtes fixés dans la première étape.


Nous avons constaté que WHPI est un puissant outil Agile qui peut être intégré dans n'importe quelle équipe, quels que soient leurs tâches et leurs objectifs. Vous trouverez ci-dessous une brève description de chaque étape WHPI et quelques conseils pour implémenter et utiliser ces méthodes au sein de votre équipe.

ÉTAPE 1: Pourquoi

Pour cette étape, nous rassemblons plusieurs participants clés du projet (2 à 4) et discutons rapidement d'un ensemble d'objectifs ou de résultats du projet. Si possible, nous nous réunissons dans un seul espace physique (ou virtuel) et élaborons toutes les idées enregistrées sur des autocollants pendant le processus de travail. Ces réunions durent généralement de 15 à 30 minutes. Bien que ces délais puissent sembler difficiles et peu pratiques pour des réunions aussi importantes, ils reflètent une vérité importante: si vous n'êtes pas en mesure de déterminer les principaux objectifs en 15 à 30 minutes, vous devez obtenir plus d'informations avant d'aller de l'avant. À plusieurs reprises à ce stade, nous avons réalisé qu'il était nécessaire de mener des recherches de base pour confirmer nos hypothèses ou poser à nos clients des questions de clarification. Après avoir créé un seul ensemble initial d'objectifs «pourquoi», nous les mettons au centre de l'attention afin qu'ils dirigent le reste du processus de travail.

Par exemple, lorsque nous développons un rapport analytique après une réunion, nous écrivons souvent trois «pourquoi» principaux sur des autocollants:

• Pour transmettre une compréhension de la force motrice du projet à la haute direction.
• Rappelez aux participants les points clés de la réunion.
• Susciter l'intérêt des employés qui n'ont pas assisté à la réunion.

Veuillez noter qu'aucun de ces points n'indique directement comment nous allons atteindre nos objectifs - plus à ce sujet plus tard!

ÉTAPE 2: Comment

Après avoir fixé les objectifs du projet, nous passons à la tâche difficile de déterminer comment les atteindre. Nous appelons souvent cette étape «définition des outils» - c'est-à-dire que lorsque nous savons ce que nous allons faire, nous devons penser aux outils et aux approches. Je recommande de passer du «pourquoi» au «comment» avec les mêmes participants à la réunion. Souvent, en définissant un «comment», vous comprenez pourquoi au moins un objectif principal de l'équipe du «pourquoi» est en fait une étape du «comment» au niveau de la direction.

Dans la section précédente, nous avons identifié le «pourquoi» suivant: «Suscitez l'intérêt des employés qui n'ont pas assisté à la réunion.» Avant d'utiliser cette méthode, nous définissons un objectif similaire comme suit: "Expliquez aux participants le langage et les cadres afin qu'ils puissent partager des informations avec leurs collègues." Mais après avoir commencé à séparer le «pourquoi» du «comment», nous avons réalisé que nous avions oublié deux questions clés: pourquoi est-il important que les gens partagent ces tâches avec des collègues et comment pouvons-nous simplifier le processus de réalisation des objectifs? Le langage et les cadres sont-ils vraiment nécessaires aux gens? Comme nous avons réussi à en discuter dans ce livre, une attention prioritaire aux clients et à leurs besoins aide souvent à réduire la quantité de travail que nous attendions, ou à comprendre que le résultat souhaité est considérablement différent de ce que nous avions prévu de réaliser.

Étant donné le «pourquoi» de la dernière section, nous pouvons identifier le «comment» suivant pour diriger le flux de travail:

• Créez un court rapport d'analyse de deux pages qui peut être facilement compris et diffusé.
• Utilisez des citations mémorables des participants pour transmettre la compréhension de la force motrice à la haute direction.
• Utilisez des photos de réunion pour rappeler aux participants des moments intéressants.
• Promouvoir des résultats positifs et limiter la quantité de détails pour garder le résultat concentré et susciter un large intérêt.

Comme vous pouvez le voir, «comment» fournit un plan d'action ou un plan pour créer toutes les conditions nécessaires pour atteindre les objectifs visés. Cette étape détermine la forme de notre résultat, aborde directement notre «pourquoi» et fournit des limites claires et mouvantes pour éviter toute perte de contrôle sur les résultats souhaités. Un plan aussi clair vous permet de déléguer des tâches pour obtenir des résultats beaucoup plus rapidement, quelle que soit l'approche que vous utilisez dans les étapes suivantes.

ÉTAPE 3: Prototype

En définissant le «pourquoi» et le «comment», nous sommes prêts à créer un prototype limité dans le temps. Le mot "prototype" peut signifier beaucoup de choses dans différents contextes. Dans le cadre de cette méthode, nous définissons un prototype comme suit:

• Un prototype n'est pas un modèle ou un document de planification; il est créé dans le même format que le résultat souhaité. Par exemple, le «prototype» d'une présentation avec des diapositives est une présentation avec des diapositives. Le «prototype» d'une brochure imprimée est une brochure imprimée.
• Un prototype est créé dans un laps de temps limité et prédéterminé. (Créé dans le cadre de la boxe temporelle.)

En d'autres termes, nous «créons les conditions pour atteindre le nombre maximum d'objectifs du projet (« pourquoi ») en utilisant des approches et des outils approuvés (« comment »), dans le même format et avec le même délai que le résultat souhaité. Dans le cas de petits projets, tels que des affiches, le prototype initial peut ressembler à un résultat fini. Dans le cas de grands projets, comme un rapport de quarante pages, le prototype initial peut être 20 pages complètes pliées en deux, agrafées ensemble et remplies à la main (avec des pages numérotées, des en-têtes, des résultats succincts et des emplacements pour les images).

Comme nous l'avons expliqué au chapitre 3, notre objectif ici est de nous rapprocher le plus possible de l'expérience du client en créant notre propre version de «logiciel fonctionnel». Les éléments qui ont fière allure dans les modèles et les documents de planification ne fonctionnent pas dans les présentations, les rapports et les réunions. La vérification des premiers résultats à l'aide de la méthode prototype nous a permis de pénétrer l'expérience client, de réduire le nombre d'améliorations et d'analyser plus en détail les hypothèses initiales.

En règle générale, nous désignons un membre de l'équipe pour être responsable de la création du prototype principal. Cela devient souvent une question de temps libre: qui peut réserver plusieurs heures au cours des prochains jours pour faire la première tentative? Nous avons constaté que deux heures de travail est la limitation standard pour la création d'un prototype, ce qui vous permet de créer une base de comparaison avec les objectifs du projet et laisse de la place pour le développement et l'itération.

ÉTAPE 4: Itération

Après avoir créé le premier prototype limité dans le temps, l'équipe originale de participants (ou une partie de l'équipe) est réunie pour analyser le prototype et discuter de la prochaine itération. Nos premières discussions ont eu lieu dans le format plus / suggérer, dans lequel chaque membre de l'équipe parle des aspects réussis et des éléments à améliorer. (Nous avons utilisé exactement le même format dans nos rétrospectives, nous y sommes donc rapidement revenus.) Nous avons progressivement refait ce format dans la discussion dite «protéger, exclure, améliorer». Une fois le prototype présenté, les participants partagent trois types d'avis:

• Ce qu'il faut laisser pour les prochaines itérations, car il correspond autant que possible à tous les «pourquoi».
• Ce qui peut être exclu des itérations suivantes, car il ne correspond pas à tous les «pourquoi».
• Ce qui devrait être amélioré pour les prochaines itérations, car il peut encore aider à atteindre le «pourquoi» nécessaire.

La principale différence entre cette approche et le format traditionnel plus / offre est une discussion ouverte de ce qui doit être exclu des itérations suivantes. Nous avons commencé à utiliser cette approche après avoir constaté que les modifications les plus réussies pour les itérations se produisent après l'exclusion, et non l'addition, même dans les plus grands projets. Une «exception» ouverte pendant les discussions permet aux participants de suivre les aspects qui peuvent être supprimés, ce qui fournit des résultats plus précis et ciblés. En alignant les trois types d'examens avec le «pourquoi» convenu précédemment, nous résolvons tous les conflits potentiels, évitons les moments difficiles et gardons le projet dans la bonne direction.

Après avoir recueilli les commentaires, l'un des membres de l'équipe transforme ces avis en un autre prototype à itération limitée dans le temps. Dans certains cas, cela conduit à une révision complète du dernier prototype (par exemple, une révision de la présentation). Dans d'autres cas, cela conduit à la création d'un nouveau prototype basé sur d'anciens prototypes (par exemple, un rapport sur les résultats dans Word basé sur des prototypes manuscrits). Ces cycles d'itérations consécutifs peuvent être contrôlés par une personne qui a créé le prototype initial ou par tout autre membre de l'équipe. À la deuxième ou à la troisième itération, le prototype est souvent entre les mains de la personne qui a la responsabilité principale de présenter le produit modifié. De plus, à la deuxième ou troisième itération, le prototype semble presque complet et prêt pour la révision finale.

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur
» Contenu
» Extrait

25% de réduction sur les colporteurs - Agile

Lors du paiement de la version papier du livre, un livre électronique est envoyé par e-mail.