SCRUM est devenu si populaire qu'ils essaient maintenant de l'implémenter presque partout. Dans les grandes entreprises, il s'avère parfois que SCRUM est implémenté dans un souci de reporting, ou pour être «progressif» et «à la mode». En conséquence, la situation, qui semble être celle d'un gestionnaire responsable, a placé la prochaine case à cocher, disent-ils, il était nécessaire de mettre en œuvre la méthodologie - mise en œuvre, bien fait, mais au lieu de quelques améliorations qualitatives, le soi-disant «Zombie SCRUM» apparaît sur la sortie. C'est à ce moment que le framework est officiellement implémenté, mais personne n'y travaille normalement. D'où le nom.
Je m'appelle Oleg Egorkin, je suis un coach agile à Rostelecom, et dans ce post, je vais expliquer pourquoi la «mêlée de zombies» apparaît en général, comment l'éviter et comment s'assurer que tout est prêt pour que l'entreprise lance une équipe de mêlée.
Approches existantes pour exécuter des commandes
Parfois, ils essaient de lancer une équipe Scrum en informatique, c'est-à-dire de bas en haut. C'est à ce moment-là que les développeurs eux-mêmes et les chefs de département comprennent qu'il est temps, pour ce produit, nous avons besoin d'une cicatrice. Le plus, c'est que l'initiative vient des personnes concernées. Moins - avec cette approche, les entreprises ne sont pas impliquées. Et si l'entreprise n'est pas impliquée, la structure organisationnelle elle-même avec cette approche change soit très légèrement, soit (le plus souvent) ne change pas du tout. En conséquence, la probabilité qu'une telle mêlée devienne une «mêlée de zombies» est très élevée. Bien sûr, il ne sera pas tel que le premier jour, tout ira mal comme on le souhaiterait. Mais après environ six mois, les gens se rendront compte que tous les inconvénients qui étaient au démarrage ne sont allés nulle part. D'où la frustration qui affecte toujours tristement le produit.
Il y a une histoire inverse - de haut en bas. Ce n'est pas non plus la chose à rechercher. À titre d'exemple, rappelez-vous, il y a plusieurs années, à l'aube d'Agile, 50 nouvelles équipes ont été lancées dans une banque verte sur les instructions des hautes autorités «d'ici l'été», et d'ici la fin de l'année - 5000. C'est l'approche même de la mêlée pour la mêlée. Que se passe-t-il dans ce cas? Les gens se précipitent pour faire des courses. Sous l'écran, tout ce qui n'est pas vissé commence à ramer. Scrum dans cette histoire n'est jamais une amélioration du développement et de nouvelles méthodologies, c'est juste une tique dans le KPI du manager. Le résultat est une «mêlée de zombies».
Et il y a une troisième approche - l'initiative est codée en haut et en bas. Nous avons eu de la chance, et à Rostelecom tout à l'heure. Une chose dans quoi. Au niveau de la haute direction, il y a une assistance constante à toutes les approches transformationnelles au sein des équipes. En même temps, personne ne met en place des plans «ambitieux».
Pour les grandes et très grandes entreprises, ce n'est pas tout à fait familier. Cela fonctionne comme ceci: une fois par mois, je donne une formation de base d'une journée sur Agile. Des informaticiens et des professionnels viennent assister aux formations, 25 personnes dans le groupe. J'essaie d'en parler le plus largement possible et largement. Après un certain temps (cela peut prendre entre une semaine et plusieurs mois), les collègues, digérant les connaissances acquises, reviennent avec une demande compréhensible de créer une équipe de mêlée.
À propos de la liste de contrôle
Il y a deux types de demandes pour moi - soit pour lancer une équipe dans le cadre de la transformation d'un produit existant, soit pour une équipe pour un nouveau produit. Pour traiter ces demandes, j'ai rédigé une liste de contrôle spéciale, à l'aide de laquelle je vérifie toutes les conditions nécessaires à l'exécution. Si la candidature ne passe par aucun point et ne remplit pas les conditions préalables, nous n'exécutons pas l'équipe. C'est un besoin reconnu - si vous marquez franchement au moins un des points et dirigez l'équipe sans lui, cela n'apportera toujours pas de résultats. Eh bien, outre le fait que pas faible démotive tous les participants.
Si quelqu'un de l'informatique vient me voir avec une application, je lui demande de parler à l'entreprise et de revenir ensemble. Parce que l'activité chez Agile est un élément clé. De là, nous avons le premier élément de la liste de contrôle:
1. Une équipe agile devrait vouloir créer une entreprise
Ici, comme avec les vampires - ils ne peuvent pas simplement entrer et entrer dans la maison, ils doivent être invités. Avec les coachs Agile, c'est la même chose, dans le sens où un changement doit être demandé.
Les professionnels et les informaticiens remarquent que certains produits fonctionnent dans des conditions de marché difficiles, ils me contactent eux-mêmes et me disent - l'approche doit être modifiée. Et ici, si vous êtes très chanceux, alors la demande arrive du tout au tout début, quand il n'y a pas encore d'équipe, mais il y a une idée sous laquelle les gens peuvent commencer à se rassembler. Dans le même temps, tout le monde comprend qu'une spécification claire pour le produit ne peut pas être formée, elle changera en fonction du modèle commercial et il n'est pas clair quel modèle fonctionnera et lequel ne fonctionnera pas.
En général, il est très important que l'entreprise soit impliquée.
Il est également important que le moteur de cette implication soit quelque chose de tangible, et pas seulement de battage médiatique. Par conséquent, je vérifie que les motivations de l'entreprise se répartissent à peu près comme suit:
- réduire le délai de mise sur le marché si cet indicateur est trop grand;
- accroître l'efficacité du travail d'équipe;
- accroître la gérabilité face à l'évolution des priorités.
Si l'un de ces trois points est, alors tout va bien, c'est un signe certain que l'équipe commence avec des attentes adéquates.
2. Il doit y avoir un produit pour le lancement
Tout d'abord, c'est logique. Il est stupide de diriger une équipe de produits pour un produit lorsque vous n'en avez pas. Et peu importe ce que nous commençons tous à faire autour de lui - autour d'un produit ou d'un service.
3. Le propriétaire du produit doit avoir une vision et une feuille de route pour le développement
De plus, la feuille de route pour un an à l'avance est un minimum, sous la forme d'une compréhension au plus haut niveau de ce qui devra généralement être fait. Même si une personne a 3-5 hypothèses sur les modèles d'affaires qu'elle appliquera, ce qu'elle veut explorer. Si je vois qu'il y a une feuille de route, continuez.
4. Les entreprises doivent avoir de l'argent
A savoir, le budget d'une équipe interfonctionnelle. Parce que le produit doit être embauché pour une équipe à temps plein, et l'entreprise doit être prête à payer pour cela à l'horizon environ un an à l'avance. Je m'assure que tout cela est fait, je regarde quel centre de responsabilité financière est impliqué dans cela, pour que ça ne fonctionne pas qu'il y ait une idée, qu'il y ait un désir de lancer une équipe, mais qu'il n'y a pas d'argent.
5. Doit être le propriétaire du produit dans l'entreprise
Le propriétaire. Pas les propriétaires. Un propriétaire.
Une personne qui est 100% dédiée à ce produit particulier. Il y a eu un cas où deux managers sont venus et ont dit - nous voulons créer un produit de motivation et d'éducation (une telle chose interne pour les employés). Je leur dis - super, mais avez-vous un propriétaire de produit? Ils répondent - oui, bien sûr, un propriétaire du produit est pour la formation, et l'autre - pour la motivation. Le produit est motivant et éducatif.
À ce moment-là, j'ai demandé à réfléchir et à convenir qui sera responsable de l'ensemble du produit. Cela s'est avéré être une question très difficile et l'équipe n'a réussi à être lancée que six mois plus tard.
Un produit - un propriétaire de produit. C'est important.
6. Tous les participants de l'équipe de développement doivent également être alloués à 100% pour le produit.
Si quelqu'un de l'équipe de développement travaille à 50%, 30%, 10% - ce n'est pas tout de suite. Il faut être complètement dans le produit. Mais en même temps, je n'exige pas la présence d'équipes colocalisées. Dans nos conditions, c'est tellement rare, Rostelecom est très grand, nous avons beaucoup de filiales et d'affiliés (filiales), où travaillent les développeurs inclus dans les équipes. Et ils peuvent être répartis à travers Moscou, Peter, Krasnodar et d'autres villes de notre immense patrie. Il est parfois difficile et long de constituer rapidement une équipe à Moscou, mais souvent cela ne fonctionne pas du tout.
Par conséquent, j'avance, mais il y a une contre-exigence - que l'équipe se réunisse pendant les 2 premiers jours lorsque la formation est en cours, puis tous les six mois pour maintenir des contacts personnels et discuter des problèmes actuels.
7. Méthode de paiement du produit
C'est aussi une chose importante, ainsi que beaucoup de choses liées à l'argent. Lorsque le propriétaire du produit dispose d'un budget, celui-ci est dépensé sur demande. Autrement dit, les savoirs traditionnels sont écrits sur la commande, une évaluation est effectuée pour sa mise en œuvre, puis des fonds dans le budget sont alloués pour ce cas. Cela semble facile. Mais il y a des nuances.
Lorsque vous passez à un travail personnalisé, à la fin de l'exécution des commandes, il devrait y avoir des procédures pour accepter et transférer le produit en opération. Et comme les savoirs traditionnels ont déjà été approuvés, il est extrêmement difficile d'y apporter des modifications. Toute modification doit être renégociée, approuvée. Il s'agit d'un processus très complexe et lent, incompatible avec une réaction rapide aux changements.
Qu'avons-nous fait pour ne pas nous enfouir là-dedans et ne pas devenir fou.
Vous pouvez travailler sur Time & Materials lorsqu'un contrat est conclu et que le temps de toute l'équipe est payé. Autrement dit, il existe une équipe qui travaille pour le propriétaire du produit. Ses services sont payés mensuellement ou trimestriellement. Mais dans notre pays, cela ne peut se faire sous sa forme pure, car il existe des restrictions bureaucratiques.
Par conséquent, nous avons commencé à travailler dans le cadre du développement personnalisé au niveau des commandes trimestrielles avec fixation des feuilles de route (pas les savoirs traditionnels), tandis que la commande ne détaille pas comment la feuille de route sera mise en œuvre. Le propriétaire du produit a la flexibilité de générer un backlog. Et lorsque le trimestre se termine, nous déchargeons de la diète une liste des tâches accomplies et sur sa base nous formons des actes signés et payés. Il en résulte le même temps et le même matériau.
Et ici, il n'est pas nécessaire de se conformer clairement aux savoirs traditionnels, car il n'y a pas de savoirs traditionnels. Des exigences qui n'ont plus de sens après avoir testé des hypothèses ne peuvent tout simplement pas être faites.
8. L'équipe ne doit pas avoir de KPI, sauf ceux associés au produit
C'est important précisément parce que les développeurs sont embauchés par des filiales, où les KPI sont habitués à se mettre en place pour le recyclage (c'est à ce moment que le développeur doit être constamment occupé par quelque chose). En fait, presque tous les intégrateurs travaillent comme ça - dans les conditions de pénurie d'un projet (ou de projets concurrents) du même développeur, ils peignent sur plusieurs projets. Et puis, pour que l'entreprise soit dans le noir, ils ont mis le développeur en KPI qu'il devrait toujours être au moins 85% occupé. Autrement dit, il a en fait un certain KPI, ce qui le motive à s'intégrer dans le nombre maximum de projets afin d'adapter son élimination aux nombres requis.
Heureusement, l'équipe de mêlée n'a pas un tel besoin (de facto c'est 100%). Je m'assure que les équipes n'ont pas d'autres KPI en plus de l'épicerie.
Total
Ceci est ma liste de contrôle. Selon elle, je vérifie toutes les équipes avant de commencer, et comme nous avons une approche co-directionnelle, je peux exiger un changement de conditions si l'équipe ne passe pas par au moins un de ces points. Par conséquent, le résultat est uniquement les équipes qui sont prêtes à mettre en œuvre les valeurs de l'approche agile.
Si la candidature de l'équipe passe par tous ces points, l'étape suivante commence - la formation et le lancement de l'équipe.
Dont je parlerai dans le prochain post =)