"Nos acostamos, encendimos luces, en el Universo somos los únicos". Parece que esta línea de la canción del grupo Splin se puede reconocer de forma segura como la banda sonora de la introducción de la práctica de Sprint Review en Dodo Pizza.
Descargo de responsabilidad: en un artículo, Anton describe la primera versión de una revisión de sprint viable. Ya tenemos uno más avanzado, pero al respecto en la próxima serie.
El primer intento de lanzar la práctica de revisión de sprint en Dodo Pizza fracasó miserablemente.
Tal vez piense que las prácticas de la cadena de pizza scrum son generalmente inútiles. Sin embargo, una de las principales ventajas de Dodo Pizza es, curiosamente, su propio sistema de TI, que gestiona todos los procesos en 495 pizzerías de la cadena en 12 países.
Más de 80 desarrolladores y analistas están trabajando en este sistema hoy (y más de doscientos vendrán con el tiempo). Como una startup de rápido crecimiento, nos esforzamos por lograr la máxima eficiencia, por lo tanto, utilizamos muchos de los marcos de "desarrollo flexible": Scrum, LeSS, programación extrema.
Pero, ¿qué es este scrum, preguntas, sin una revisión de sprint? Y tendrás razón.
Como sabes, la revisión del sprint marca el ritmo del equipo y motiva a completar el trabajo al final del sprint. Más importante aún, ayuda a crear un producto valioso que una empresa necesita, y no solo a realizar tareas pendientes. Entonces, en cualquier caso, escriben en libros.
Sin embargo, por alguna razón, este enfoque no funcionó para nosotros. Por ejemplo, en una de las primeras revisiones de sprint mostramos a los franquiciados de Dodo Pizza de Kazajstán su nuevo sitio: dodopizza.kz. La retroalimentación fue inspiradora: los socios dijeron que el sitio se ve magnífico, y en el contexto de los competidores, parecerá una obra maestra.
Cuando lo lanzamos, resultó que faltaban muchas cosas. Es decir, pasamos tiempo en la revisión de sprint, pero en realidad no obtuvimos comentarios útiles de los socios.
En general, pronto detuvimos silenciosamente tales revisiones de sprint.
Después de unos meses, decidí volver a intentarlo. Para ese momento, ya teníamos ocho equipos trabajando en el mismo trabajo atrasado en el marco de LeSS. Intentamos seguir todas las reglas de Scrum a gran escala, y la falta de revisión de sprint fue una de las violaciones.
Me preparé de antemano por el hecho de que al principio todo será malo, y deberá buscar el formato correcto utilizando el método de prueba y error. Después de cada revisión, pedí a los participantes que calificaran el evento en una escala del 1 al 10 (Inferior - Omnische). Al principio, las calificaciones eran muy bajas, más cercanas al "fondo". Sin embargo, no nos dimos por vencidos, experimentamos, y en algún lugar en un par de meses comenzaron a cambiar al Ognist.
Eso es lo que cambiamos
Haciendo la tarea
Nos dimos cuenta de que no debes dedicar menos tiempo a la preparación que a la revisión del sprint, o incluso más. Todo el evento dura dos horas, y me preparo para tres horas. Después de todo, es necesario coordinar los objetivos con los equipos, concertar con socios, gerentes de la empresa de gestión, empleados de pizzerías y otros invitados, reservar conversaciones, hacer un póster, encontrar facilitadores, instruir, redactar y dibujar un cronograma, colgar charlas para recoger comentarios, etc. Sin todo esto, simplemente habrá caos.
No mostrar sin terminar
Al principio, mostramos características a medio terminar. Pero nos dimos cuenta de que así es como engañamos a los equipos y, lo más importante, a los clientes. Una vez le mostramos al CEO de una empresa de geoservicios que almacena en caché los datos del mapa. Luego, en la próxima revisión, se mostró nuevamente, solo con errores corregidos. Cuando llegamos por tercera vez y mostramos el mismo servicio, pero ya en el sitio web de combate, el CEO tenía una pregunta lógica: "¿Qué demonios estás mostrando lo mismo por tercera vez?"
Ahora en la revisión de sprint mostramos solo lo que se publica en el sitio de combate. Si algo está casi listo, solo hay errores para corregir, probar y diseñar errores, no lo mostramos.
Negociaciones en lugar de espacios abiertos
Los autores de LeSS recomiendan una revisión de sprint en forma de "bazar". Todos los equipos deben mostrar su trabajo en una sala grande, y los interesados pueden ir a las estaciones que les interesen. Lo intentamos varias veces, resultó ruidoso y quisquilloso.
Las pantallas de las computadoras portátiles son pequeñas, no se ve nada en ellas, el ruido de las estaciones vecinas hace que sea difícil concentrarse y el movimiento constante de las personas crea caos. Por lo tanto, ahora en la sala de conferencias todos se reúnen solo al principio y al final. La acción principal tiene lugar en las salas de reuniones, donde cada equipo presenta su trabajo. Allí, equipo, pantallas grandes, puede sentarse cómodamente, los participantes remotos están conectados y hay un lugar para recopilar comentarios.
¡Las transiciones están prohibidas!
Al principio, nuestros grupos de interés se movían libremente entre equipos. Pero fue molesto. Imagine que comenzó a contar algo y en diez minutos una nueva persona se une al grupo y hace preguntas sobre lo que acaba de hablar.
Comienza a responder: el resto está aburrido. Ignorar: la persona está molesta. Por lo tanto, decidimos prohibir el movimiento entre grupos. Elegí el tema que te interesa: siéntate en la sala de reuniones durante veinte minutos hasta el próximo descanso.
Estimados invitados
Nos dimos cuenta de que la composición de los "invitados" es de gran importancia. Nada motiva a un desarrollador como aparecer en un CEO de revisión de sprint. Especialmente cuando necesita mostrarle algún truco técnico, como un servicio en un cubo o transferir Auth a .Net Core. Tenemos que explicar por qué estamos haciendo esto. Fedor Ovchinnikov, CEO de Dodo Pizza, energiza y sabe animar a todos y delinear los horizontes del desarrollo de la compañía en tres minutos. Bueno, cuando mostramos las características del cliente, por ejemplo, un constructor de media pizza en una aplicación móvil, ahora llamamos a invitados externos, por regla general, conocidos y amigos de Facebook.
Miembros eliminados
Es fácil celebrar una reunión cuando todo está en una habitación. Pero tenemos muchos empleados remotos en Syktyvkar, Nizhny Novgorod, Kazan y Goryachy Klyuch. También es importante que asistan.
Al principio, los "trabajadores remotos" se quejaron de que tenían problemas de audición y casi no veían nada. Ahora nos ocupamos de ellos y de los participantes fuera de línea. Hay elementos en la lista de verificación de preparación de la revisión de sprint que nos recuerdan verificar la conexión y configurar el equipo. Estamos transmitiendo en Slack, y más recientemente, hemos estado transmitiendo el evento en nuestro canal de YouTube Dodo Pizza .
Descargo de responsabilidad de comentarios
Cuando comenzó a parecer que todo estaba bien y no había ningún lugar para mejorar el formato, nos hicimos la pregunta: ¿no estamos haciendo basura? Una revisión de sprint es un evento bastante costoso (si lo miras cínicamente, en términos del número de participantes, sus salarios y las horas dedicadas). ¿Estamos usando estas dos horas de la forma más productiva posible? Como resultado, decidimos negarnos por completo a recopilar comentarios durante la revisión del sprint.
En el formato de tal evento, no se puede hacer profunda y cualitativamente (recuerde un caso con Kazajstán). Además, recopilamos la mayoría de las revisiones significativas y de alta calidad durante el sprint, atrayendo a todos los interesados, desde clientes internos hasta usuarios ... Se sorprenderá, incluso la Guía Scrum no dice que se deben recopilar comentarios sobre la revisión del sprint: "Durante la revisión del Sprint , el Equipo Scrum y las partes interesadas colaboran sobre lo que se hizo en el Sprint ". Equipo y partes interesadas, no usuarios. Interactuar, no recopilar comentarios. Un significado completamente diferente.
Abre la "cocina"
No todas las partes interesadas están profundamente inmersas en el proceso de desarrollo. Pero todos quieren saber qué está pasando allí. Es para estos fines que decidimos reorientar la revisión del sprint.
Todavía mostramos el trabajo realizado, pero además de esto, los equipos cuentan la historia detrás de las nuevas características. ¿Cuál fue el propósito? ¿Qué pasó durante el sprint? ¿Qué nos distrajo o nos impidió alcanzar nuestra meta? ¿Qué medidas hemos tomado para salvar el gol? Ayuda: esto deja en claro a los gerentes, por ejemplo, por qué "ocultar el correo electrónico del cliente con una marca de verificación en las estrellas" es una tarea muy difícil ("media hora de trabajo de un programador", como pensaron los gerentes). Por el contrario, dicho diálogo ayuda a los desarrolladores a pensar en términos de "clientes" y sus problemas, en lugar de en términos de las soluciones específicas en las que están trabajando.
Esto es quizás lo principal que hemos cambiado en nuestro enfoque. El progreso es evidente, pero como siempre, todavía hay algo que mejorar. Los experimentos están en curso.
Lo principal que entendimos es que no necesitamos quedarnos con los formatos propuestos en los manuales de Scrum. Necesitas intentar, cometer errores y experimentar. No hay soluciones universales: debe buscar las que funcionan en su situación.
Por lo tanto, quiero advertirle al final: no copie nuestro formato. Trabaja bien con nosotros porque nació como resultado de muchos experimentos. Busque su enfoque, y tendrá éxito. Ciertamente no será peor.