Chez Promsvyazbank, nous passons activement des équipes des canaux en cascade aux équipes de pointe. Quelque part cela a coûté quelques cônes, quelque part il est déjà possible de changer le râteau ... mais en conséquence, nous avons accumulé beaucoup d'expérience liée à la transformation des bords. Dans ce post, nous voulons partager l'expérience - tout d'un coup, vous découvrirez quelque chose de nouveau.
Naissance de l'idée de transition vers Edge
Habituellement, un idéologue apparaît dans l'entreprise qui infecte tout le monde avec le virus Edge, parlant des valeurs du travail d'équipe. Tout sera simple et rapide, le résultat étonnera l'imagination, l'argent coulera dans nos poches, et tous les employés seront heureux de se vautrer dans des poufs avec une tasse de café à la main et un bol sans fin de biscuits, promet-il.
Pour renforcer les réflexions sur Edge, des experts sont invités à prédire quelques centaines de jours de travail sur le produit et, par conséquent, la «dégradation» du produit, sa disparition. Et puis, peut-être, la disparition de l'entreprise. Un exemple est HTC et Blackberry. Comment ne pas répéter leur sort? Les consultants proposent une recette qui a été utilisée par des géants tels que Google, Amazon, Apple, à savoir un agile flexible.
Ce qui se passe généralement pendant la transformation
Et maintenant, vous avez appris toutes les phrases et phrases nécessaires pour avoir le droit de porter le fier nom de PMI Agile Certified Practitioner: «stand-up, toilettage, démo, équipe, planche, autocollants, tout a traversé la forêt avec leurs approbations.» Vous êtes des professionnels dans votre domaine, vous savez quoi et comment cela fonctionne, vous connaissez tous les nouveaux concepts, événements et processus nécessaires. Reste à réaliser une transformation agile. Voici une liste d'erreurs courantes.
- Il y avait des départements de développement et ils faisaient des équipes de pointe.
- La file d'attente de tâches sans fin pour les demandes de changement dans Jira a été transformée en un carnet de commandes RFC en un clin d'œil.
- Auparavant, les ressources étaient affectées de manière centralisée à une tâche, mais elles ont désormais réparti les tâches entre les développeurs.
- «Que va faire ce développeur avec nous? Et prenons cette tâche dans l'arriéré, il pourra le faire. "
- Vous vous fixez pour objectif de vous éloigner de l'évaluation des tâches en un mois de travail. En réponse, le développeur dit: "D'accord, commençons ce sprint et terminons le suivant."
- La tâche n'est pas coordonnée avec le service de sécurité et les avocats? Introduisons des vacances normatives et ignorons ce moment.
- Les tâches sont-elles attribuées par le patron? Ensuite, nous faisons un bord, une structure plate, mais "je serai toujours le patron".
Qu'obtenons-nous finalement?
La structure n'a pas changé. Les chefs définissent les tâches des subordonnés. Les gens ont une explosion cérébrale, de nombreux dirigeants, ces dirigeants fixent simultanément différentes tâches avec des délais clairs. Les tâches étaient simplement mesurées en sprints, pas en mois.
Que faire est incompréhensible, comment faire est incompréhensible. Pas de documentation! Toute l'équipe est assemblée à des réunions tout le temps, où viennent de vieux technologues et programmeurs endurcis. Ils regardent les employés de l'équipe comme s'ils venaient au zoo pour observer le comportement des gibbons dans un pack.
Le Scrum Master parle de Definition of Ready et Definition of Done. Néanmoins, ils comprennent que c'est important et nécessaire, pourquoi les développeurs résistent-ils?
En ce moment, une tâche malheureuse arrive malgré les délais imposés par la direction, et le jeune, toujours debout sur ses pieds, agile meurt sous les assauts des ennemis et des zombies.
Comment est-ce nécessaire?
Vous ne pouvez pas suivre aveuglément les schémas d'entreprises prospères. Il est plus facile d'expliquer ici par une analogie - par exemple, par le football. Imaginez que vous êtes entraîneur, votre équipe perd, cinq minutes avant la fin du match. Il existe un exemple de plan sans faille utilisé par le célèbre entraîneur Ernesto Valverde. Selon lui, l'attaquant Luis Alberto Suarez fait irruption dans la surface de réparation, il est démoli, le juge nomme une pénalité. Lionel Messi se rapproche du ballon et tire exactement dans le coin supérieur le plus éloigné du gardien de but. Plan impeccable. Mais vous n'êtes pas Valverde, et vous n'avez pas Suarez et Messi dans l'équipe. C’est tout. Tu as perdu.
De plus, nous commençons à nous accrocher aux processus, oubliant pourquoi nous les implémentons dans notre travail. Par conséquent, je vous conseillerais de formuler un objectif et de l'accrocher dans un endroit bien en vue. Comment fixer des objectifs, vous le savez tous. L'objectif doit être concret, mesurable, réalisable, significatif et limité dans le temps. Qu'est-ce que tout cela signifie concrètement?
En pratique, cela signifie que la chose la plus importante dans tout ce processus est le client. Par conséquent, assurez-vous de passer du temps et de découvrir qui est votre vrai client, qui vous rapporte de l'argent. Décrivez sa personne. Toutes les entreprises n'ont pas une réponse évidente à cette question.
Pour le client, vous fabriquez le produit, et tel qu'après son utilisation, le client reste heureux. Le produit doit être:
- utile, c'est-à-dire résoudre un problème client important;
- de haute qualité, c'est-à-dire répondre ou dépasser les attentes des clients;
- fait et offert à temps, pas dans un an.
Le produit, à son tour, est créé par l'équipe. En fait, le produit et l'équipe sont étroitement liés. Comme l'a dit l'équipe des noyés sur l'épave des Pirates des Caraïbes: "Une partie de l'équipe fait partie du navire." Un bon produit ne peut exister sans une bonne équipe, et vice versa. Et c'est la principale raison pour laquelle la plupart des tentatives de transformation des bords s'effondrent. Pour éviter cette situation, nous, à Promsvyazbank, avons commencé à lancer chaque équipe en choisissant une gamme de produits et un propriétaire de produit.
Beaucoup a été dit et écrit sur la façon dont le propriétaire du produit devrait être. Tout cela est vrai, la principale difficulté est de trouver la personne dont vous avez besoin. Voici ce que fait le propriétaire du produit:
- fixe un objectif;
- décrit l'arriéré de niveau supérieur;
- réfléchit au KPI, par lequel il serait possible de surveiller en permanence l'approche de l'objectif; y compris n'oubliez pas un client heureux;
- calcule comment les tâches de backlog affectent les KPI.
Le propriétaire du produit n'est pas la personne qui sait traduire efficacement les priorités de l'hôtel de quelqu'un d'autre, mais la personne qui le souhaite. Il veut faire le meilleur produit pour le client, pour le faire comme il le voit tous les jours.
L'équipe de développement est composée de personnes responsables qui peuvent développer le produit de manière indépendante et indépendante. L'équipe doit avoir toutes les compétences nécessaires pour atteindre le résultat. Les dépendances externes ne doivent pas être contrôlées, elles doivent être éliminées en incluant ou en formant les bonnes personnes dans une équipe. Certainement pas besoin de faire une équipe avec des rôles redondants. Pour être d'accord, l'équipe doit être aussi petite que possible. Supprimez mentalement le rôle de l'équipe; est-ce que cela empirerait sans lui?
La meilleure question pour l'équipe au départ: "Avez-vous assez pour atteindre votre objectif?" Et la pratique la plus efficace pour former la composition des participants est la conception de soi, lorsque les employés eux-mêmes déterminent qui et avec qui travailler. Nous avons essayé de le faire déjà au début - lorsque nous avons proposé de faire la rotation nous-mêmes, cela a bien fonctionné.
Maintenant qu'il y a une équipe, elle doit s'efforcer de s'assurer qu'à la fin du sprint, il y a une augmentation de la «qualité» du produit avec un bénéfice commercial clair.
Une bonne allégorie du travail d'équipe à Scrum est une compétition de bateaux-dragons. Le batteur donne le rythme de la synchronisation de l'aviron collectif et au début du bateau, un barreur définit la direction. Dans notre entreprise, le propriétaire du produit gère la vision du secteur d'activité et le Scrum Master aide l'équipe à garder le bon rythme pour un travail synchrone sur tous les fronts. Un tambour est une planche de mêlée, un lieu de rencontre commun pour les événements d'équipe.
L'erreur principale ici est de tenter de nommer un Scrum Master ou même de combiner plusieurs rôles en une seule personne. Peut-être que cela fonctionnera dans des équipes matures, mais ce n'est certainement pas votre cas. Et même dans des équipes matures, le propriétaire d'un produit ne peut jamais être un scrum master en même temps. Vous devriez trouver un maître de mêlée et ne pas nommer quelqu'un parmi les personnes qui viennent à portée de main. Une telle personne aidera l'équipe à devenir plus cohérente et efficace d'un sprint à l'autre.
Pour le développement de pratiques d'ingénierie, vous devez créer non pas un département qui imposera les bonnes choses comme les tests unitaires, mais une communauté de développeurs intéressés par cela. Si de telles initiatives naissent d'en bas, elles seront soutenues à tous les niveaux.
Le travail d'équipe doit être transparent pour toutes les parties intéressées. C'est le devoir de l'équipe et son avantage significatif. L'équipe construit elle-même le processus de son travail et tous les problèmes qui peuvent survenir seront également résolus de manière indépendante au cours du processus de croissance.
Et le dernier conseil: utilisez des outils simples. Tous les champs et processus de Jira sont facilement remplacés par une carte physique avec un ensemble d'aimants.
Où en sommes-nous?
Nous avons régulièrement de nouvelles équipes produits. Ils ne discutent pas de l'agilité, mais font de nouvelles fonctionnalités. Grâce aux membres des équipes, des produits sont créés, utiles et pratiques pour les clients et rentables pour une banque.