Fundamentos de Scrum desde la mirada Garage (2/2)
En el artículo anterior sobre Scrum que publiqué anteriormente, les conté un poco acerca de esta metodología y sus bases, además de su filosofía y algunos detalles de cómo llevarlo a cabo. Ahora, los invito a que vean cómo aplicamos todo eso en Garage Labs y cómo ha sido el camino hasta el día de hoy. Comencemos!
Configuración inicial
Hace un par de años, cuando Garage recién se lanzaba como una empresa emergente de desarrollo de software e e-Commerce, nos preguntábamos cómo llevar adelante los desarrollos de software que se nos presentaban como nuevos desafíos. Es así como en un primer salto metodológico nos propusimos implementar Scrum en nuestros equipos.
Para nuestros equipos de desarrollo existe una configuración predefinida: Un Product Owner, nuestro líder por parte de negocio, quien comparte casi el mismo conocimiento de nuestro cliente, un Designer, quien se encarga de temas UX/UI, Mockups y todo lo relacionado con las interacciones Usuario/Software, y finalmente un Dev, quien condensa todo el conocimiento de las otras dos partes y las plasma en nuestros productos. Nuestros equipos siempre se definen de 3 personas, ya que, como les comentaba en el artículo anterior, es importante mantener los canales de comunicación acotados. En este tipo de equipos cubrimos todas las habilidades necesarias para llevar adelante el software. Si es necesario hacer delivery más rápido de funcionalidades, siempre es posible añadir un nuevo Dev a nuestros equipos sin romper nuestra configuración.
Herramientas
Para ordenar la información de los sprints, redactar historias de usuario, armar backlog de funcionalidades y todo lo demás, utilizamos Jira. Con esto tenemos distintas funcionalidades en una: Tablero Kanban de nuestros desarrollos, gestión de épicas, incidencias, tareas, historias de usuario e incluso podemos armar una planificación por épicas con User Story Map.
Y si! somos amantes de los tableros Kanban. La visibilidad del trabajo lo es todo en Scrum y no tenemos problemas en que todo el equipo Garage vea en qué estamos, además de poder ver el status de tus compañeros sin molestarlos mientras están a full.
En el caso de Mockups y Wireframes nuestros equipo Designer suele utilizar la suite Adobe, así entre todos nos compartimos el status de sus diseños.
Estas herramientas que te menciono obviamente no son la panacea y cada equipo que conformes puede sentirse cómodo trabajando con otros software del estilo kanban o de diseño. Lo importante es que las hagas tuyas y que facilite la vida de todos.
El día a día
En nuestros equipos de desarrollo tenemos altamente interiorizados los rituales de Scrum. Para partir, nuestros sprint plannings (inicio de iteración en desarrollo) siempre deben caer día lunes. En estas reuniones en conjunto con el cliente negociamos lo que más valor le aportará a la solución que estamos construyendo, plasmándolo en una historia de usuario que luego pasará al conjunto de funcionalidades que deben llevarse a cabo en esa iteración.
Nuestras iteraciones/sprints siempre intentamos que duren 2 semanas, terminando con un sprint review /demo el viernes de la segunda semana. Hay ocasiones excepcionales que extendemos nuestros sprints, ya sea por feriados o por cuestiones de negocio. Tus equipos deben ser lo suficientemente autónomos y autorganizados para que ellos decidan qué es lo mejor para el equipo en estos casos. En estas reuniones de demo que también incluye al cliente damos a conocer el trabajo que hemos realizado y es la instancia ideal para obtener feedback que nos permita dar cuenta de los errores o cambios que se deben hacer para las siguientes iteraciones.
En el día a día, nuestros equipos que recién se vienen acoplando realizan las llamadas daily meeting de Scrum, que es básicamente dar a conocer a nuestro equipo qué estamos haciendo, qué vamos a hacer en el día y cuáles han sido nuestras complicaciones. En nuestros equipos con más experiencia este ritual ya no es tan formal, ya que los equipos se han afianzado y han hecho la daily meeting algo implícito en su comunicación y organización.
Otro ritual que llevamos a cabo son las retrospectivas, que es la instancia en que el equipo se plantea qué ha hecho mal, qué ha hecho bien y qué se podría cambiar. En nuestros equipos nuevos hacemos de esto un ritual de ajuste a nivel de equipo y organizacional, para que descubran cuál es la forma de trabajar que más le acomoda y para descubrir aquellos procesos o elementos que los hacen avanzar más lento. Una vez que toman confianza y quedan funcionando como relojito como nos gusta decirle, utilizamos las retrospectivas para ajustar cosas más puntuales que pueden surgir en el equipo, y así mejorar sprint a sprint.
Digievoluciones
Así como en los animés, nosotros también hemos ido digievolucionando metodológicamente, a continuación te cuento un poco el progreso que hemos tenido.
De un track a dos
Sabemos que Scrum solo nos aporta los artefactos y filosofía del cómo hacer el delivery de un producto, por lo que en nuestros primeros desarrollos nos hizo falta una forma de obtener información valiosa de nuestros clientes para pulir nuestros backlogs e historias de usuario, además de saber qué es lo que más agregará valor al cliente a la brevedad.
Para subsanar estas necesidades nos propusimos trabajar con Scrum Dual Track. Esta metodología propone trabajar con 2 subequipos dentro de un mismo equipo de desarrollo: Por una parte, tenemos un track y subequipo de discovery, que se encargará de interactuar con el cliente y usuarios finales para obtener la información necesaria para mejorar nuestro backlog, y, por otra parte, un subequipo de delivery, que es la configuración que nos propone Scrum por si solo.
Cuando implementamos este dual track, agregamos un nuevo ritual a nuestro día a día, una reunión de sprint n+1, que es destinada a interactuar con usuarios y cliente sobre sus necesidades y cómo podemos plasmarlas en el software o producto y que aporte valor inmediato a su organización. Este ritual siempre debe darse antes de la próxima reunión de planning, mientras el team delivery desarrolla un sprint. El nombre n+1 surge ya que siempre estamos levantando necesidades y problemas de nuestro cliente para el próximo sprint que se avecina.
Este equipo de discovery se conforma de nuestro Produc Owner y Designer, para dejar al Dev libre mientras ejecuta las historias de usuario en el sprint activo.
De dos tracks a tres
Luego de trabajar aproximadamente un año con dual track, nos dimos cuenta que hacía falta un mayor involucramiento de nuestro equipo de Designers en el crecimiento y formación de nuestros productos. Es así como nace nuestro triple track: Un track Delivery, otro de Discovery y un nuevo track de Design.
El objetivo de esto fue empoderar a nuestros Diseñadores y Diseñadoras en su rol y apoyar, desde su punto de vista, al levantamiento de problemas desde una mirada más cercana con los potenciales usuarios de nuestros productos. Uno de los procesos que incorporamos a nuestro día a día fue realizar Design Sprints por sobre reuniones de n+1, para tener información más precisa que nos permita adelantarnos a algunos posibles cambios o errores que cometíamos al trabajar con dual track. Por otra parte, con estos design sprints acercamos a los usuarios a nuestra labor de construir productos que faciliten la operación de sus trabajos y recibimos feedback en etapas tempranas, incluso cuando aún el track delivery y el dev no tienen idea de lo que viene a futuro.
Si quieres conocer cómo llevamos a cabo los design sprints puedes leer alguno de los artículos que Natalia Rodríguez Mariani ha compartido y documentado para que puedas aplicarlo.
Para ir cerrando, este triple track que hemos propuesto no es definitivo, como te comenté en el artículo anterior nuestra meta es buscar la maestría en lo que hacemos, y para eso necesitamos seguir iterando como equipo.
Espero que te haya gustado acompañarme en esta historia de evolución de nuestra forma de trabajo, si quieres nos puedes dejar tus dudas o experiencia en los comentarios para conversar sobre estos temas. #StayHome!
