"Nous nous couchons, nous allumons des lumières, dans l'Univers nous sommes les seuls." Il semble que cette ligne de la chanson du groupe Splin puisse être reconnue comme la bande originale de l'introduction de la pratique Sprint Review dans Dodo Pizza.
Avertissement: dans un article, Anton décrit la première version d'une revue de sprint viable. Nous en avons déjà un plus avancé, mais à ce sujet dans la prochaine série.
La première tentative de lancement de la pratique de révision de sprint chez Dodo Pizza a lamentablement échoué.
Peut-être que vous pensez que les pratiques de la chaîne de pizza Scrum sont généralement inutiles. Cependant, l'un des principaux avantages de Dodo Pizza est, curieusement, son propre système informatique, qui gère tous les processus dans 495 pizzerias de la chaîne dans 12 pays.
Plus de 80 développeurs et analystes travaillent sur ce système aujourd'hui (et plus de deux cents viendront avec le temps). En tant que startup à croissance rapide, nous visons une efficacité maximale, par conséquent, nous utilisons de nombreux cadres de «développement flexible»: Scrum, LeSS, programmation extrême.
Mais qu'est-ce que cette mêlée, demandez-vous, sans revue de sprint? Et vous aurez raison.
Comme vous le savez, la revue de sprint donne le rythme à l'équipe et motive à terminer le travail à la fin du sprint. Plus important encore, il aide à créer un produit précieux dont une entreprise a besoin, et pas seulement à effectuer des tâches de backlog. Donc, en tout cas, ils écrivent dans des livres.
Cependant, pour une raison quelconque, cette approche n'a pas fonctionné pour nous. Par exemple, lors d'une des premières revues de sprint, nous avons montré aux franchisés Dodo Pizza du Kazakhstan leur nouveau site - dodopizza.kz. Les commentaires ont été inspirants: les partenaires ont déclaré que le site était magnifique et, dans le contexte des concurrents, il ressemblerait à un chef-d'œuvre.
Lorsque nous l'avons déployé, il s'est avéré qu'il manquait beaucoup de choses. Autrement dit, nous avons passé du temps sur la révision du sprint, mais nous n'avons en fait pas reçu de commentaires utiles de la part des partenaires.
En général, nous avons rapidement arrêté ces critiques de sprint.
Après quelques mois, j'ai décidé de réessayer. À ce moment-là, nous avions déjà huit équipes travaillant sur le même arriéré dans le cadre LeSS. Nous avons essayé de suivre toutes les règles de Scrum à grande échelle, et l'absence de révision de sprint a été l'une des violations.
J'ai préparé à l'avance le fait qu'au début, tout sera mauvais, et vous devrez rechercher le format correct en utilisant la méthode d'essai et d'erreur. Après chaque examen, j'ai demandé aux participants d'évaluer l'événement sur une échelle de 1 à 10 (Bottom - Omnische). Au début, les notes étaient très basses, plus proches du "bas". Cependant, nous n'avons pas abandonné, expérimenté, et quelque part dans quelques mois, ils ont commencé à passer à l'Ogniste.
Voilà ce que nous avons changé
Faire ses devoirs
Nous avons réalisé que vous ne devez pas consacrer moins de temps à la préparation qu'à la revue de sprint elle-même - voire plus. L'événement prend deux heures et je me prépare pour trois heures. Après tout, vous devez coordonner les objectifs avec les équipes, organiser avec les partenaires, les gestionnaires de la société de gestion, les employés des pizzerias et d'autres invités, réserver des conversations, faire une affiche, trouver des facilitateurs, instruire, établir et dessiner un calendrier, raccrocher des chats flip pour recueillir des commentaires, etc. Sans tout cela, il y aura simplement le chaos.
Ne pas montrer inachevé
Au début, nous avons montré des fonctionnalités à moitié terminées. Mais nous avons réalisé que c'est ainsi que nous trompons les équipes et, surtout, les clients. Une fois, nous avons montré le PDG d'une entreprise de géoservices qui met en cache les données cartographiques. Ensuite, lors du prochain examen, il a été montré à nouveau - uniquement avec des bugs corrigés. Lorsque nous sommes entrés pour la troisième fois et avons montré le même service, mais déjà sur le site Web de combat, le PDG avait une question naturelle: "Qu'est-ce que tu montres la même chose pour la troisième fois?"
Maintenant, lors de la revue de sprint, nous montrons uniquement ce qui est affiché sur le site de combat. Si quelque chose est presque prêt - il n'y a que des bogues à corriger, tester et mettre en page - nous ne les montrons pas.
Négociations au lieu d'un espace ouvert
Les auteurs de LeSS recommandent une revue de sprint sous la forme d'un "bazar". Toutes les équipes doivent montrer leur travail dans une grande salle, et les personnes intéressées peuvent se rendre aux stations qui les intéressent. Nous l'avons essayé plusieurs fois, il s'est avéré bruyant et difficile.
Les écrans des ordinateurs portables sont petits, rien n'y est visible, le bruit des stations voisines rend la concentration difficile et le mouvement constant des gens crée le chaos. Par conséquent, maintenant dans la salle de conférence, tout le monde se rassemble seulement au début et à la fin. L'action principale se déroule dans les salles de réunion, où chaque équipe présente son travail. Là, équipement, grands écrans, vous pouvez vous asseoir confortablement, les participants à distance sont connectés et il y a une place pour recueillir les retours.
Les transitions sont interdites!
Au début, nos parties prenantes se déplaçaient librement entre les équipes. Mais c'était ennuyeux. Imaginez que vous avez commencé à dire quelque chose et en dix minutes une nouvelle personne rejoint le groupe et pose des questions sur ce dont vous venez de parler.
Commencez à répondre - les autres s'ennuient. Ignorer - la personne est bouleversée. Par conséquent, nous avons décidé d'interdire les mouvements entre les groupes. J'ai choisi le sujet qui vous intéresse - asseyez-vous dans la salle de réunion pendant vingt minutes jusqu'à la prochaine pause.
Chers invités
Nous avons réalisé que la composition des "invités" est d'une grande importance. Rien ne motive un développeur comme apparaître sur un PDG de revue de sprint. Surtout lorsque vous devez lui montrer des trucs techniques comme un service dans un cube ou transférer Auth vers .Net Core. Nous devons expliquer pourquoi nous faisons cela. Fedor Ovchinnikov, PDG de Dodo Pizza, dynamise et sait égayer tout le monde et esquisser les horizons du développement de l'entreprise en trois minutes. Eh bien, lorsque nous montrons des fonctionnalités client, par exemple, un concepteur de demi-pizza dans une application mobile, nous appelons maintenant des invités externes, généralement des connaissances et des amis de Facebook.
Membres supprimés
Il est facile de tenir une réunion lorsque tout est dans une seule pièce. Mais nous avons de nombreux employés à distance à Syktyvkar, Nizhny Novgorod, Kazan et Goryachy Klyuch. Il est également important pour eux de participer.
Au début, les "travailleurs à distance" se sont plaints d'être malentendants et de ne rien voir. Maintenant, nous prenons soin d'eux ainsi que des participants hors ligne. Il y a des éléments dans la liste de contrôle de la préparation de la revue de sprint qui nous rappellent de vérifier la connexion et de configurer l'équipement. Nous diffusons sur Slack, et plus récemment, nous avons diffusé l'événement sur notre chaîne YouTube Dodo Pizza .
Avis de non-responsabilité
Quand il a commencé à sembler que tout allait bien et qu'il n'y avait nulle part où améliorer le format, nous nous sommes posé la question: ne faisons-nous pas des ordures? Un examen de sprint est un événement assez coûteux (si vous le regardez cyniquement - en termes de nombre de participants, de leurs salaires et des heures passées). Utilisons-nous ces deux heures de manière aussi productive que possible? En conséquence, nous avons décidé de refuser complètement de recueillir des commentaires lors de la revue de sprint.
Sous la forme d'un tel événement, cela ne peut pas être fait de manière approfondie et qualitative (rappelons un cas avec le Kazakhstan). De plus, nous collectons la plupart des critiques importantes et de haute qualité pendant le sprint, attirant toutes les personnes intéressées, des clients internes aux utilisateurs ... Vous serez surpris, même le Scrum Guide ne dit pas que les commentaires devraient être collectés sur la revue de sprint: "Pendant la revue de sprint:" Pendant la revue de sprint , l'équipe Scrum et les parties prenantes collaborent sur ce qui a été fait dans le Sprint. " L'équipe et les parties prenantes, pas les utilisateurs. Interagissez, ne recueillez pas de commentaires. Un sens complètement différent.
Ouvrez la "cuisine"
Toutes les parties prenantes ne sont pas profondément immergées dans le processus de développement. Mais tout le monde veut savoir ce qui se passe là-bas. C'est à ces fins que nous avons décidé de réorienter la revue de sprint.
Nous montrons toujours le travail accompli, mais en plus de cela, les équipes racontent l'histoire derrière les nouvelles fonctionnalités. Quel était le but? Que s'est-il passé pendant le sprint? Qu'est-ce qui nous a distraits ou nous a empêchés d'atteindre notre objectif? Quelles mesures avons-nous prises pour sauver l'objectif? Cela aide: de cette façon, il devient clair pour les gestionnaires, par exemple, pourquoi «cacher le courrier électronique du client avec des étoiles de contrôle» est une tâche très difficile («une demi-heure de travail d'un programmeur», comme le pensaient les gestionnaires). À l'inverse, un tel dialogue aide les développeurs à penser en termes de «clients» et de leurs problèmes, plutôt qu'en termes de solutions spécifiques sur lesquelles ils travaillent.
C'est peut-être la principale chose que nous avons changé dans notre approche. Les progrès sont évidents, mais comme toujours, il y a encore quelque chose à améliorer. Les expériences se poursuivent.
La principale chose que nous avons comprise est que nous n'avons pas besoin de nous accrocher aux formats proposés dans les manuels Scrum. Vous devez essayer, faire des erreurs et expérimenter. Il n'y a pas de solutions universelles - vous devez rechercher celles qui fonctionnent dans votre situation.
Par conséquent, je veux vous avertir à la fin: ne copiez pas notre format. Il travaille bien avec nous car il est né à la suite de nombreuses expériences. Recherchez votre approche - et vous réussirez. Ce ne sera certainement pas pire.