¿Qué obtienes cuando cruzas un departamento de TI, una revisión, determinación y pizza defectuosas de Sprint? Grandeza, eso es lo que.
Nuestro primer intento de introducir
revisiones de sprint en Dodo Pizza fracasó espectacularmente. Se podría pensar, tal vez, que una cadena de pizzas no necesita prácticas Scrum en absoluto. Sin embargo, por extraño que parezca, una de las principales ventajas de
Dodo Pizza es su propio sistema de TI que controla todos los procesos de trabajo de 430 pizzerías en 11 países.
Más de 60 programadores y analistas trabajan en nuestro sistema ahora, y estamos planeando aumentar ese número a
más de 200 . Al igual que cualquier inicio de rápido crecimiento, nuestro objetivo es lograr la máxima eficiencia, por lo que utilizamos mucho los marcos ágiles, incluidos Scrum, LeSS y programación extrema. Pero, ¿cómo empleas Scrum sin revisiones de sprint? Esa es la pregunta que podrías hacer, y estarías en lo correcto.
Como sabemos, una revisión de sprint establece el ritmo de trabajo para un equipo y lo motiva a terminar la tarea al final del sprint. Más importante aún, una revisión de Sprint ayuda a crear un producto que es valioso para el negocio, no solo para resolver problemas de la cartera de pedidos. Al menos, eso dicen los libros.
Pero de alguna manera, este enfoque nunca funcionó para nosotros. Por ejemplo, en una de nuestras primeras revisiones de sprint, presentamos un nuevo sitio web (dodopizza.kz) a nuestros franquiciados de Kazajstán. La retroalimentación fue inspiradora, nuestros socios nos dijeron que el sitio web se veía genial, y en comparación con los competidores, era prácticamente una obra maestra. Pero después de su lanzamiento, resultó que le faltaba mucho. Así que perdimos el tiempo en una revisión de sprint pero no obtuvimos ningún comentario útil.
Pronto, detuvimos en silencio estas revisiones de sprint por completo.
Pasaron varios meses y decidí volver a intentarlo. En ese momento, teníamos ocho equipos trabajando en una cartera de pedidos en el marco de
LeSS . Intentamos cumplir con todas las reglas de Scrum a gran escala, y la cancelación de las revisiones de sprint fue una violación.
Me preparé para obtener malos resultados iniciales: estaba claro que tendríamos que encontrar el formato correcto a través de prueba y error. Después de cada revisión, les pedí a los participantes que la evaluaran en una escala del 1 al 10. Inicialmente, nuestras calificaciones fueron muy bajas, pero no nos dimos por vencidos y continuamos experimentando, así que en un par de meses, las revisiones comenzaron a mover a la parte superior de la escala.
Esto es lo que hicimos de manera diferente.
Haciendo nuestra tarea
Está claro que la preparación de la revisión de sprint exige no menos tiempo que la revisión de sprint en sí, o incluso más. Una revisión lleva dos horas, y me paso tres horas preparándome. Hay objetivos de revisión para discutir y acordar con el equipo, los socios, los gerentes de la empresa matriz, los empleados y otros invitados con quienes hablar, salas de conferencias para reservar, un póster para hacer, facilitadores para encontrar e instruir, un calendario para armar , rotafolios de comentarios para colgar, etc. Y sin todo eso, se produce el caos.
Si no está terminado, no lo muestres
Al principio, mostramos características medio listas en las revisiones de sprint. Entonces se nos ocurrió que esto significaba engañar a nuestros equipos y, lo que es peor, a nuestros clientes. Le mostramos al CEO un servicio de mapeo que almacena datos cartográficos una vez. En la próxima revisión, lo mostramos nuevamente, con errores corregidos. Cuando se lo trajimos por tercera vez y se lo mostramos en el sitio web en vivo, tenía una pregunta muy legítima: ¿por qué demonios tiene que mirar lo mismo una y otra vez? Ahora, en las revisiones de sprint, mostramos solo las características que ya están en un sitio en vivo. Si algo está casi listo y solo necesitamos corregir errores, probarlo y desplegarlo, simplemente no lo mostramos todavía.
Salas de conferencias en lugar de un espacio abierto
Los creadores de LeSS recomiendan realizar una revisión de sprint como un "bazar", donde todos los equipos demuestran su trabajo en una sala grande y las personas visitan las estaciones que les interesan. Lo intentamos varias veces, y había mucho ruido y confusión.
Las pantallas de las computadoras portátiles son pequeñas e incómodas, no se puede concentrar muy bien debido al ruido en otras estaciones y se produce el caos cuando la gente deambula constantemente. Así que ahora todos nos reunimos en una gran sala de conferencias solo al principio y al final de la revisión. La acción principal tiene lugar en pequeñas salas de conferencias, donde cada equipo presenta su trabajo. Es más cómodo, hay todo el equipo necesario, pantallas grandes y acceso a Internet para participantes remotos, y puede recopilar comentarios en paz.
Vagar no está permitido
Al principio, las partes interesadas caminaban libremente entre los equipos, pero era molesto. Imagine que está haciendo su presentación, ha estado hablando durante diez minutos y luego alguien aparece y le hace preguntas sobre las cosas que acaba de cubrir.
Si respondes, todos los demás están aburridos. Si no lo hace, esta persona puede resentirse. Así que hemos decidido no permitir deambular entre grupos. Si ha elegido un tema, siéntese en una sala de conferencias y espere 20 minutos hasta el próximo descanso.
Estimados invitados
Nos hemos dado cuenta de que la lista de invitados es muy importante. Nada motiva más a un desarrollador que un CEO de la compañía que visita una revisión de sprint, especialmente cuando muestra algo técnico, como alojar un microservicio en Kubernetes o migrar un componente de autenticación a .Net Core. Luego tienes que explicar por qué incluso hiciste todo esto en primer lugar.
Fyodor Ovchinnikov, el CEO de Dodo Pizza , puede cargar energía a la audiencia, levantar el ánimo en tres minutos y describir las amplias perspectivas del desarrollo de la compañía, pero al demostrar características de front-end, como la función de construir su propia pizza En nuestra aplicación móvil, invitamos a invitados externos, en su mayoría conocidos y amigos de Facebook.
Un presentador divertido y una gorra
Resulta que el presentador representa la mitad del éxito de una revisión de sprint interesante y emocionante. Mucha gente ha jugado ese papel; Lo intenté primero, con la ayuda de nuestros maestros Scrum.
Entonces Sergey Gryazev, el propietario de nuestro producto de aplicación móvil, se convirtió en presentador, y ahora no podemos imaginar tales eventos sin sus bromas. Y recientemente, adquirimos un artefacto ritual, el Gorro del orador. El orador debe ponerse una tapa. No significa nada especial, es solo un ritual, pero anima a todos.
Participantes remotos
Es fácil realizar una revisión de sprint cuando todos se sientan en la misma habitación. Pero tenemos muchos empleados remotos en Syktyvkar, Nizhny Novgorod, Kazan y Goryachy Klyuch, y también es importante que participen.
Al principio, se quejaron de que no podían escuchar ni ver prácticamente nada, pero hemos aprendido a preocuparnos por ellos y por nuestros participantes fuera de línea. En la lista de verificación de preparación de la revisión de sprint, hay recordatorios de que debemos verificar la conexión a Internet y ajustar el equipo. Publicamos actualizaciones de eventos a través de Slack, y recientemente, comenzamos a transmitir nuestras reuniones en el
canal de Dodo Pizza Youtube .
No recopile comentarios
Cuando ya habíamos empezado a pensar que todo estaba bien y no necesitábamos mejorar nada más, nos preguntamos si realmente estamos haciendo lo correcto. Una revisión de sprint es un asunto bastante costoso, teniendo en cuenta la cantidad de participantes, sus salarios y el tiempo dedicado. ¿Usamos estas dos horas con la máxima eficiencia? Como resultado, hemos decidido no recopilar comentarios en las revisiones de sprint. En tales condiciones, los comentarios nunca son completos o de buena calidad (la revisión del sitio web de Kazajstán es un buen ejemplo). Además, reunimos una gran cantidad de comentarios significativos y útiles durante el sprint en sí, cuestionando a todas las partes interesadas, desde clientes internos hasta usuarios.
Se sorprendería, pero incluso en la Guía Scrum, no hay una palabra sobre la recopilación de comentarios en una revisión de sprint. "Durante la Revisión de Sprint, el Equipo Scrum y las partes interesadas colaboran sobre lo que se hizo en Sprint". El equipo Scrum y las partes interesadas, no los usuarios. Y colaboran, no recopilan comentarios. No se trata de eso en absoluto.
Bienvenido al backstage
No todas las partes interesadas participan activamente en el proceso de desarrollo, pero todas quieren mantenerse informadas de lo que está sucediendo allí. Y ese es nuestro objetivo de revisión de sprint ahora. Todavía mostramos lo que hemos hecho, pero además de eso, nuestros equipos hablan sobre la génesis de las nuevas características. ¿Cuál fue nuestro objetivo? ¿Qué estaba pasando durante el sprint? ¿Qué nos distrajo o nos impidió? ¿Qué medidas tomamos para alcanzar nuestra meta? Y ayuda; De esta manera, los gerentes pueden entender, por ejemplo, por qué ocultar la dirección de correo electrónico de un cliente en un recibo con asteriscos no es una tarea trivial en absoluto y no solo "media hora de programación", como pensaban anteriormente. Y dicho diálogo ayuda a nuestros desarrolladores de software a pensar en términos de los problemas de los clientes, no dejarse llevar por la solución en la que están trabajando.
Estas son las cosas principales que hemos cambiado en nuestro enfoque para las revisiones de sprint. Definitivamente hay progreso, pero también hay margen de mejora, por lo que continuamos nuestros experimentos.
Sobre todo, hemos entendido una cosa: no necesita obsesionarse demasiado con las recomendaciones de la Guía Scrum. Debes ir por prueba y error. No hay soluciones universales; deberías buscar a los que trabajan para ti.
Entonces, en conclusión, solo quiero advertirte. No copie nuestro formato. Funciona para nosotros, ya que nació de la experimentación. Busque su propio enfoque y tendrá éxito. ¿Qué es lo peor que puede pasar?