Qu'obtenez-vous lorsque vous traversez un service informatique, un examen, une détermination et une pizza Sprint défectueux? Grandeur, c'est quoi.
Notre première tentative d'introduire
des critiques de sprint chez Dodo Pizza a échoué de façon spectaculaire. On pourrait penser, peut-être, qu'une chaîne de pizzas n'a pas du tout besoin de pratiques Scrum. Cependant, aussi étrange que cela puisse paraître, l'un des principaux avantages de
Dodo Pizza est son propre système informatique qui contrôle tous les processus de travail de 430 pizzerias dans 11 pays.
Plus de 60 programmeurs et analystes travaillent actuellement sur notre système, et nous prévoyons d'augmenter ce nombre à
plus de 200 . Comme toute start-up à croissance rapide, nous visons une efficacité maximale, nous utilisons donc beaucoup de frameworks Agile, y compris Scrum, LeSS et la programmation extrême. Mais comment utilisez-vous Scrum sans revues de sprint? C'est la question que vous pourriez vous poser - et vous auriez raison.
Comme nous le savons, une revue de sprint fixe le rythme de travail d'une équipe et la motive à terminer la tâche à la fin du sprint. Plus important encore, un examen de sprint permet de créer un produit qui est précieux pour l'entreprise, et pas seulement de résoudre les problèmes de l'arriéré. Du moins, c'est ce que disent les livres.
Mais d'une manière ou d'une autre, cette approche n'a jamais fonctionné pour nous. Par exemple, lors de l'une de nos premières revues de sprint, nous avons présenté un nouveau site Web (dodopizza.kz) à nos franchisés du Kazakhstan. Les commentaires ont été inspirants, nos partenaires nous ont dit que le site Web avait fière allure, et en comparaison avec les concurrents, c'était pratiquement un chef-d'œuvre. Mais après son lancement, il s'est avéré qu'il faisait gravement défaut. Nous avions donc perdu du temps sur une revue de sprint mais nous n'avions pas reçu de commentaires utiles.
Bientôt, nous avons complètement arrêté ces critiques de sprint.
Plusieurs mois se sont écoulés et j'ai décidé de réessayer. À ce stade, nous avions huit équipes travaillant sur un seul carnet de commandes dans le cadre
LeSS . Nous avons essayé d'adhérer à toutes les règles Scrum à grande échelle, et l'annulation des critiques de sprint était une violation.
Je me suis préparé à de mauvais résultats initiaux - il était clair que nous devions trouver le bon format par essais et erreurs. Après chaque examen, j'ai demandé aux participants de l'évaluer sur une échelle de 1 à 10. Au départ, nos notes étaient très faibles, mais nous n'avons pas abandonné et avons continué à expérimenter, donc en quelques mois, les examens ont commencé à déplacer vers la partie supérieure de l'échelle.
C'est ce que nous avons fait différemment.
Faire nos devoirs
Il est devenu clair que la préparation de la revue de sprint ne demande pas moins de temps que la revue de sprint elle-même, voire plus. Un examen prend deux heures et je passe trois heures à le préparer. Il y a des objectifs d'examen à discuter et à convenir avec l'équipe, les partenaires, les dirigeants de la société mère, les employés et les autres invités à qui parler, des salles de conférence à réserver, une affiche à faire, des facilitateurs à trouver et à instruire, un calendrier à mettre en place , des tableaux à feuilles de rétroaction à accrocher, etc. Et sans tout cela, le chaos s'ensuit.
Si ce n'est pas fini, ne le montrez pas
Au début, nous avons montré des fonctionnalités à moitié prêtes lors des revues de sprint. Il nous est alors venu à l'esprit que cela impliquait de tromper nos équipes et, pire encore, nos clients. Nous avons montré une fois au PDG un service de cartographie mettant en cache les données cartographiques. Lors du prochain examen, nous l'avons montré à nouveau, avec des bugs corrigés. Lorsque nous l'avons apporté pour la troisième fois et l'avons montré sur le site Web en direct, il avait une question très légitime: pourquoi diable doit-il regarder la même chose encore et encore? Maintenant, dans les revues de sprint, nous ne montrons que les fonctionnalités qui sont déjà sur un site en direct. Si quelque chose est presque terminé et que nous avons juste besoin de corriger des bogues, de le tester et de le déployer, nous ne le montrons tout simplement pas encore.
Salles de conférence au lieu d'un espace ouvert
Les créateurs de LeSS recommandent d'effectuer une revue de sprint comme un «bazar», où toutes les équipes démontrent leur travail dans une grande salle, et les gens visitent les stations qui les intéressent. Nous l'avons essayé plusieurs fois, et c'était beaucoup de bruit et de confusion.
Les écrans d'ordinateur portable sont petits et inconfortables, vous ne pouvez pas vous concentrer très bien à cause du bruit dans les autres stations, et vous obtenez le chaos lorsque les gens errent constamment. Alors maintenant, nous nous réunissons tous dans une grande salle de conférence seulement au début et à la fin de l'examen. L'action principale se déroule dans de petites salles de conférence, où chaque équipe présente son travail. C'est plus confortable, il y a tout l'équipement nécessaire, de grands écrans et un accès Internet pour les participants à distance, et vous pouvez recueillir des commentaires en toute tranquillité.
L'errance n'est pas autorisée
Au début, les intervenants marchaient librement entre les équipes, mais c'était ennuyeux. Imaginez que vous faites votre présentation, que vous parlez depuis dix minutes, puis que quelqu'un arrive et vous pose des questions sur les choses que vous venez de couvrir.
Si vous répondez, tout le monde s'ennuie. Si vous ne le faites pas, cette personne peut en vouloir. Nous avons donc décidé de ne pas autoriser l'errance entre les groupes. Si vous avez choisi un sujet, veuillez vous asseoir dans une salle de conférence et attendre 20 minutes jusqu'à la prochaine pause.
Chers invités
Nous avons réalisé que la liste des invités est très importante. Rien ne motive plus un développeur qu'un PDG d'une entreprise visitant une revue de sprint, surtout lorsque vous montrez un truc technique, comme l'hébergement d'un microservice dans Kubernetes ou la migration d'un composant Auth vers .Net Core. Ensuite, vous devez expliquer pourquoi vous avez même fait tout cela en premier lieu.
Fyodor Ovchinnikov, le PDG de Dodo Pizza , peut charger le public d'énergie, remonter le moral en trois minutes et décrire les grandes perspectives du développement de l'entreprise, mais lors de la démonstration de fonctionnalités frontales, comme une fonctionnalité de fabrication de pizza dans notre application mobile, nous invitons des invités extérieurs, principalement des connaissances et des amis de Facebook.
Un présentateur drôle et une casquette
Il s'avère que le présentateur représente la moitié du succès d'une revue de sprint intéressante et passionnante. Beaucoup de gens ont joué ce rôle; Je l'ai essayé en premier, avec l'aide de nos Scrum Masters.
Ensuite, Sergey Gryazev, notre propriétaire de produit d'application mobile, est devenu présentateur, et maintenant nous ne pouvons pas imaginer de tels événements sans ses blagues. Et récemment, nous avons acquis un artefact rituel, le haut-parleur. L'orateur doit mettre un capuchon. Cela ne signifie rien de spécial, c'est juste un rituel, mais ça égaye tout le monde.
Participants à distance
Il est facile d'effectuer une revue de sprint lorsque tout le monde est assis dans la même pièce. Mais nous avons beaucoup d'employés à distance à Syktyvkar, Nizhny Novgorod, Kazan et Goryachy Klyuch, et il est important qu'ils soient également impliqués.
Au début, ils se plaignaient de ne pouvoir entendre ou voir pratiquement rien, mais nous avons appris à nous soucier d'eux et de nos participants hors ligne. Dans la liste de contrôle de la préparation de la revue de sprint, il y a des rappels que nous devons vérifier la connexion Internet et ajuster l'équipement. Nous publions des mises à jour sur les événements via Slack, et récemment, nous avons commencé à diffuser nos réunions sur la
chaîne Youtube Dodo Pizza .
Ne pas recueillir de commentaires
Quand nous avions déjà commencé à penser que tout allait bien et que nous n'avions pas besoin d'améliorer quoi que ce soit d'autre, nous nous sommes demandé si nous faisions vraiment la bonne chose. Une revue de sprint est une affaire assez coûteuse, compte tenu du nombre de participants, de leur salaire et du temps passé. Utilisons-nous ces deux heures avec une efficacité maximale? En conséquence, nous avons décidé de ne pas du tout recueillir de commentaires lors des revues de sprint. Dans de telles conditions, les commentaires ne sont jamais complets ou de bonne qualité (l'examen du site Web du Kazakhstan en est un exemple). En outre, nous recueillons beaucoup de commentaires significatifs et utiles pendant le sprint lui-même, interrogeant toutes les parties intéressées, des clients internes aux utilisateurs.
Vous seriez surpris, mais même dans le Scrum Guide, il n'y a pas un mot sur la collecte de commentaires lors d'une revue de sprint. «Au cours de la revue Sprint, l'équipe Scrum et les parties prenantes collaborent sur ce qui a été fait dans la Sprint.» L'équipe Scrum et les parties prenantes, pas les utilisateurs. Et ils collaborent, ne recueillent pas de commentaires. Ce n'est pas du tout cela.
Bienvenue dans les coulisses
Toutes les parties prenantes ne participent pas activement au processus de développement, mais elles souhaitent toutes être tenues informées de ce qui s'y passe. Et c'est notre objectif de révision de sprint maintenant. Nous montrons toujours ce que nous avons fait, mais en plus de cela, nos équipes parlent de la genèse de nouvelles fonctionnalités. Quel était notre objectif? Que s'est-il passé pendant le sprint? Qu'est-ce qui nous a distraits ou gênés? Quelles mesures avons-nous prises pour atteindre notre objectif? Et ça aide; De cette façon, les managers peuvent comprendre, par exemple, pourquoi cacher l'adresse e-mail d'un client dans un reçu avec des astérisques n'est pas du tout une tâche triviale et pas seulement "une demi-heure de programmation", comme ils le pensaient précédemment. Et un tel dialogue aide nos développeurs de logiciels à penser en fonction des problèmes des clients, sans se laisser emporter par la solution sur laquelle ils travaillent.
Ce sont les principales choses que nous avons modifiées dans notre approche des revues de sprint. Il y a certes des progrès, mais il y a encore place à amélioration, nous continuons donc nos expériences.
Par-dessus tout, nous avons compris une chose - vous n'avez pas besoin de trop vous obséder sur les recommandations du Scrum Guide. Vous devriez procéder par essais et erreurs. Il n'y a pas de solutions universelles; vous devriez chercher ceux qui travaillent pour vous.
Donc, en conclusion, je veux juste vous avertir. Ne copiez pas notre format. Cela fonctionne pour nous, car il est né de l'expérimentation. Recherchez votre propre approche et vous réussirez. Quel est le pire qui puisse arriver?