Je travaille avec / in / for agile dans le domaine du développement web depuis plus de 10 ans. La plupart d'entre eux ont dû faire face au framework agile le plus populaire - Scrum ( selon VersionOne ). Je veux partager avec vous les observations et conclusions accumulées.
Je vais commencer par une métaphore, car parfois je devais voir l'introduction de la mêlée dans ce scénario:
- Avant la mêlée : «développement» en tant que bébé - elle est déterminée, mais elle ne sait pas marcher normalement, mais veut vraiment apprendre pour atteindre l'objectif.
- Introduction : un enseignant vient ( formations Scrum, cours, coach agile, etc. ) et montre comment marcher. L'enfant est content, il se déplace par étapes! Top-top-top. Nous avons des sprints - c'est parti!
- Après l'introduction: les intervenants des patients disent: « D' accord, a conduit au but, » ce sont « pas de pression exercent sur l'équipe, nous allons! ». Le développement écrit des trajectoires intéressantes et apprécie le processus, mais l'objectif est oublié.
- Scrum-no : plus loin la pilule de la vérité de l'entreprise, Scrum "mute" et permet à l'entreprise d'obtenir une sorte de produit du développement. Et, malheureusement, la coche «nous travaillons sur Scrum» est officiellement cochée, mais le vrai potentiel de l'équipe de développement n'a pas encore été révélé, et ils disent que «Scrum n'est pas réel» autour.
À mon avis, cela se produit du fait que la mêlée est souvent mise en œuvre «mécaniquement», sans se rendre compte de l'essence du cadre et de ses éléments. Je voudrais essayer de révéler les symptômes de la "mêlée mécanique"; comprendre quels sont les inconvénients de cette approche; comprendre ce qui pourrait être mieux avec «une vraie mêlée avec agile»; et trouver des moyens de lutter contre les symptômes de la mêlée. Je consacrerai ici quelques articles à cela et je serai heureux de vos commentaires et questions.
Pour commencer, définissons ce qu'est une «mêlée mécanique». De mon point de vue, c'est lorsque tous les rôles, événements et artefacts de mêlée sont officiellement présents, mais les valeurs et les objectifs sont oubliés; lorsqu'il n'y a pas de culture agile ( c'est-à-dire un degré élevé de sensibilisation et d'acceptation du manifeste et des principes agiles ). Quand il n'y a pas de compréhension ou même une tentative de comprendre pourquoi tel ou tel artefact est nécessaire, ou quel est le but des événements dans la mêlée. C'est comme un robot dans une vidéo qui sait tordre les culbutes, mais qui l'appellera gymnaste? Lors de la mise en œuvre de la mêlée, il est important de transmettre à l'équipe ses objectifs et ses valeurs, et pas seulement la mécanique. La culture agile renforce la mêlée et la rend "réelle". Scrum est utile pour fournir régulièrement de la valeur et recevoir des commentaires rapides. Scrum concerne la vitesse et le développement de produits. Cela semble-t-il banal en théorie? Essayons de comprendre comment travailler sur Scrum et ne perdons pas la culture et les valeurs Scile en cours de route.
Lors de l'analyse des éléments Scrum dans ScrumGuide, les rôles sont l' un des premiers à être analysés , nous ferons de même. Parce que il s'est avéré beaucoup de matériel, puis, pour donner l'occasion de le réaliser, il est divisé en trois parties ( partie 2 , partie 3 ). Commençons l'analyse avec Product Owner.
Product Owner - Product Owner (PO):
Le propriétaire du produit est la personne responsable du produit, il «possède» le carnet de commandes du produit. L'outil principal de PO est la vision du développement de produits, et la tâche principale est de maximiser la valeur du produit produit par l'équipe. Tout semble simple: «Si vous êtes courageux, habile et habile ...», mais il y a des nuances. Ils ne nous enseignent pas à PO, mais ils enseignent à PM (chef de projet), et souvent PM devient PO, croyant que ce n'est qu'un changement de nom, et vous pouvez garder les anciennes approches au travail. Mais l'agile ne fonctionne pas comme ça. Comment est-ce nécessaire?
Interaction entre PO et produit, Backlog
Symptôme : PO n'est pas responsable de la composition de l'arriéré, il fonctionne uniquement sur les histoires reçues des autres participants au processus. Ou PO n'est pas responsable de prioriser les éléments du backlog. Son travail consiste à ramener l'arriéré au niveau accepté par l'équipe, et il ne détermine pas le contenu et les priorités de ce que l'équipe fera.
Ce qui est mauvais : si un OP n'a pas le courage ou la capacité de créer un produit ( former un backlog, prioriser, mener des expériences, etc. ), ce n'est pas un PO, mais un autre type d'activité. Et sans PO mêlée, pas mêlée. Sans former un carnet de commandes, PO ne peut pas être responsable du produit. Si elle n'est pas responsable de l'arriéré, l'adoption des décisions sur les produits nécessite des communications supplémentaires - il s'agit d'un temps supplémentaire passé, ce qui affecte négativement la vitesse de l'équipe.
Comment traiter : vous devez donner à PO le droit exclusif de prendre des décisions sur les produits et la responsabilité de la composition de l'arriéré. Si un non-décideur est un ordre établi, il est difficile de changer la situation du jour au lendemain. Lorsque PO est un proxy, alors
- Ou nous le supprimons de l'équation et faisons du PO vraiment celui qui est responsable de la composition et de la priorisation de l'arriéré. L'équipe de développement et l'équipe spéciale de découverte de produits peuvent aider les OP à travailler sur le carnet de commandes, mais la responsabilité de la composition et de la qualité du carnet de commandes ne devrait incomber qu'à une seule personne: les PO.
- Ou nous apprenons / nous permettons / nous forçons progressivement à prendre des responsabilités et à prendre des décisions (la composition des éléments de l'arriéré, la priorité des éléments, etc. ) de l'OP en cours. Les itérations sont importantes: consolider le succès, obtenir des commentaires.
Symptôme : PO n'a pas de vision pour le développement de produits, il n'a pas de stratégie globale, il n'y a aucun objectif où apporter le produit et pourquoi.
Ce qui est mauvais : La principale force de PO est la vision du produit, comprendre pourquoi et pour qui il est créé. Avec cette vision, il peut motiver et «infecter» les gens autour de lui. S'il n'y a pas de vision, il est peu probable que le produit se révèle nécessaire et bon. L'équipe ne sera pas «chargée» du résultat.
Comment traiter : PO, il est important de formuler d'abord une vision du produit. Il doit être capable de dire au format de l' ascenseur quel genre de chose cool il fait, pour quoi et pour qui. L'une des valeurs agiles est la transparence. En visualisant divers artefacts de développement de produits, nous travaillons sur la transparence. Le PO peut articuler sa vision et l'afficher devant l'équipe. Il est préférable que le travail sur la formulation de la hauteur et de la vision de l'ascenseur soit effectué avec une certaine fréquence - comme d'autres événements de mêlée ( prévu une nouvelle itération - fait - rétroaction collectée ).
Symptôme : PO ne fonctionne pas sur les éléments du backlog, ne les amène pas aux accords adoptés par l'équipe, ne met pas à jour les éléments du backlog, ne le nettoie pas, ne nettoie pas le backlog .
Ce qui est mauvais : si l'OP ne prête pas suffisamment d'attention à l'arriéré régulièrement, il devra quand même le faire (les sprints doivent être collectés ), mais cela sera plus stressant et coûteux ( par exemple: nettoyage collectif de l'arriéré sur la planification des sprints ). Les frais généraux de communication seront compensés par rapport au temps alloué pour le développement. L'OP commencera à perdre la confiance de l'équipe: elle n'investit pas dans l'arriéré - l'équipe n'investira pas dans l'augmentation. L'arriéré incorrect / non pertinent réduit la transparence pour toutes les parties intéressées. Et une mêlée sans transparence n'est pas une mêlée.
Comment traiter : Avant le bon de commande, vous devez transmettre l'importance de travailler sur l'arriéré - articles, livres, formations, etc. Nous devons développer des règles / réglementations pour mener le Product Backlog Refinement (PBR) afin que ces réunions soient utiles et efficaces, en menant une mini-rétrospective après PBR, en quelques itérations vous pouvez améliorer qualitativement cet événement. L'équipe doit améliorer le mécanisme de réalisation du PBR, en créant une synergie maximale entre l'OP et l'équipe de développement. Le carnet de commandes doit être nettoyé régulièrement. Pour obtenir les dernières informations, en plus d'ajouter de nouvelles histoires au backlog, vous devez vous rappeler de nettoyer les histoires qui ont perdu leur pertinence. Le backlog doit contenir des éléments compréhensibles par l'équipe et élaborés ( dans le cadre des accords d'une équipe spécifique ) pour 2-3 sprints; un backlog plus approfondi peut perdre de sa pertinence. En général, l'arriéré devrait contenir la feuille de route pendant au moins un an, afin que toutes les parties intéressées aient le sentiment que le produit a un avenir. Garder un carnet de commandes brisé par incréments approximatifs aidera l'équipe à réfléchir à l'avance aux objectifs de sprint .
Symptôme : PO fonctionne sur plusieurs produits indépendants ou avec plusieurs équipes. En option - en plus du bon de commande principal, il joue également un rôle différent dans le processus Scrum (développeur ou SM).
Ce qui est mauvais : être un bon de commande n'est pas une tâche facile, nécessitant de grands rendements. Si le rôle de l'OP est combiné avec d'autres activités, alors avec un degré élevé de probabilité, cela affectera gravement la qualité du résultat. Les OP expérimentés et matures peuvent exécuter simultanément plusieurs produits et travailler avec plusieurs équipes si ces produits sont «liés» ou font partie d'un grand produit dont les fonctionnalités sont proches. Très probablement, seules des personnes très, très uniques peuvent faire simultanément, disons, un éditeur graphique pour les appareils mobiles et un simulateur de vol de l'armée. Pour être efficace, vous devez vous concentrer sur un seul objectif avant d'en jongler avec plusieurs.
Comment traiter : PO doit regarder d'un œil critique ses produits: dans quelle mesure une vision bien développée et formulée? Comment les équipes comprennent-elles et acceptent-elles cette vision? Dans quelle mesure l'arriéré est-il bien développé? Est-il transparent pour toutes les parties concernées? Existe-t-il une feuille de route du produit, est-ce clair pour tout le monde? L'équipe comprend-elle ce que feront les 2-3 prochains sprints? Dans quelle mesure l'utilisateur et le marché sont-ils bien connus? Quelle est la qualité de l'interaction avec l'équipe de développement? Si, dans certains de ces problèmes, une amélioration de la qualité est possible, vous devez vous laisser un seul produit et vous concentrer dessus.
PO et interaction d'équipe
Symptôme : la directive PO contrôle l'équipe, travaillant actuellement sur le schéma PM classique. Le PO prend toutes les décisions, même les plus petites, l'équipe se tourne vers lui sur n'importe quel problème.
Ce qui est mauvais : si l'OP est engagée dans la microgestion au sein de l'équipe, prend une part active au développement, puis, d'une part, elle démotive l'équipe et l'empêche de se développer ( il n'y a pas d'auto-organisation, car la responsabilité des décisions locales incombe à l'OP ), d'autre part, c'est mauvais pour le produit, car les efforts de PO sont dirigés à l'intérieur du processus, et le produit peut être laissé sans son attention.
Comment traiter : les OP doivent tuer les PM en vous-même, essayer des approches de gestion non directives et cesser de percevoir les gens comme une ressource. Si un schéma de gestion des directives est construit entre l'OP et l'équipe de développement, il vaut la peine d'impliquer un facilitateur externe ou interne qui peut ajuster l'interaction. Les limites de responsabilité entre l'OP et l'équipe de développement doivent être clairement définies - c'est la transparence. Il doit y avoir une relation de confiance entre l'OP et l'équipe: l'équipe fait généralement confiance à l'OP et à ses solutions de produits, et l'OP fait confiance à l'équipe et aux décisions qu'elle prend pour mettre en œuvre les éléments du carnet de commandes. Chacun comprend que le travail est effectué dans un seul but. L'un des outils possibles pour PO peut être son équipe «produit», qui comprend des analystes. Lorsque les hypothèses sont basées sur des chiffres et des données, elles sont plus crédibles. L'essentiel pour PO est de ne pas oublier de partager ces données avec l'équipe de développement. Si l'équipe n'est pas indépendante, le PO doit apprendre à déléguer. Ensuite, l'équipe sera obligée de prendre des décisions, en raison de ses responsabilités, et progressivement elle deviendra une équipe de mêlée.
Symptôme : PO et l'équipe de développement sont régulièrement en conflit, il y a une confrontation constante, il n'y a pas de compréhension mutuelle.
Ce qui est mauvais : l'OP et l'équipage naviguent dans le même bateau, si des communications efficaces ne sont pas établies entre eux, il est peu probable qu'un tel bateau puisse naviguer loin. Beaucoup d'énergie sera dépensée pour établir une interaction et non pour le développement de produits. Le but du PO et de l'équipe est le même, ce qui signifie qu'il ne devrait pas y avoir de conflits réguliers.
Comment traiter : Nous avons besoin d'un facilitateur expérimenté qui peut identifier l'essence du conflit, l'enlever et établir une relation de travail. Si tous les efforts ne mènent pas à une compréhension mutuelle, il vaut peut-être la peine de changer de tandem.
Symptôme : PO ne communique presque pas avec l'équipe. Par exemple, il n'est disponible que dans le cadre de réunions obligatoires (planification, revue de sprint).
Ce qui est mauvais : l'équipe crée un nouveau produit complexe ( Scrum est un cadre pour développer, livrer et maintenir des produits complexes. ), Par conséquent, il fonctionne dans des conditions de grande incertitude. Pour offrir une valeur maximale, ils ont besoin d'informations que, dans la plupart des cas, seul PO a ( c'est son travail ). En l'absence d'informations, des hypothèses et des décisions incorrectes peuvent être prises, de sorte qu'un temps précieux sera perdu lors de leur correction.
Comment décider : le bon de commande doit être disponible pour l'équipe, mais l'équipe ne doit pas en abuser, sinon le temps du bon de commande ne sera consacré qu'à des questions ad hoc. Un format d'interaction confortable pour tout le monde devrait être élaboré, dans lequel l'équipe reçoit en temps opportun de l'OP les informations et les décisions nécessaires que l'équipe ne peut vraiment pas prendre seule. Vous pouvez appeler des rétrospectives PO avec une certaine régularité et y discuter de la fréquence, des outils et du format de communication.
Symptôme : l'OP n'inculque ni ne promeut une culture de rétroaction d' équipe. Ou PO fournit une rétroaction à sens unique en filtrant les éloges ou les critiques.
Pourquoi c'est mauvais : Lorsque le PO ne donne pas régulièrement de commentaires honnêtes à l'équipe, cela démotive l'équipe. Pas de synchronisation des attentes et des résultats. L'équipe ne ressent pas de complicité, elle n'est pas réellement la créatrice du produit, elle remplit simplement sa fonction. «L'équipe fournit régulièrement des incréments. L'équipe reçoit régulièrement des commentaires honnêtes sur son travail »- cela semble être une bonne affaire.
Comment traiter : PO, bien sûr, ne doit pas facturer à l'équipe toute la quantité d'informations avec lesquelles il travaille lui-même, tout ce qu'il reçoit des utilisateurs et des analystes. Il doit agréger et publier des informations déjà importantes et compréhensibles pour l'équipe. Il est bon de proposer différents formats de commentaires, et pas seulement sur la base de chiffres secs ( par exemple: tests en direct, interviews, etc. ). L'équipe elle-même devrait rappeler à PO le besoin de rétroaction: poser des questions, établir un processus régulier pour recevoir la rétroaction. Si vous faites de PO le «propriétaire» de l'événement de révision de sprint et que vous le faites comprendre avec le fait que l'équipe a besoin de commentaires, cela rappellera au moins le travail de PO aux commentaires et peut conduire à une approche plus créative de l'organisation.
Interaction entre l'OP et les utilisateurs du marché
Symptôme : PO ne connaît pas "son" utilisateur; le produit voit un ensemble de fonctionnalités. PO ignore les demandes et les informations des utilisateurs existants. Ne communique pas avec les utilisateurs en direct.
Pourquoi c'est mauvais : tout d'abord, le produit est créé pour l'utilisateur qui a ( peut-être qu'il ne le sait pas encore ) le besoin satisfait par le produit. Et si vous ne connaissez pas et ne comprenez pas l'utilisateur, il est impossible de «porter la responsabilité d'atteindre la valeur maximale du produit», comme l'exige le guide Scrum.
Comment traiter : Il existe de nombreux outils différents pour mener des recherches qualitatives, par exemple des entretiens approfondis, un portrait d'un utilisateur, une carte de parcours client , des outils pour collecter des analyses qualitatives (vs quantitatives) , etc. etc. Vous devez essayer différents outils et laisser utile / travailler pour votre produit. La plupart de ces outils en sortie ont une visualisation du résultat, il convient de les placer devant l'équipe pour augmenter la transparence. Ces artefacts méritent d'être mis à jour de temps en temps. Vous pouvez organiser une équipe de découverte de produits pour vous aider à mener des recherches de qualité. Si le PO parvient à établir une interaction avec l'utilisateur, il peut utiliser ce contact, par exemple, pour la revue de sprint: donner à l'utilisateur un nouvel incrément, et l'équipe examinera comment l'utilisateur va faire face à la tâche, l'aide à la résolution qu'ils ont prévue dans l'incrément.
Symptôme : PO n'étudie pas le marché / les concurrents.
Ce qui est mauvais : le produit vit comme dans le vide et est dissocié de la réalité, vous devez être un visionnaire afin de créer un produit précieux dans de telles conditions.
Comment traiter : Il existe un certain nombre de pratiques pour les propriétaires de produits, comment étudier et créer des marchés, cela vaut la peine d'en essayer plusieurs et d'en laisser des bénéfiques. Dans cette activité, les PO peuvent être aidés par des analystes ou une équipe. Il est utile de rechercher de temps en temps des « océans bleus ». Et bien sûr, vous devriez vous inspirer des formations, des réunions culinaires et des conférences.
Conclusion
Une analyse des rôles restants apparaîtra dans les parties suivantes. Voyons maintenant comment ces informations peuvent vous être utiles. Nous avons examiné certains des symptômes possibles, en disant que quelque chose ne va pas dans la mêlée et les options pour changer la situation. Si vous le souhaitez, une liste de contrôle à la fin:
- En lisant presque chaque élément, vous vous êtes reconnu ( votre équipe / organisation ), c'est-à-dire vous avez une mêlée avec une compréhension non canonique. Ensuite, cela vaut la peine de poser des questions: avez-vous besoin de mêlée? Pourquoi avez-vous besoin de mêlée? Quelles tâches lui confiez-vous? La culture d'entreprise est-elle prête pour des valeurs et des principes agiles? Si vous avez des réponses et comprenez pourquoi la mêlée est nécessaire, et que vous pariez vraiment dessus, passez à la deuxième option. Sinon, arrêtez de pratiquer l'auto-tromperie.
- En lisant certains points, vous pensiez qu'il ne s'agissait pas de vous. Certains points vous ont poussé à raisonner et vous vous êtes souvenu de votre situation. Si c'est le cas, sélectionnez les éléments qui peuvent s'appliquer à votre situation. Imprimez-les sous forme de cartes. Discutez des symptômes avec l'équipe: sont-ils justes pour vous? Discutez des risques, êtes-vous d'accord avec eux ou voyez-vous des conséquences plus dangereuses des symptômes. Prenez ensuite la carte qui inquiète le plus l'équipe, le symptôme le plus dangereux en ce moment. Considérez la solution proposée, est-ce qu'elle vous convient? Trouvez collectivement comment vous pouvez améliorer la situation, comment soulager le symptôme. Et agissez! Après avoir traité un symptôme, passez au suivant, revenant périodiquement à l'examen général, pour vous assurer que les résultats que vous avez déjà obtenus ne se sont pas affaissés.
- Si vous avez tout lu et n'avez pas reconnu vos réalités dans ces situations, nous avons tout raison. Existe-t-il vraiment de telles organisations? Vous êtes de bons amis, assurez-vous de partager dans les commentaires comment vous y êtes parvenu!
PS J'espère que l'article fournira un outil de travail pour les équipes de mêlée pour l'auto-amélioration.
PPS Merci beaucoup pour l'illustration Sai Kin
UPD Partie 2 et partie 3 .